Currently libjava is being improperly linked (PR java/41991) due to the presence of -lm and -lpthreads on the shared library linkages. This causes libSystem.dylib to be pushed to the front of the linkage and breaks the logic used by libgcc_ext. We should add and set defines for HAVE_LIBSYSTEM_PTHREADS and HAVE_LIBSYSTEM_LIBMATH to configure and use these for conditionals in the Makefile.am's where appropriate to avoid passing -lm and -lpthread on darwin.
Subject: Re: New: linkage on -lm and -lpthread should be purged from darwin build What about removing those in the driver? This way it works correctly for other makefiles too? On Aug 11, 2010, at 9:30 AM, "howarth at nitro dot med dot uc dot edu" <gcc-bugzilla@gcc.gnu.org> wrote: > Currently libjava is being improperly linked (PR java/41991) due to > the > presence of -lm and -lpthreads on the shared library linkages. This > causes > libSystem.dylib to be pushed to the front of the linkage and breaks > the logic > used by libgcc_ext. We should add and set defines for > HAVE_LIBSYSTEM_PTHREADS > and HAVE_LIBSYSTEM_LIBMATH to configure and use these for > conditionals in the > Makefile.am's where appropriate to avoid passing -lm and -lpthread > on darwin. > > > -- > Summary: linkage on -lm and -lpthread should be purged from > darwin build > Product: gcc > Version: 4.6.0 > Status: UNCONFIRMED > Severity: normal > Priority: P3 > Component: target > AssignedTo: unassigned at gcc dot gnu dot org > ReportedBy: howarth at nitro dot med dot uc dot edu > GCC build triplet: *-apple-darwin* > GCC host triplet: *-apple-darwin* > GCC target triplet: *-apple-darwin* > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45258 >
Created attachment 21459 [details] proposed patch to add and use remove-outfile The proposed patch implements remove-outfile to parse out -lm and -lpthread from LINK_SPEC in darwin.h.
Note that while the proposed patch properly parses out -lm and -lpthread from linkages done with the compiler, this is insufficient to solve the problems with libjava. The hard coded use of -lm in libjava/Makefile.am has to be fixed as well since this links directly with ld via libtool.
Opps. Forgot about -ldl.
Created attachment 21466 [details] final patch to add remove-outfile support for darwin.
Created attachment 21467 [details] patch to eliminate remaining -lm and -lpthread usage in libjava build
The combination of the remove_outfile.diff and libjava_lm_lpthread_cleanup.diff patches eliminates the incorrect linkage position of libSystem in the libjava shared libraries on darwin. Will regression test next on x86_64-apple-darwin10.
These patches also appear to clean up the linkages on libstdc++.6.dylib and libgfortran.3.dylib so that now libSystem is properly at the end of the linkage. It will be interesting to see if these patches help eliminate the random failures I have seen with... FAIL: tr1/2_general_utilities/shared_ptr/thread/default_weaktoshared.cc execution test in the libstdc++ testsuite.
The remove_outfile.diff patch has the additional advantage of also eliminating the gcc.dg/torture/builtin-math-7.c failures.
Posted patches to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00886.html and http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00887.html. Testsuite results posted at http://gcc.gnu.org/ml/gcc-testresults/2010-08/msg01232.html.
(In reply to comment #10) > Posted patches to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00886.html and > http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00887.html. Jack, based on the above, can this be closed now? Thanks.
(In reply to comment #11) > (In reply to comment #10) > > Posted patches to http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00886.html and > > http://gcc.gnu.org/ml/gcc-patches/2010-08/msg00887.html. > > Jack, based on the above, can this be closed now? Thanks. Ralf, Yes. Current gcc trunk always ends up with -lSystem last for the gcc build itself. I had been considering creating a version_compare_remove_outfile spec function to handle all the other symlinks of libSystem but this is impossible to implement. Closing as fixed.
Author: mrs Date: Mon Jan 10 19:41:39 2011 New Revision: 168639 URL: http://gcc.gnu.org/viewcvs?root=gcc&view=rev&rev=168639 Log: 2010-08-17 Jack Howarth <howarth@bromo.med.uc.edu> PR target/45258 * gcc.c (spec_function): Add remove-outfile. (remove_outfile_spec_function): New function. * config/darwin.h (LINK_SPEC): Add removal of -ldl, -lm and -lpthread. * invoke.texi (replace-outfile): Document. Modified: trunk/gcc/ChangeLog-2010
if we could get Java and libquadmath to intercept the new LINK_GCC_C_SEQUENCE_SPEC instead of re-writing the *lib sequence it would give us a little more room to maneuver. .. as it is when another part of the complier hijacks the *lib sequence it happens too late for the target to intervene -- anything inserted as a '-l*' is untouchable at that stage. if we have the option to re-write from the start of LINK_GCC_C_SEQUENCE_SPEC we're in with a chance... otherwise .. the only solution then is to apply target-specific stuff in the lib/java builds.
Iain, I was referring to the conceptual problems of creating a version-compare-remove-outfile spec function. For any given OS release there is a different set of symlinks for libSystem which are visible to the compiler regardless of the setting of -mmacosx-version-min=. So one would really have to have version-compare-remove-outfile look only at the running OS version to decide properly which symlinks are present to prune.