libgcc_s?

["Howard Chu" <hyc at highlandsun dot com>]

Sorry for dredging this up, I just spent 3 hours reading the archives from
2001 on the issue of libgcc as a shared library, and can only say that I'm
not feeling very enlightened.

It seems that the GCC project itself has changed since the last time I
worked on it (indeed, I see that my i860 work has been retired from the
tree. Ah well, the i860 was a crummy chip anyway...). But I've been a little
caught off guard by this libgcc dependency. I build a lot of 3rd-party
software written in C that includes its own shared libraries. For example, a
reasonably complete distribution of OpenLDAP includes its own
libldap/liblber DSOs, pulls in a shared  Cyrus SASL, probably OpenSSL,
Kerberos, Berkeley DB, and many other libraries. It's pretty much a given
that the version I build of all of these packages is newer than anything
pre-installed on any system I touch (since I'm actively developing with
these packages). At some point I tie everything together into bundles that I
want to make available for download, for other folks to just unpack and use.

That's great, but now that I build with GCC 3.x there's this new dependency
that I've never had to think about before. What are the ramifications of
bundling libgcc_s.so in my software? Where does it get installed? If I sell
these bundles commercially, what part of the GPL am I dealing with?

In the past, when I used GCC to build C code, that's all that it did. Now I
find that I'm saddled with an extra dependency to support something I never
asked for. (C++ exception handling). As a deep-level system hacker I will
never willingly touch C++, and it galls me that this appendage is being
pulled in by all the carefully crafted shared *C* code that I've built.
What's worse is that nowhere in the 3.x release notes did it ever say
anything about this issue, so I had no clue to look for any special
configure options or runtime options to deal with this.

A brief synopsis on how to build a shared library without any dependency on
libgcc_s.so would be much appreciated; adding it to the FAQ would be great.
If there's something I can throw into my specs file and forget about, that
would be helpful, because I don't want to have to change all the Makefiles
and configure scripts for all the packages I build.

It seemed the past flamewars were related to libgcc playing nice on
GNU/Linux platforms, but this issue really affects anybody using GCC to
build and distribute 3rd-party software on any OS. If I as a software vendor
ship a package that was built with GCC 3.x and it depends on libgcc_s.so
then I run into all of the problems that H.J. Lu described endlessly in past
emails. For example, OpenLDAP and Cyrus SASL both can/do explicitly load
other DSOs at runtime. If the main executable was bound to one version of
libgcc_s.so but the dlopen'd DSO was linked against a different version, I
expect the result will be two different instances present at the same time,
which probably will break somewhere. If all our stuff installs under /opt,
and we hardcode (-rpath) /opt into our binaries, that still doesn't protect
us if the user has LD_LIBRARY_PATH (or its equivalent) set.

Also this dependency makes it more difficult to package the software itself;
I could split OpenLDAP, OpenSSL, Kerberos, SASL etc. into their own packages
before because they were all reasonably independent. But now all of a sudden
they all require this extra piece, completely unrelated to anything else.
The sane thing to do is to ship it as its own package that everything else
depends on, to make sure we only ship one instance of it, but that's still
an added configuration/installation burden for a customer.

It's also an item of discomfort for me now, because I'm shipping something
that I didn't build explicitly, something with which I have no intimate
familiarity. In contrast, I've read every single line of source code of the
other items, I built them explicitly and I stand behind their functionality.
This item's a wildcard, I dunno what's inside, why it's needed, whether my
bundled version is even right for a customer's platform.

If all of these questions have already been addressed I'm sorry for wasting
your time, but please send me a pointer to the relevant messages. Thanks.

  -- Howard Chu
  Chief Architect, Symas Corp.       Director, Highland Sun
  http://www.symas.com               http://highlandsun.com/hyc
  Symas: Premier OpenSource Development and Support