Current build failure when libgcj is enabled on i386-unknown-freebsd4.2

Loren James Rittle rittle@latour.rsch.comm.mot.com
Tue Apr 24 19:56:00 GMT 2001


I am now led to believe that someone wants this information, thus I
will post it.  I mainly work on libstdc++-v3 for this platform not
java but way back when I volunteered to check on java status once and
a while.

$gcc-mainline-src is the gcc mainline with this patch of interest
(which is required or else libgcj ends up in noconfigdirs):

Index: configure.in
===================================================================
RCS file: /cvs/gcc/egcs/configure.in,v
retrieving revision 1.99
diff -c -r1.99 configure.in
*** configure.in        2001/04/23 16:47:08     1.99
--- configure.in        2001/04/25 01:49:05
***************
*** 801,806 ****
--- 801,808 ----
    i[3456]86-*-beos*)
       noconfigdirs="$noconfigdirs gdb target-newlib target-libgloss"
       ;;
+   i[3456]86-*-freebsd*)
+     ;;
    m68k-*-elf*)
      noconfigdirs="${libgcj}"
      if [ x${is_cross_compiler} != xno ] ; then

No other patches were in the tree except some completely unrelated
dwarf2 configuration patches.  Next is the top-level configure command
line and bootstrap step, where --enable-threads=posix is absolutely
required to get the rest of gcc to build in a way compatible with the
existing system compiler.

; $gcc-mainline-src/configure --enable-threads=posix --enable-languages=c,c++,java --with-dwarf2
; make bootstrap
[...]
/bin/sh ./libtool --mode=link /usr/users/rittle/tmp/gcc-build-latour-mainline-0424/gcc/xgcc -B/usr/users/rittle/tmp/gcc-build-latour-mainline-0424/gcc/ -B/usr/local/beta-gcc/i386-unknown-freebsd4.2/bin/ -B/usr/local/beta-gcc/i386-unknown-freebsd4.2/lib/ -isystem /usr/local/beta-gcc/i386-unknown-freebsd4.2/include -I././targ-include -I/usr/users/rittle/outside-cvs-src/gcc-mainline/boehm-gc/./libc/include -fno-builtin -g -O2  -o libgcjgc.la  -version-info 1:1:0 -rpath /usr/local/beta-gcc/lib allchblk.lo alloc.lo blacklst.lo checksums.lo dbg_mlc.lo dyn_load.lo finalize.lo gcj_mlc.lo headers.lo hpux_irix_threads.lo linux_threads.lo malloc.lo mallocx.lo mark.lo mark_rts.lo misc.lo new_hblk.lo obj_map.lo os_dep.lo pcr_interface.lo ptr_chck.lo real_malloc.lo reclaim.lo solaris_pthreads.lo solaris_threads.lo stubborn.lo typd_mlc.lo mach_dep.lo -lpthread 
/usr/users/rittle/tmp/gcc-build-latour-mainline-0424/gcc/xgcc -B/usr/users/rittle/tmp/gcc-build-latour-mainline-0424/gcc/ -B/usr/local/beta-gcc/i386-unknown-freebsd4.2/bin/ -B/usr/local/beta-gcc/i386-unknown-freebsd4.2/lib/ -isystem /usr/local/beta-gcc/i386-unknown-freebsd4.2/include -shared  .libs/allchblk.o .libs/alloc.o .libs/blacklst.o .libs/checksums.o .libs/dbg_mlc.o .libs/dyn_load.o .libs/finalize.o .libs/gcj_mlc.o .libs/headers.o .libs/hpux_irix_threads.o .libs/linux_threads.o .libs/malloc.o .libs/mallocx.o .libs/mark.o .libs/mark_rts.o .libs/misc.o .libs/new_hblk.o .libs/obj_map.o .libs/os_dep.o .libs/pcr_interface.o .libs/ptr_chck.o .libs/real_malloc.o .libs/reclaim.o .libs/solaris_pthreads.o .libs/solaris_threads.o .libs/stubborn.o .libs/typd_mlc.o .libs/mach_dep.o  -lpthread  -Wl,-soname -Wl,libgcjgc.so.1 -o .libs/libgcjgc.so.1
/usr/local/beta-gcc/bin/ld: cannot find -lpthread
collect2: ld returned 1 exit status
gmake[1]: *** [libgcjgc.la] Error 1
gmake[1]: Leaving directory `/usr/users/rittle/tmp/gcc-build-latour-mainline-0424/i386-unknown-freebsd4.2/boehm-gc'
gmake: *** [all-target-boehm-gc] Error 2

OK, the obvious problem is that boehm-gc assumes that libpthread
exists on the system.  It does not on this system.  Other parts of the
gcc build machinery on this platform (i.e. libgcc and libstdc++-v3,
before it no longer referenced the thread library directly) use
-pthread (which is the correct way to do it on this platform) to find
all libraries needed to support POSIX threads.

Unfortunately, there is a deeper issue not immediately visible.
During the configuration of boehm-gc, it doesn't detect the mismatch
between the configuration requested and the fact that there is no code
path for generic POSIX threads.  It appears that this version of
boehm-gc only supports POSIX threads on some platforms even though
additional platforms support the required POSIX pthread_* API.

Regards,
Loren



More information about the Java mailing list