[Bug bootstrap/44107] New: libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Bug bootstrap/44107] New: libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis dot Excoffier at airbus dot com]

The symptoms are that for some inputs, my C++ program gets stuck after a
`throw' and before the corresponding `catch', with CPU running. With an
appropriate DYLD_LIBRARY_PATH, the problem disappears.

The problem comes IMHO from libgcc/config/t-slibgcc-darwin (lines 29-35) where
libgcc_s.10.5.dylib is _not_ built. Therefore it remains absent from
$(objdir)/gcc. However, in the `specs' located in this directory, it is
referenced from within the `*libgcc:' target (see also lines 400 and 405 of
gcc/config/darwin.h). Consequently, libstdc++.6.dylib contains a dependency
towards /usr/lib/libgcc_s.10.5.dylib (see line 577 of
libstdc++-v3/src/Makefile.in, /usr/lib is a default directory), and this
dependency remains in my C++ executable (dynamically linked). The symptoms
follow (see explanations under the description of the option `-shared-libgcc'
of GCC).

I modified libgcc/config/t-slibgcc-darwin in order to build libgcc_s.10.5.dylib
in all cases and everything is now perfect. Perhaps a better solution would be
to remove the -lgcc_s.10.5 from the build of libstdc++.6.dylib.

Hope this helps. I grabbed the 4.5-20100506 snapshot and found no change in
this area. All the above lines and files are from the 4.5.0 distribution.


-- 
           Summary: libstdc++ (dylib) is built with an erroneous dependency
                    towards /usr/lib
           Product: gcc
           Version: 4.5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: bootstrap
        AssignedTo: unassigned at gcc dot gnu dot org
        ReportedBy: Denis dot Excoffier at airbus dot com
 GCC build triplet: powerpc-apple-darwin9.8.0
  GCC host triplet: powerpc-apple-darwin9.8.0
GCC target triplet: powerpc-apple-darwin9.8.0


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

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[paolo dot carlini at oracle dot com]

------- Comment #1 from paolo dot carlini at oracle dot com  2010-05-13 08:41 -------
Mike, can you have a look?


-- 

paolo dot carlini at oracle dot com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikestump at comcast dot net


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

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[rguenth at gcc dot gnu.org]

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

Richard Guenther <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.6.1                       |---

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[mikestump at comcast dot net]

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

--- Comment #15 from Mike Stump <mikestump at comcast dot net> 2011-03-21 18:53:12 UTC ---
I'd trust the person doing the work.  :-)  They usually have more state on
exactly what problem they are fixing and if the work for any one bug covers the
problems in other bug reports completely or partially.  I prefer that as enough
work is put in to fix one bug report, that that bug report is then marked as
fixed, and other the other bug reports that are completely solved by it are
then marked as dup of that bug.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

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

--- Comment #14 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-21 08:24:19 UTC ---
(In reply to comment #13)
> (In reply to comment #12)
> > (In reply to comment #11)
> > > (In reply to comment #10)
> > > > (In reply to comment #8)
> > > So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
> > > (that tells us if we have a way forward)
> > duh ... make that version 'y'.
> If you take the pure distribution gcc-4.6.0-RC-20110314 and apply the two
> patches (the patch attached in #4 and included in #5), then
> - you can bootstrap without error (i can say for C and C++ for the time
>   being)
> - the xerces-c library compiles ok
> - my C++ program compiles ok
> - my C++ program executes ok with no DYLD_LIBRARY_PATH needed

Thanks Denis, that is very helpful testing - and you have, indeed, identified a
serious bug.  However,  I think that this set of tests indicates that the bug
is that we "emit eh_frames that are incompatible with the darwin
{8,9}-unwinder,10-compacter". 

Accordingly, I suggest that either we close this bug and refer to PR41991 - or
we re-name this one to reflect its underlying cause and make it a target bug;

Mike - any preference?

> - all the dylibs and executable around carry a dependency towards
>   /usr/lib/libgcc_s.1.dylib

hopefully, I have explained both that this is an intention of the current
design and why that design must be as it is.

If you can think of a viable alternative, I'd be very glad to read it.

... remembering that there are some system libraries and frameworks that are
closed source and therefore cannot be re-compiled by an end User - to say
nothing of any 3rd party commercial applications the User has installed that
were linked against a 'standard' system.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

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

--- Comment #13 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-21 06:46:26 UTC ---
(In reply to comment #12)
> (In reply to comment #11)
> > (In reply to comment #10)
> > > (In reply to comment #8)
> > So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
> > (that tells us if we have a way forward)
> duh ... make that version 'y'.
If you take the pure distribution gcc-4.6.0-RC-20110314 and apply the two
patches (the patch attached in #4 and included in #5), then
- you can bootstrap without error (i can say for C and C++ for the time
  being)
- the xerces-c library compiles ok
- my C++ program compiles ok
- my C++ program executes ok with no DYLD_LIBRARY_PATH needed
- all the dylibs and executable around carry a dependency towards
  /usr/lib/libgcc_s.1.dylib

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

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

--- Comment #12 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-20 21:06:30 UTC ---
(In reply to comment #11)
> (In reply to comment #10)
> > (In reply to comment #8)

> So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
> (that tells us if we have a way forward)

duh ... make that version 'y'.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

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

--- Comment #11 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-20 20:54:09 UTC ---
(In reply to comment #10)
> (In reply to comment #8)

> 
> Now comes the question of the beginning (which is also included in the title of
> this PR): why does my C++ program have (like in 'y' or 'z'+DYLD_LIBRARY_PATH)
> to use a /usr/lib/libgcc_s.1.dylib (dated 2007-10-06, 264016 bytes on my Darwin
> 9.8.0), when we could take advantage of the one in $(prefix)/lib (newer and
> only 89656 bytes), or none at all (like in 'x')?

libgcc_s (/usr/lib/libgcc_s.1.dylib) contains the unwinder for the system
(which is what you need for your try/catch stuff). 

We are not at liberty to change that - it belongs to the distribution and is
part of the suite of things Apple would update in event of security matters
arising.

(of course, you can overwrite Apple's lib, but then you take personal
responsibility for any issues that creates - including security ones ;) ).

Now the technical reason;
Any system library that links with /usr/lib/libgcc_s.1.dylib - uses the
unwinder from that.

If you wish (and we do wish for gcc to be capable of this) to be able to make
use of system libraries and frameworks - then _everyone_ MUST link the unwinder
in  /usr/lib/libgcc_s.1.dylib ... it's that simple.  There can only be one
unwinder in a single application.

Now - we don't want to give up the newer capabilities of libgcc - so we made
the libgcc_ext which allows you to use some newer math (and things like
emulated thread local storage).

> Second question, why is /usr/lib hardwired into t-slibgcc-darwin (line 31)?
> That fact, let it alone, is already suspicious for me...

maybe it should not be - we are living in someone else's house ;) 
... we must comply with the existing infrastructure...

===

You can do a whole load of things that _might_ work for your particular case -
- stand alone code that makes NO use of system libraries or frameworks is free
to use the FSF libgcc_s ... (and you can force that with DYLD_LIBRARY_PATH).

- but the configuration for gcc is intended to work in the general case (for
example, people want to be able to link libobjc and pieces from CoreFoundation)
...

====

So, my question is "does version 'x' work without a DYLD_LIBRARY_PATH set?"
(that tells us if we have a way forward)

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

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

--- Comment #10 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-20 20:34:37 UTC ---
(In reply to comment #8)
> "DYLD_PRINT_LIBRARIES=1 ./myexe " 
> is really useful for making sure that the libraries you think should be used
> actually are ;-)
This is great, thank you for the hint.

This shows that the sets 'y' (ie patched) and 'z' (ie unchanged) have a real
dependency towards /usr/lib/libgcc_s.1.dylib. The set 'x' (modif
t-slibgcc-darwin) does not have it. Perhaps (i don't know) it is inside anyway
(i mean statically) but i suppose that  if some libgcc_s.1.dylib must be
statically included, the one just-compiled will be chosen.

Now comes the question of the beginning (which is also included in the title of
this PR): why does my C++ program have (like in 'y' or 'z'+DYLD_LIBRARY_PATH)
to use a /usr/lib/libgcc_s.1.dylib (dated 2007-10-06, 264016 bytes on my Darwin
9.8.0), when we could take advantage of the one in $(prefix)/lib (newer and
only 89656 bytes), or none at all (like in 'x')?

Second question, why is /usr/lib hardwired into t-slibgcc-darwin (line 31)?
That fact, let it alone, is already suspicious for me...

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[howarth at nitro dot med.uc.edu]

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

--- Comment #9 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-20 12:42:52 UTC ---
Test results for WIP patch  from Comment 4 and 5 against gcc-4_6-branch under
Xcode 4.0...

http://gcc.gnu.org/ml/gcc-testresults/2011-03/msg01968.html

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

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

Iain Sandoe <iains at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.6.1

--- Comment #8 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-20 09:27:15 UTC ---
(In reply to comment #7)
> 1) In no configuration the bootstrap fails (as long as you take care of PR45381
> and PR47016).

PR45381 has been fixed in trunk and on the branch - I guess it will be fixed in
the release (I think there's another RC coming).  As already commented in
PR47016, this is a tool problem, not  a gcc bug (but, since I doubt any tool
fixes will be forthcoming for darwin < 11, we will endeavor to solve it somehow
;-) - patches welcome... )

> 2) Indeed, the DYLD_LIBRARY_PATH that makes things to work properly is
> DYLD_LIBRARY_PATH=$(prefix)/lib

If everything is linked correctly with proper rpaths, and the products are
installed - there should be no need for a DYLD_LIBRARY_PATH - it should only be
necessary for uninstalled testing.

> 3) I have built with the patch attached in #4 (together with the addition
> included in #5), it seems
> to work properly now (see configuration 'y' below).
> 
> 4) I have now 3 configurations (all with 4.6.0 RC 20110314)
> - 4.6.x: built with my modification (the change in t-slibgcc-darwin)
> - 4.6.y: built with the 2 patches from yesterday
> - 4.6.z: no change from the distribution
> I have also built the Xerces-C library 3 times, xerces-c-3.1.1x,
> xerces-c-3.1.1y and
> xerces-c3.1.1.z.
> The libxerces-c-3.1.dylib contains (iaw otool -L) a dependency towards
> /usr/lib/libgcc_s.1.dylib
> in the cases 'y' and 'z'. The libxerces-c-3.1.dylib contains a dependency
> towards /usr/lib/libSystem.B.dylib in the three configurations. My C++ program
> links with this library.
> 
> The sets 'x' and 'y' work properly. 

Hm, configuration 'x' is actually generically incorrect - it will _only_  work
providing you don't link with any library that is already linked with the
unwinder in /usr/lib/libgcc_s.1.dylib.   This is because there can only be
_one_ unwinder - the whole program must use the same one.

Some stand-alone programs are unaffected (including the gcc test-suite), but -
anything that uses stuff from gcc together with system frameworks is almost
certainly doomed...

set 'y' is correct (IMO) - and if the products are installed should work
without a DYLD_LIBRARY_PATH - assuming that everything has its correct paths...

The set 'z' does not work (stuck between
> throw and  catch, CPU running).

that, to me, confirms that the bug is in our emitting unwind that is
incompatible with the darwin 9 unwinder (a known issue, but without a specific
bug - it has been treated as part of PR41991 to date). 

I don't know when (or if) the patch will make it into gcc - but surely not for
4.6.0 it's too intrusive and the time has gone - for now, a local patch is
required - although it might be that fink/macports would decide to apply this
too.

hint: 
"DYLD_PRINT_LIBRARIES=1 ./myexe " 
is really useful for making sure that the libraries you think should be used
actually are ;-)

thanks for  testing!!

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

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

--- Comment #7 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-20 08:12:49 UTC ---
1) In no configuration the bootstrap fails (as long as you take care of PR45381
and PR47016).

2) Indeed, the DYLD_LIBRARY_PATH that makes things to work properly is
DYLD_LIBRARY_PATH=$(prefix)/lib

3) I have built with the patch attached in #4 (together with the addition
included in #5), it seems
to work properly now (see configuration 'y' below).

4) I have now 3 configurations (all with 4.6.0 RC 20110314)
- 4.6.x: built with my modification (the change in t-slibgcc-darwin)
- 4.6.y: built with the 2 patches from yesterday
- 4.6.z: no change from the distribution
I have also built the Xerces-C library 3 times, xerces-c-3.1.1x,
xerces-c-3.1.1y and
xerces-c3.1.1.z.
The libxerces-c-3.1.dylib contains (iaw otool -L) a dependency towards
/usr/lib/libgcc_s.1.dylib
in the cases 'y' and 'z'. The libxerces-c-3.1.dylib contains a dependency
towards /usr/lib/libSystem.B.dylib in the three configurations. My C++ program
links with this library.

The sets 'x' and 'y' work properly. The set 'z' does not work (stuck between
throw and
catch, CPU running).

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[howarth at nitro dot med.uc.edu]

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

--- Comment #6 from Jack Howarth <howarth at nitro dot med.uc.edu> 2011-03-19 22:02:58 UTC ---
 Doesn't the darwin linker developer's comments on PR48097
(http://gcc.gnu.org/bugzilla/show_bug.cgi?id=48097#c8) imply that libjava's
Throw2 test case is expected to fail on the current Apple system unwinder? Thus
your epilogue patch should be fine as it only regressed Throw2 for me.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

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

--- Comment #5 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-19 15:06:07 UTC ---

in addition to the attachment at c #4  - you'll also need this:

Index: gcc/toplev.c
===================================================================
--- gcc/toplev.c    (revision 171158)
+++ gcc/toplev.c    (working copy)
@@ -1338,9 +1338,10 @@ process_options (void)
   if (flag_rename_registers == AUTODETECT_VALUE)
     flag_rename_registers = flag_unroll_loops || flag_peel_loops;

-  if (flag_non_call_exceptions)
+  if (flag_non_call_exceptions 
+      && !global_options_set.x_flag_asynchronous_unwind_tables)
     flag_asynchronous_unwind_tables = 1;
-  if (flag_asynchronous_unwind_tables)
+  if (flag_asynchronous_unwind_tables || flag_non_call_exceptions)
     flag_unwind_tables = 1;

   if (flag_value_profile_transformations)

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[iains at gcc dot gnu.org]

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

--- Comment #4 from Iain Sandoe <iains at gcc dot gnu.org> 2011-03-19 15:00:14 UTC ---
Created attachment 23721
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=23721
work in progress patch to suppress unwind epilogues on Darwin

There was a change in gcc unwinding during 4.5 which is incompatible with the
system unwinders on Darwin 9 (and incompatible with the unwind compacter on
Darwin 10).  Specifically we now emit function epilogues.

This is an unreviewed, unapproved,  "work in progress" patch ; ergo, it has a
health warning that it might not be acceptable to the maintainers, even if it
works (which I think it does).

If this solves your problem then I think we should alter the description &c.
accordingly.

If it doesn't then, as Mike says, we'll need a reduced test-case to work on.

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[Denis.Excoffier at airbus dot com]

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

Denis Excoffier <Denis.Excoffier at airbus dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
            Version|4.5.0                       |4.6.0

--- Comment #2 from Denis Excoffier <Denis.Excoffier at airbus dot com> 2011-03-19 08:41:51 UTC ---
More or less the same applies for GCC 4.6.0 RC 20110314.

If i don't perform the modification indicated above in t-slibgcc-darwin (ie
force the build of libgcc_s_10.[45].dylib even when /usr/lib is not
$(shlib_slibdir), see line 31), the executable of my
(simple) C++ program gets stuck near its end (and never finishes).

[Bug bootstrap/44107] libstdc++ (dylib) is built with an erroneous dependency towards /usr/lib

[mikestump at comcast dot net]

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

--- Comment #3 from Mike Stump <mikestump at comcast dot net> 2011-03-19 09:49:35 UTC ---
> With an appropriate DYLD_LIBRARY_PATH, the problem disappears.

So, can you elaborate?  Which value makes the problem disappear?  I'd assume
you if you include $prefix/lib?

I fear this is going to be a hard bug...  If one wants any compatibility, the
routines in gcc_s from /usr/lib have to be used, in particular, the unwinder. 
But, that is exactly the thing that appears to be causing the problems.

I think we're going to need a test case, or if you could, could you try and
binary search the gcc trunk for the patch that caused this to break for you?

Also, you have this in bootstrap, does that mean that this doesn't bootstrap? 
If you could include the error messages from the bootstrap, or the name of the
gcc test case in the testsuite that is failing, that would help.

Thanks.