This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: A shared version of libgcc
>>>>> "Mark" == Mark Kettenis <kettenis@wins.uva.nl> writes:
Mark> But if you put them in libstdc++ as well as the additional
Mark> C++ runtime library, people only have to distribute one
Mark> shared library instead of two :-).
I have no objection to that, if it all works. You know a lot more
about the magic of ELF linker semantics than I.
However, I'm still worried about some more fundamental questions.
Like, does the code in libgcc work if PIC on all machines where peope
configure --enable-shared? Do the assemblers and linkers on those
targets handle that correctly? Is the code going to need to change in
any way because it's going to be shared?
So, in summary, I'd like to see us reach step 1 first, which means
adjusting the Makefiles, configury, and specs files to build a shared
libgcc. Run the testsuites, see how things are working.
At that point, I think we will be better poised to decide what
switches to add to GCC to make users live easier, which of Richard's
heuristics to implement to avoid having to use the switches, and which
changes to the library structure might be most appropriate to reduce
the number of shared objects we have to ship.
We can't do any of those things until we know the basics work. And,
even if all we do is the basics, I claim users will be better off than
with GCC 2.95, since there will be some way (even if inconvenient) to
build working programs in the presence of shared objects linking
against different versions of libgcc.
That's not to say we should address all of these suggestions before
the release. I fully recognize the import of getting this right, and
that there are libc implications, etc. It's just that I'd like to see
us take this one step at a time. I have the feeling we're debating
step ten -- and I'm a little bit afraid we're going to find that step
two trips us up completely.
--
Mark Mitchell mark@codesourcery.com
CodeSourcery, LLC http://www.codesourcery.com