From: Jack Howarth <howarth@bromo.med.uc.edu>
To: java@gcc.gnu.org
Subject: PR16923 failure on darwin
Date: Mon, 15 Feb 2010 16:59:00 -0000 [thread overview]
Message-ID: <20100215165856.GA9808@bromo.med.uc.edu> (raw)
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/fink.build/gcc45-4.4.999-20100213/darwin_objdir/gcc/xgcc -B/sw/src/fink.build/gcc45-4.4.999-20100213/darwin_objdir/gcc/ /sw/src/fink.build/gcc45-4.4.999-20100213/gcc-4.5-20100213/libjava/testsuite/libjava.jni/invocation/PR16923.c -bind_at_load -multiply_defined suppress -I. -I.. -I/sw/src/fink.build/gcc45-4.4.999-20100213/gcc-4.5-20100213/libjava/testsuite/libjava.jni -I/sw/src/fink.build/gcc45-4.4.999-20100213/gcc-4.5-20100213/libjava/testsuite/../include -I/sw/src/fink.build/gcc45-4.4.999-20100213/gcc-4.5-20100213/libjava/testsuite/../classpath/include -fdollars-in-identifiers -L/sw/src/fink.build/gcc45-4.4.999-20100213/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs -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/fink.build/gcc45-4.4.999-20100213/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs
Setting LD_LIBRARY_PATH to .:/sw/src/fink.build/gcc45-4.4.999-20100213/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs:.:/sw/src/fink.build/gcc45-4.4.999-20100213/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs
dyld: _dyld_bind_fully_image_containing_address() error
dyld: Symbol not found: _libiconv
Referenced from: /sw/src/fink.build/gcc45-4.4.999-20100213/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs/libgcj.11.dylib
Expected in: flat namespace
in /sw/src/fink.build/gcc45-4.4.999-20100213/darwin_objdir/x86_64-apple-darwin10.3.0/./libjava/.libs/libgcj.11.dylib
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?
Jack
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/fink.build/gcc45-4.4.999-20100213/gcc-4.5-20100213/libjava/testsuite/libjava.jni/invocation/PR16923.c, 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.
reply other threads:[~2010-02-15 16:59 UTC|newest]
Thread overview: [no followups] expand[flat|nested] mbox.gz Atom feed
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20100215165856.GA9808@bromo.med.uc.edu \
--to=howarth@bromo.med.uc.edu \
--cc=java@gcc.gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).