Re: Ruby w/clang (Was: Re: [CFT]: ClangBSD is selfhosting, we need testers now)

On Thu, Apr 29, 2010 at 02:40:24AM +1100, Dima Panov wrote:
> On Wednesday 28 April 2010 23:16:38 Ollivier Robert wrote:
> > According to Dima Panov:
> > > while building lang/ruby18:
> > Which options to you use?
> > 
> > _OPTIONS_READ=ruby+oniguruma-1.8.7.248_1,1
> > WITHOUT_ONIGURUMA=true
> > WITH_RDOC=true
> > WITHOUT_DEBUG=true
> > 
> > I notice your ruby is compiling w/o any -On, try with -O at least?
> 
> same here. also on 1.8.7.249 snapshot.
> 
> ar rcu libruby18-static.a array.o  bignum.o  class.o  compar.o  dir.o  dln.o  enum.o  
> enumerator.o  error.o  eval.o  file.o  gc.o  hash.o  inits.o  io.o  marshal.o  math.o  
> numeric.o  object.o  pack.o  parse.o  process.o  prec.o  random.o  range.o  re.o  regex.o  
> ruby.o  signal.o  sprintf.o  st.o  string.o  struct.o  time.o  util.o  variable.o  
> version.o   dmyext.o
> clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC    -DRUBY_EXPORT -I. 
> -I. -I/usr/include    -c main.c
> clang -I/usr/include -O2 -fno-strict-aliasing -pipe -std=gnu89  -fPIC    -DRUBY_EXPORT -L.  
> -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o  libruby18-static.a -
> lrt -lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
> ./lib/fileutils.rb:1437: [BUG] unexpected local variable assignment
> ruby 1.8.7 (2010-01-10 patchlevel 249) [amd64-freebsd9]
> 
> *** Signal 6
> 
> Stop in /tmp/usr/ports/lang/ruby18/work/ruby-1.8.7-p249.
> *** Error code 1
> 
> 
> _OPTIONS_READ=ruby-1.8.7.249,1
> WITHOUT_ONIGURUMA=true
> WITH_RDOC=true
> WITHOUT_DEBUG=true
> 
> 
> > 
> > > clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC    -DRUBY_EXPORT -I.
> > > -I. -I/usr/include -c main.c
> > > clang -I/usr/include -pipe -g -g -std=gnu89  -fPIC    -DRUBY_EXPORT -L. 
> > > - rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o 
> > > libruby18-static.a -lrt -lcrypt -lm -L/usr/lib 
> > > -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
> > > ./lib/fileutils.rb:1429: fu_same? is not a class/module (TypeError)
> > > 
> > >         from ./mkconfig.rb:11:in `require'
> > >         from ./mkconfig.rb:11
> > > 
> > > *** Error code 1
> > 
> > Interesting, using a fairly recent clang snapshot from trunk, I get a sig11
> > :(
> 
> 
> Ruby is bad?
> 
For the record, ruby compilation also fails with base gcc inside
i386 ports tinderbox on amd64-CURRENT host:

[snip]
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC    -DRUBY_EXPORT -I. -I. -I/usr/include    -c variable.c
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC    -DRUBY_EXPORT -I. -I. -I/usr/include    -c version.c
In file included from version.c:14:
version.h:29:41: warning: no newline at end of file
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC    -DRUBY_EXPORT -I. -I. -I/usr/include    -c dmyext.c
ar rcu libruby18-static.a array.o  bignum.o  class.o  compar.o  dir.o  dln.o  enum.o  enumerator.o  error.o  eval.o  file.o  gc.o  hash.o  inits.o  io.o  marshal.o  math.o  numeric.o  object.o  pack.o  parse.o  process.o  prec.o  random.o  range.o  re.o  regex.o  ruby.o  signal.o  sprintf.o  st.o  string.o  struct.o  time.o  util.o  variable.o  version.o   dmyext.o
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC    -DRUBY_EXPORT -I. -I. -I/usr/include    -c main.c
cc -I/usr/include -O2 -pipe -fno-strict-aliasing  -fPIC    -DRUBY_EXPORT -L.  -rpath=/usr/lib:/usr/local/lib -pthread -rdynamic  -pthread main.o  libruby18-static.a -lrt -lcrypt -lm -L/usr/lib  -rpath=/usr/lib:/usr/local/lib -pthread  -o miniruby
./lib/fileutils.rb:1030: retry outside of rescue clause
rbconfig.rb updated
*** Error code 1

Stop in /work/a/ports/lang/ruby18/work/ruby-1.8.7-p248.
*** Error code 1

Stop in /a/ports/lang/ruby18.
================================================================
build of /usr/ports/lang/ruby18 ended at Sat Apr 24 04:57:59 UTC 2010

I don't know why it is failing in the same file (is it just included first
or is it really troublesome?), but it looks quite suspicious.
I am nowhere the ruby expert but it may be that the problem is in ruby itself.
Note, that I have successfully built quite a lot of packages inside
this i386 tinderbox on amd64 host including full kde4, openoffice3, jdk16,
virtualbox-ose, mplayer, ...

On the topic, if I understand it correctly, one can build clandbsd branch
with normal gcc from base, so it is "backward compatible".
What are the general showstoppers then to merge to HEAD
the part of clangbsd that allows building HEAD with llvm from ports?
I think this will significantly increase the number of testers...

Alexey.