+++ This bug was initially created as a clone of Bug #38743 +++ I'm building gcc 4.4.0 20090106 on OpenSolaris (32 bit boot mode). The file trunk/libjava/configure checks if 64 bit code can executed on a 32 bit platform when configuring for the i386-pc-solaris2.11/amd64/libgcc directory. # prev-gcc/xgcc -v Using built-in specs. Target: i386-pc-solaris2.11 Configured with: ../gcc_trunk/configure --enable-languages=ada,c,c++,fortran,java,objc,obj-c++ --enable-shared --disable-static --enable-decimal-float --with-long-double-128 --enable-nls --with-included-gettext --enable-gather-detailed-mem-stats --with-stabs --enable-debug -enable-largefile --enable-symvers --without-system-zlib --enable-gtk-cairo --enable-qt-peer --enable-xmlj --enable-gconf-peer --enable-gjdoc --enable-java-awt=gtk,xlib,qt,x --enable-gc-debug --enable-libgcj-debug --enable-objc-gc --enable-libstdcxx-debug --disable-stage1-checking --enable-checking=release --without-system-libunwind --with-gnu-as --with-as=/usr/local/bin/as --with-gnu-ld --with-ld=/usr/local/bin/ld Thread model: posix gcc version 4.4.0 20090111 (experimental) [trunk revision 143259] (GCC) #ggrep -B10 cross i386-pc-solaris2.11/amd64/libjava/config.log configure:2383: checking for C compiler default output file name configure:2386: /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -g -O2 conftest.c >&5 configure:2389: $? = 0 configure:2437: result: a.out configure:2442: checking whether the C compiler works configure:2448: ./a.out ./a.out: ./a.out: cannot execute [Exec format error] configure:2451: $? = 126 configure:2470: result: yes configure:2477: checking whether we are cross compiling configure:2479: result: yes # isainfo -k i386 To push past this point I simply edited trunk/libjava/configure (as I did in Bug #38743) and commented out the exit when the test failed (since I do not need execs in that dir): echo "$as_me: error: in \`$ac_pwd':" >&2;} { { echo "$as_me:$LINENO: error: cannot run C compiled programs. If you meant to cross compile, use \`--host'. See \`config.log' for more details." >&5 echo "$as_me: error: cannot run C compiled programs. If you meant to cross compile, use \`--host'. See \`config.log' for more details." >&2;} # { (exit 1); exit 1; }; }; } # Line 2466 }; } fi fi fi echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 Thanks, Rob
sigh ... and: trunk/libjava/classpath/configure Doing this to find them all: # { (exit 1); exit 1; }; }; } # Added - OpenSolaris - not cross compiling }; } cross_compiling=no
Changed that hack to: # { (exit 1); exit 1; }; }; } # Added - OpenSolaris - not cross compiling }; } fi fi fi cross_compiling=no echo "$as_me:$LINENO: result: yes" >&5 echo "${ECHO_T}yes" >&6 --------- We do have executables in this directory (unlike for libgcc) so the quick hack quickly fails ... File: i386-pc-solaris2.11/amd64/libjava/config.log ... configure:25790: checking size of void * configure:26113: /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -o conftest -g -O2 conftest.c >&5 configure:26116: $? = 0 configure:26118: ./conftest ./conftest: ./conftest: cannot execute [Exec format error] configure:26121: $? = 126 configure: program exited with status 126 configure: failed program was: ... configure:26130: error: in `/usr/share/src/gcc_build/i386-pc-solaris2.11/amd64/libjava':
There are a dozen occurances of this line in file: trunk/libjava/configure ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS >&5' I changed them to this and the hack let the build continue: ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS -m32 >&5'
Hmm, automake should have done the correct thing ...
# Even if the default multilib is not a cross compilation, # it may be that some of the other multilibs are. if test $cross_compiling = no && test $multilib = yes \ && test "x${with_multisubdir}" != x ; then cross_compiling=maybe fi
(In reply to comment #5) > # Even if the default multilib is not a cross compilation, > # it may be that some of the other multilibs are. > if test $cross_compiling = no && test $multilib = yes \ > && test "x${with_multisubdir}" != x ; then > cross_compiling=maybe > fi > Yes, it's a little screwy. If 64 bit code can not be executed on a 32 bit platform then you MUST be 'cross compiling'. I think the term it is looking for is 'building multilib'. Other circumstances include "co-processing". You want to compile for your favorite hardware, Xbox or PSP, and you execute a portion of gcc's build on the device, both for speed and accuracy of the values determined by the configure scripts. The 'hardware' can also be "fake" like Qemu. There is also the situation where you have the hardware you are compiling for and could execute the program and libraries on the device. This helps to get the real values for fixing scripts used to cross compile. The gdb program can help run "make -i check" on your hardware remotely. Maybe the Docs need this explanation: What if you have a 486 and want to build 32/64 bit execs/libs for a 686. That is cross compiling and multilib, regardless of boot mode. Up in family or "cross" family is cross compiling. What if you have a 686 and want to build 32/64 bit execs/libs for a 686. That is building multilib, regardless of boot mode. Same family, no cross. What if you have a 686 and want to build 32/64 bit execs/libs for a 486. That is building multilib, regardless of boot mode. Down in family is not cross compiling. Building any of the above combinations with either only 32 bit _or_ only 64 bit execs/libs means you are not building multilib. Building for a higher number in the family or "cross" to a different (and non-compatible) family is cross compiling. A quick mention for completeness that cross platform (or ABI) compiling is not "cross compiling" in the usual sense though the same techniques can be used to get gcc to run under Cygwin (a Linux Simulation for Windows (and others)) or Wine (a Windows Simulation for Linux (and others)) by using bootstrapping and cross compiling. I don't know why this 32/64 bit issue comes up so often. We've had 64 bit OSes for a few years now. It must be the VM that is new and confusing ;(o Also, the dozen occurrences of the 'ac_link' variable is redundant. Rob
Let me clarify the accuracy of my meaning: When I said: "Down in family is not cross compiling." I meant for the purposes of being able to execute 'target' code on the 'host', 'build' or 'target' platform (as when executables that create source code are ran during the build). Technically speaking, _ANY_ difference in 'host', 'build' or 'target' processor, even a _small_ revision, makes it a "cross compile"; we care most (during the build) if we can execute our utilities. --- That reminds me. It would be great if there were a ./configure option to specify a script that would "enable" the other hardware. It could 'wake-up' real hardware and ask it to download / execute / upload results of some code. It could run WINE or QEmu and execute the utility on the target to allow easier cross-porting. A set of 'gnokii-like' scripts could create a simple framework to allow gdb to remotely execute code (port gcc to your cellphone's Operating System). I run gcc to cross compile for my router (Linux 2.6) and cellphone (Symbian). Rob Rob
>Other circumstances include "co-processing". You want to compile for your favorite hardware, Xbox or PSP HEHE, funny you mentioned the PSP, you know that I work for Sony on their GCC for PS3 compilers. So I cross compile all the time really. Anyways most of this bug report is not really the issue here.
(In reply to comment #4) > Hmm, automake should have done the correct thing ... (In reply to comment #5) > # Even if the default multilib is not a cross compilation, > # it may be that some of the other multilibs are. > if test $cross_compiling = no && test $multilib = yes \ > && test "x${with_multisubdir}" != x ; then > cross_compiling=maybe > fi Along the same lineage of problems (do you want a new report) we have trouble checking for features in libgomp (and probably elsewhere). The logic is actually 'backward'; 64 bit is available and 32 bit is not available (on a 32 bit boot): OK : gcc_build/i386-pc-solaris2.11/amd64/libgomp/config.log : configure:18855: checking whether the target supports __sync_*_compare_and_swap configure:18877: /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -m64 -o conftest -g -O2 -pthread -pthread -Wall -Werror conftest.c >&5 configure:18883: $? = 0 configure:18887: test -z || test ! -s conftest.err configure:18890: $? = 0 configure:18893: test -s conftest configure:18896: $? = 0 configure:18908: result: yes Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log : configure:18855: checking whether the target supports __sync_*_compare_and_swap configure:18877: /usr/share/src/gcc_build/./gcc/xgcc -B/usr/share/src/gcc_build/./gcc/ -B/usr/local/i386-pc-solaris2.11/bin/ -B/usr/local/i386-pc-solaris2.11/lib/ -isystem /usr/local/i386-pc-solaris2.11/include -isystem /usr/local/i386-pc-solaris2.11/sys-include -o conftest -g -O2 -pthread -Wall -Werror conftest.c >&5 /var/tmp//cc80a43R.o: In function `main': /usr/share/src/gcc_build/i386-pc-solaris2.11/libgomp/conftest.c:43: undefined reference to `__sync_val_compare_and_swap_4' collect2: ld returned 1 exit status configure:18883: $? = 1 configure: failed program was: | /* confdefs.h. */ | | #define PACKAGE_NAME "GNU OpenMP Runtime Library" | #define PACKAGE_TARNAME "libgomp" | #define PACKAGE_VERSION "1.0" | #define PACKAGE_STRING "GNU OpenMP Runtime Library 1.0" ... | #define LIBGOMP_GNU_SYMBOL_VERSIONING 1 | /* end confdefs.h. */ | | int | main () | { | int foo, bar; bar = __sync_val_compare_and_swap(&foo, 0, 1); | ; | return 0; | } configure:18908: result: no So ./configure will set us to use compare_and_swap() in 64 bit mode (when I or someone else boot to that mode) but in 32 bit mode (which I am currently in) the compare_and_swap() is not available - hmmm ... I'll bet configure never _tested_ that the 64 bit code links. hehe Rob
>Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log : No, it is not broken at all. __sync_val_compare_and_swap_4 cannot be used with x86 explicit -march=i686 is used as the default really is to compile for i486 really.
(In reply to comment #10) > >Broken : gcc_build/i386-pc-solaris2.11/libgomp/config.log : > > No, it is not broken at all. __sync_val_compare_and_swap_4 cannot be used with > x86 explicit -march=i686 is used as the default really is to compile for i486 > really. So it should not say: configure:18855: checking whether the target supports __sync_*_compare_and_swap configure:18908: result: yes We _might_ get a small reduction of the occurrences of Bug 38743 (and this Bug 38804) if we alter this line in "maintainer-scripts/gcc_release" : # gdiff -Naur maintainer-scripts/gcc_release maintainer-scripts/gcc_release_new --- maintainer-scripts/gcc_release 2009-01-18 05:21:52.485084055 -0800 +++ maintainer-scripts/gcc_release_new 2009-01-18 09:03:35.186299275 -0800 @@ -205,7 +205,7 @@ inform "Building compiler" OBJECT_DIRECTORY=../objdir contrib/gcc_build -d ${SOURCE_DIRECTORY} -o ${OBJECT_DIRECTORY} \ - -c "--enable-generated-files-in-srcdir --disable-multilib" build || \ + -c "--enable-generated-files-in-srcdir --enable-multilib" --enable-checking=release build || \ error "Could not rebuild GCC" fi Thanks, Rob
It has always been the case that configure needs to be able to execute code for all multilibs. If you have a target where this is not possible (like Solaris or IRIX), you need to configure with --disable-multilibs (or on some targets restrict the set of multilibs built). This has nothing to do with libgcj, but affects most target libraries. A documentation issue probably. Rainer
(In reply to comment #12) > It has always been the case that configure needs to be able to execute code > for all multilibs. If you have a target where this is not possible (like > Solaris or IRIX), you need to configure with --disable-multilibs (or on some > targets restrict the set of multilibs built). This has nothing to do with > libgcj, but affects most target libraries. > > A documentation issue probably. > > Rainer It has been over 2 and a half years since the Post prior to yours. A lot has changed since then (I don't think we compile LibJava anymore and we now have (proper) 64-Bit support for this Platform). As long as the Docs are up to date (assuming 64-Bit Compile is working) then this Bug could be closed. I've been waiting to get a Bulldozer running before I contribute here further as my current Computer is too old to be of much help here. I expect to be back in 6 months.
Closing as won't fix as libgcj (and the java front-end) has been removed from the trunk.