[Bug bootstrap/38804] New: gcc 4.4.0 20090111 - The configure for $BUILD/amd64/libjava checks if 64 bit code can exec on 32 bit platform

[Bug bootstrap/38804] New: gcc 4.4.0 20090111 - The configure for $BUILD/amd64/libjava checks if 64 bit code can exec on 32 bit platform

[rob1weld at aol dot com]

+++ 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


-- 
           Summary: gcc 4.4.0 20090111 - The configure for
                    $BUILD/amd64/libjava checks if 64 bit code can exec on
                    32 bit platform
           Product: gcc
           Version: 4.4.0
            Status: UNCONFIRMED
          Severity: major
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: rob1weld at aol dot com
 GCC build triplet: i386-pc-solaris2.11
  GCC host triplet: i386-pc-solaris2.11
GCC target triplet: i386-pc-solaris2.11


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug bootstrap/38804] gcc 4.4.0 20090111 - The configure for $BUILD/amd64/libjava checks if 64 bit code can exec on 32 bit platform

[rob1weld at aol dot com]

------- Comment #1 from rob1weld at aol dot com  2009-01-11 15:37 -------
sigh ...

and: trunk/libjava/classpath/configure


Doing this to find them all:

#   { (exit 1); exit 1; }; }; }
# Added - OpenSolaris - not cross compiling
    }; }
cross_compiling=no


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug bootstrap/38804] gcc 4.4.0 20090111 - The configure for $BUILD/amd64/libjava checks if 64 bit code can exec on 32 bit platform

[rob1weld at aol dot com]

------- Comment #2 from rob1weld at aol dot com  2009-01-11 16:11 -------
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':


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug bootstrap/38804] gcc 4.4.0 20090111 - The configure for $BUILD/amd64/libjava checks if 64 bit code can exec on 32 bit platform

[rob1weld at aol dot com]

------- Comment #3 from rob1weld at aol dot com  2009-01-11 16:51 -------
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'


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[pinskia at gcc dot gnu dot org]

------- Comment #4 from pinskia at gcc dot gnu dot org  2009-01-13 00:45 -------
Hmm, automake should have done the correct thing ...


-- 

pinskia at gcc dot gnu dot org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|major                       |normal


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[pinskia at gcc dot gnu dot org]

------- Comment #5 from pinskia at gcc dot gnu dot org  2009-01-13 00:45 -------
# 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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[rob1weld at aol dot com]

------- Comment #6 from rob1weld at aol dot com  2009-01-13 07:16 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[rob1weld at aol dot com]

------- Comment #7 from rob1weld at aol dot com  2009-01-13 14:38 -------
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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[pinskia at gcc dot gnu dot org]

------- Comment #8 from pinskia at gcc dot gnu dot org  2009-01-13 20:39 -------
>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.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[rob1weld at aol dot com]

------- Comment #9 from rob1weld at aol dot com  2009-01-15 22:03 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[pinskia at gcc dot gnu dot org]

------- Comment #10 from pinskia at gcc dot gnu dot org  2009-01-15 22:16 -------
>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.  


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804

[Bug libgcj/38804] libgcj multilib fails if not able to exec "non" native programs

[rob1weld at aol dot com]

------- Comment #11 from rob1weld at aol dot com  2009-01-18 17:04 -------
(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


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=38804