[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 (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

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 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...)


reply via email to

[Prev in Thread] Current Thread [Next in Thread]