[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RFC] New library "type" needed?
From: |
Charles Wilson |
Subject: |
Re: [RFC] New library "type" needed? |
Date: |
Mon, 26 Mar 2007 08:47:37 -0500 |
User-agent: |
Thunderbird 1.5.0.10 (Windows/20070221) |
Charles Wilson wrote:
I completely understand the motivation for the meat of this, speaking in
the hypothetical sense, but why would you ever want to build libbfd
shared?
I did --enable-shared at the top level, and bfd is the first one that
failed. I'm really more interested in the runtime libs (libgcc,
libsupc++, etc) but I'm pretty sure that almost everything depends on
libiberty...so the problem will show up eventually somewhere I care
about. Why not solve it up front, with the first failure?
Sure, I could have configured using "--enable-shared=lib,lib,lib" and
left libbfd out of the list, but...
It is always built static by default even on ELF systems, for
the same reason as libiberty - it is not expected to expose anything
resembling a stable or maintained ABI.
Not entirely true. It is explicitly a part of binutils, and binutils has
a version number. Plus, libbfd is already libtoolized and built using
-release (*not* -version-info) so you'd end up with cygbfd-2.7.50.dll or
somesuch.
And its maintainers do not want
the burden of having to maintain an ABI given its history of not being
designed as such. So it seems like a really bad idea to jump through
hoops to make it shared, as you'd end up with the situation you
mentioned dozens of cygbfd-<long string>.dll files to satisfy all the
various consumers.
See above; the binutils maintainers have already thought of this, which
is why they use -release. They can do this becuase bfd is part of
bintuils, and not *part of* anything else, even if it may be *used by*
something else. libiberty OTOH is shared _at the source_ level between
binutils, gcc, newlib, and cygwin projects (more?) -- so (a) no one
project owns it (b) it has no version number (c) it is needed to resolve
undefined symbols (on windows) within not just applications from those
various projects, but also libraries.
Maybe I'm wrong; maybe libiberty is only needed by the non-runtimes, and
I should just let -shared fail for libbfd and libopcodes, and hope for
the best with respect to libgcc and all the runtime libs.
But I think I've uncovered an underlying limitation (maybe
win32-specific) with the current set of library "types" managed by
libtool -- which is why I mentioned the other major set of software
shared between projects at the source level: gnulib.
Right now, any shared library that uses gnulib (typically built as a
convenience library) will export symbols for (for instance) basename,
just because they happen to use that symbol internally.
cygMyLibrary.dll and cygYourLibrary.dll shouldn't both supply that
symbol, should they? It's an internal implementation detail...but right
now, the only way to not export gnulib-supplied stuff is to turn off
auto-export in your non-gnulib code by explicitly declspec()ing stuff or
using .def files (ugh. back to the bad old days).
Or relying on non-portable "tricks" that lead to command lines with junk
like this
-Wl,--exclude-libs -Wl,libiberty.a -Wl,libgnulib.a AND
-Wl,--whole-archive libiberty.a -Wl,--no-whole-archive
-Wl,--whole-archive libgnulib.a -Wl,--no-whole-archive
where these are "hand-coded" to a degree, in that the --exclude-libs
garbage is inserted via _LDFLAGS. Ick.
Granted, the gnulib folks are fitfully investigating mechanisms to
rename symbols (e.g. cygMyLibrary might have MyLibary_basename, while
cygYourLibrary would have YouLibrary_basename), which would prevent
symbols from *clashing*. But even then, these internal
implementation-detail symbols should not be in the export list.
(I'm glossing over certain complications with gnulib, like program_name
data elements and such, which would become awkward under both
symbol-renaming and do-not-export regimes. Leave that aside for now...)
--
Chuck