PR16923 failure on darwin

Jack Howarth
Mon Feb 15 16:59:00 GMT 2010

   In the process of starting to debug the failure of the
PR16923 libjava testcase on x86_64-apple-darwin10, I discovered
that the actual failure is masked by an issue with the testcase
picking the wrong libiconv to link against. Currently the failure
appears as...

Executing on host: /sw/src/ -B/sw/src/ /sw/src/   -bind_at_load -multiply_defined suppress -I. -I.. -I/sw/src/ -I/sw/src/ -I/sw/src/ -fdollars-in-identifiers -L/sw/src/ -ljvm -shared-libgcc -lgcj -liconv  -lm   -o PR16923    (timeout = 300)
PASS: PR16923.c compilation
set_ld_library_path_env_vars: ld_library_path=.:/sw/src/
Setting LD_LIBRARY_PATH to .:/sw/src/
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _libiconv
  Referenced from: /sw/src/
  Expected in: flat namespace
 in /sw/src/
FAIL: PR16923 run
UNTESTED: PR16923 output

when FSF gcc trunk is built as...

Compiler version: 4.5.0 20100214 (experimental) (GCC) 
Platform: x86_64-apple-darwin10.3.0
configure flags: --prefix=/sw --prefix=/sw/lib/gcc4.5 --mandir=/sw/share/man --infodir=/sw/share/info --enable-languages=c,c++,fortran,objc,obj-c++,java --with-gmp=/sw --with-libiconv-prefix=/sw --with-ppl=/sw --with-cloog=/sw --with-mpc=/sw --with-system-zlib --x-includes=/usr/X11R6/include --x-libraries=/usr/X11R6/lib --disable-libjava-multilib

Note that all of the binaries in FSF gcc are actually linked against the libiconv from /sw/lib, but the testcase ends up
defaulting to the system libiconv in /usr/lib causing the missing symbol. I noticed that we have...

# This spec file is read by gcj when linking.
# It is used to specify the standard libraries we need in order
# to link with libgcj.
%rename startfile startfileorig
*startfile:  %(startfileorig)

%rename lib liborig
*lib:  %{s-bc-abi:} -lgcj  -lm -L/sw/lib -liconv  -lpthread -lz -allow_stack_execute  -ldl %(libgcc)  %(liborig)

*jc1: -fhash-synchronization -fuse-divide-subroutine -fcheck-references -fuse-boehm-gc -fnon-call-exceptions     -fkeep-inline-functions

for libgcj.spec on this build of darwin but there isn't anything done to direct gcc to the correct libiconv.
Any ideas on how we can make the PR16923 testcase smarter about finding the actual libiconv that FSF gcc is
built against?
ps If I repeat the compilation of PR16923 with -L/sw/lib -liconv, the resulting binary crashes with...

./PR16923Assertion failed: (class_id), function main, file /sw/src/, line 35.Abort

I'll try to debug this under darwin9 (where I can walk through the FSF libgcc unwinder) to see
what exactly is causing this assertion.

More information about the Java mailing list