We recently upgraded to GCC 3.3.3 and now we can no longer compile ruby
due to its use of some obsoleted constructs.
Apparently GCC no longer supports <varargs.h>, and code should be
revised to use <stdarg.h>
Not knowing anything about it, is there a good workaround?
Will this be changed in future versions of Ruby so that it will play
nice with the latest GCC?
gcc -fPIC -g -O2 -fPIC -mpa-risc-2-0 -I.
-I/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/compiled-1.8.0
-I/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/ruby-1.8.0
-I/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/ruby-1.8.0/ext/curses
-DHAVE_CURSES_COLR_CURSES_H -DHAVE_ISENDWIN -DHAVE_UNGETCH -DHAVE_BEEP
-DHAVE_GETNSTR -DHAVE_WGETNSTR -DHAVE_DOUPDATE -DHAVE_FLASH
-DHAVE_DELETELN -DHAVE_WDELETELN -DHAVE_KEYPAD -DHAVE_KEYNAME
-DHAVE_INIT_COLOR -c
/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/ruby-1.8.0/ext/curses/curs
es.c
In file included from
/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/ruby-1.8.0/ext/curses/curs
es.c:23:
/opt/ictools/gcc/lib/gcc-lib/hppa2.0-hp-hpux11.00/3.3.3/include/varargs.h:4:2:
#error “GCC no longer implements <varargs.h>.”
/opt/ictools/gcc/lib/gcc-lib/hppa2.0-hp-hpux11.00/3.3.3/include/varargs.h:5:2:
#error "Revise your code to use <stdarg.h>."
In file included from
/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/ruby-1.8.0/ext/curses/curs
es.c:24:
/opt/ictools/gcc/lib/gcc-lib/hppa2.0-hp-hpux11.00/3.3.3/include/curses_colr/curs
es.h:340:
error: parse error before “va_list”
/opt/ictools/gcc/lib/gcc-lib/hppa2.0-hp-hpux11.00/3.3.3/include/curses_colr/curs
es.h:341:
error: parse error before “va_list”
Ruby successfully compiled the latest stable snapshot with 3.3.3, so perhaps
you should move to that until the next release is made.
···
On Friday 05 Mar 2004 16:04, Brett Williams wrote:
We recently upgraded to GCC 3.3.3 and now we can no longer compile ruby
due to its use of some obsoleted constructs.
Hi,
At Sat, 6 Mar 2004 01:04:43 +0900,
Brett Williams wrote in [ruby-talk:94357]:
In file included from
/home/kgr/work/actruby/build/hpux11.0/pa2.0/debug/src/ruby-1.8.0/ext/curses/curs
es.c:23:
curses.c in 1.8.1 already uses stdarg.h if found.
···
–
Nobu Nakada
Brett Williams wrote:
We recently upgraded to GCC 3.3.3 and now we can no longer compile ruby
due to its use of some obsoleted constructs.
Apparently GCC no longer supports <varargs.h>, and code should be
revised to use <stdarg.h>
Not knowing anything about it, is there a good workaround?
Will this be changed in future versions of Ruby so that it will play
nice with the latest GCC?
Some time ago I backported a old version of ruby (1.0 something) to gcc
3.3. I had the same problem (varargs.h). It wasn’t all that hard to fix
actually. You can take a look at my patch for some pointers. It’s at
http://zeroth.zapto.org/diff-ruby-1.0-971225-gcc-3.3-fix. Then you just
write up a patch and send in 
···
–
Zeroth
Or, in English I have successfully compiled the latest Ruby ‘stable
snapshot’ with gcc 3.3.3, so use that until a new release is made.
···
On Friday 05 Mar 2004 19:12, Andrew Walrond wrote:
On Friday 05 Mar 2004 16:04, Brett Williams wrote:
We recently upgraded to GCC 3.3.3 and now we can no longer compile ruby
due to its use of some obsoleted constructs.
Ruby successfully compiled the latest stable snapshot with 3.3.3, so
perhaps you should move to that until the next release is made.
Andrew Walrond wrote:
We recently upgraded to GCC 3.3.3 and now we can no longer compile ruby
due to its use of some obsoleted constructs.
Ruby successfully compiled the latest stable snapshot with 3.3.3, so
perhaps you should move to that until the next release is made.
Or, in English I have successfully compiled the latest Ruby ‘stable
snapshot’ with gcc 3.3.3, so use that until a new release is made.
Thanks for the clarification
I’ve since discovered that everything is perfectly happy on Linux, but
the mkmf stuff is screwing everything up on HPUX. We’ve typically had
to fix things a bit on HPUX, but nothing ever showed up as strangely as
what we’re seeing now. Seeing as it was a header specifically rejected
by the new version, I didn’t immediately identify it as a configure problem.
Depending on how we configure the make process, sometimes we see the
above error, sometimes we get link failures with crypto.
Haven’t sorted it out yet.
···
On Friday 05 Mar 2004 19:12, Andrew Walrond wrote:
On Friday 05 Mar 2004 16:04, Brett Williams wrote: