Re: [RFC] New library "type" needed?

[Charles Wilson]

> 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