Frank Jensen <Frank.Jensen(a)hugin.com&gt; writes: > I just tried to install XEmacs 21.4.17 on Solaris 9 using gcc 3.4.3. > That resulted in the following error: > > bytecode.c: In function `invalid_byte_code_error': > bytecode.c:1494: error: incompatible type for argument 1 of `__builtin_va_start' > bytecode.c:1497: error: incompatible type for argument 1 of `__builtin_va_end' > > I then searched the archive for information regarding this bug, but I > only found the email appended below. I managed to track down the > cause of this bug. It turns out that the problem is caused by the > src/s/sol2.h header file, which overrides the gcc definition for > va_list. This happens to work with gcc 2.95.3, but it doesn't work > with gcc 3.4.3 (or gcc 3.4.2). If the header file is changed as shown > below, XEmacs will (at least) compile with gcc 2.95.3 and gcc 3.4.3 on > Solaris 8 (Sparc) and Solaris 9 (x86), which are the configurations I > have available for testing. > > Here is the snippet of the src/s/sol2.h file that I changed: > > # if __GNUC__ <= 2 > /* GCC va_list munging is a little messed up */ > #define __GNUC_VA_LIST > #define _VA_LIST_ > #define _VA_LIST va_list > typedef void *__gnuc_va_list; > typedef __gnuc_va_list va_list; > # endif > Interesting. On a Solaris 5.8 system here at work, I've built XEmacs 21.4.17 with gcc 3.4.3. Here is the Installation file: uname -a: SunOS denver 5.8 Generic_108528-14 sun4u sparc SUNW,Ultra-5_10 Solaris ../software/SunOS-5.8/src/xemacs-21.4-2005-02-10/configure '--prefix=/u/sheltonv/software/SunOS-5.8/xemacs-21.4-2005-02-10' '--with-gcc' '--cflags= -O2 -pipe -ffast-math -fno-exceptions' '--site-includes=/u/sheltonv/software/SunOS-5.8/include' '--site-libraries=/u/sheltonv/software/SunOS-5.8/lib' '--infopath=/u/sheltonv/software/SunOS-5.8/info' '--with-mule=no' '--with-dialogs=no' '--with-widgets=no' '--package-path=/u/sheltonv/software/SunOS-5.8/site-packages::/u/sheltonv/software/SunOS-5.8/xemacs-packages' '--pdump=no' '--debug=no' '--error-checking=none' XEmacs 21.4.17 "Jumbo Shrimp" configured for `sparc-sun-solaris2.8'. Compilation / Installation: Source code location: /u/sheltonv/software/src/xemacs-21.4-2005-02-10 Installation prefix: /u/sheltonv/software/SunOS-5.8/xemacs-21.4-2005-02-10 Additional header files: /u/sheltonv/software/SunOS-5.8/include Additional libraries: /u/sheltonv/software/SunOS-5.8/lib Runtime library search path: /usr/ccs/lib:/u/sheltonv/software/SunOS-5.8/lib:/usr/openwin/lib:/u/sheltonv/software/SunOS-5.8/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.8/3.4.3/../../.. Operating system description file: `s/sol2.h' Machine description file: `m/sparc.h' Compiler: gcc -O2 -pipe -ffast-math -fno-exceptions Compiler version: gcc (GCC) 3.4.3 Compiler specs file: /u/sheltonv/software/SunOS-5.8/gcc-3.4.3/lib/gcc/sparc-sun-solaris2.8/3.4.3/specs Relocating allocator for buffers: yes GNU version of malloc: yes libc: SUNWcsl 11.8.0,REV=2000.01.08.18.12 Window System: Compiling in support for the X window system: - X Windows headers location: /usr/openwin/include - X Windows libraries location: /usr/openwin/lib - Handling WM_COMMAND properly. Using Lucid menubars. Using Lucid scrollbars. TTY: Images: Compiling in support for GIF images (builtin). Compiling in support for XPM images. Compiling in support for PNG images. Compiling in support for JPEG images. Compiling in support for TIFF images. Sound: Compiling in support for sound (native). Databases: Compiling in support for DBM. Compiling in support for LDAP. Internationalization: Mail: Compiling in support for "dot-locking" mail spool file locking method. Other Features: Inhibiting IPv6 canonicalization at startup. Compiling in support for ToolTalk. Compiling in support for dynamic shared object modules. Is this a difference between Solaris 8 and Solaris 9?

Vin Shelton writes: > Compiler: gcc -O2 -pipe -ffast-math -fno-exceptions I notice that you are not using the -fno-strict-aliasing "pessimization" option, which is used when "configure" itself decides the compiler options. Since this option is usually used when the source code makes dubious casts, I was wondering whether it is considered no longer needed?

> Compiler version: gcc (GCC) 3.4.3 Hmm. My output says: Compiler version: gcc: `-V' option must have argument Are you using modified source code?

Vin Shelton <acs(a)xemacs.org&gt; wrote: > Frank Jensen <Frank.Jensen(a)hugin.com&gt; writes: [snip] > IIRC, this option is no longer needed. We fixed the aliasing problems > some time ago in the 21.4 code base. Errrrr.... Did we? There are still several aliasing problems in 21.5.

> Nope. Jerry put the ability to check compiler version in awhile ago. > My build script specifies a compiler of CC=gcc; I wonder if that makes a > difference? Who, moi? I contributed the checker for icc and icpc last April, but the general framework was put together by Valdis Kletnieks, was it not?

In any case, the info docs for gcc 3.4 say that the -V flag is to run a specific version of gcc. To get the version, you're supposed to use --version. In fact, that's what configure.in *is* using for gcc. It looks like the logic starting at the line that says: AC_MSG_CHECKING(for compiler version information) must be slightly awry for Frank's case. The test: if test "$GCC" = "yes"; then must be failing for Frank, dropping him into the machine-specific code, which results in this code being executed: *-*-solaris*) compiler_version=`$XEMACS_CC -V 2>&1 | head -1`

>>>>> "vin" == Vin Shelton <acs(a)xemacs.org&gt; writes: vin> There could still be lingering problems, but I think we had vin> to fix all the aliasing problems when we moved from gcc-2.95. I don't see how that's possible to verify in a non-union build, unless you know the optimization strategies.

Vin Shelton <acs(a)xemacs.org&gt; wrote: > Frank Jensen <Frank.Jensen(a)hugin.com&gt; writes: [snip] > IIRC, this option is no longer needed. We fixed the aliasing problems > some time ago in the 21.4 code base. Errrrr.... Did we? There are still several aliasing problems in 21.5. >> > Compiler version: gcc (GCC) 3.4.3 >> >> Hmm. My output says: >> >> Compiler version: gcc: `-V' option must have argument >> >> Are you using modified source code? > > Nope. Jerry put the ability to check compiler version in awhile ago. > My build script specifies a compiler of CC=gcc; I wonder if that makes a > difference? Who, moi? I contributed the checker for icc and icpc last April, but the general framework was put together by Valdis Kletnieks, was it not? In any case, the info docs for gcc 3.4 say that the -V flag is to run a specific version of gcc. To get the version, you're supposed to use --version. In fact, that's what configure.in *is* using for gcc. It looks like the logic starting at the line that says: AC_MSG_CHECKING(for compiler version information) must be slightly awry for Frank's case. The test: if test "$GCC" = "yes"; then must be failing for Frank, dropping him into the machine-specific code, which results in this code being executed: *-*-solaris*) compiler_version=`$XEMACS_CC -V 2>&1 | head -1` Frank, are you passing either --compiler or --xemacs-compiler to the configure script? Do you have CC set in your environment? If so, what value(s)?