This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: Shared library annoyance with gcc-3_0-branch
On Mon, Feb 19, 2001 at 04:17:04PM -0500, Daniel Jacobowitz wrote:
> On Mon, Feb 19, 2001 at 11:20:02AM -0800, Mark Mitchell wrote:
> > >>>>> "Eric" == Eric W Biederman <ebiederm@xmission.com> writes:
> >
> > Eric> O.k. What happens when you take that GCC and build a binary
> > Eric> for use during the unix bootstrap. init, /bin/sh, or
> > Eric> something called from your initial scripts.
> >
> > It works fine. Because you didn't link against any shared libraries,
> > and because you didn't specify -shared-libgcc, it gets the static
> > version of libgcc linked in.
> >
> > There should be no difference for such programs.
>
> Don't link against any shared libraries? On at least Linux systems,
> binaries in /bin and /sbin are not statically linked. -lc is implied.
> My concern is whether libc will be linked against libgcc.so, or whether
> applications using it will get their own copy.
>
> If it isn't, and the application gets a copy, consider libncurses or
> such, which will be linked against libgcc in the scenario you describe.
> Boom - copy in application, statically, copy in libncurses,
> dynamically. We limit it to two copies, but that's not a win - we need
> one, right?
To follow up to my own thoughts - you said that you believed there were
no correctness issues for C code. What about for C shared libraries?
Could we somehow get away with not linking shared libraries to the
shared libgcc unless they used C++, and requiring dynamic libgcc in
applications which wished to have correct exception handling and use
C++ shared libraries? Could we then have libgcc private to each C
shared library?
Also, my understanding is that this entire issue arises from portions
of libgcc for which there must only be one copy. But that doesn't
include all of libgcc, does it? Could we somehow divide those two -
use a static libgcc for things which can be private?
Of course, we would lose the (dubious, given the arguments about its
riskiness) benefit of being able to install a bug-fixed shared libgcc.
But this has not in the past been a major problem.
If what I'm describing in this message is feasible (or even coherent),
it might be enough to simplify the lives of we poor vendors.
Dan
/--------------------------------\ /--------------------------------\
| Daniel Jacobowitz |__| SCS Class of 2002 |
| Debian GNU/Linux Developer __ Carnegie Mellon University |
| dan@debian.org | | dmj+@andrew.cmu.edu |
\--------------------------------/ \--------------------------------/