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

[Ralf Wildenhues]

Hello Charles,

Here's a review based on the question how such a concept could be
expressed portably.  I don't see how something like this would be of
great help if it could not be made to gracefully decay into something
still usable, on at least a useful set of platforms if not all of them.

* Charles Wilson wrote on Sun, Mar 25, 2007 at 09:34:47PM CEST:
> What I really want is a type of convenience library (call it a "resolver" 
> library?) that
> 
> (1) is built both PIC and non-PIC, depending of course on the value of 
> enable_shared and enable_static.  So far, just like a "normal" convenience 
> lib.

Well, currently a convenience lib is not built in both ways at the same
time, but that's only a side issue for the discussion at hand.

> (2) where the non-PIC resolver library is ignored when building dependent 
> static libraries (and dependent static [dlpreopened] modules).  That is, NOT 
> exploded and included within the dependent.  However, the non-PIC resolver 
> library should be used like a normal convenience library when building 
> dependent, in-package executables that depend on it directly

OK so far.  You want a convenience archive without the whole-ness.
Should it be possible to install this thing or not?  Can it itself have
nontrivial (i.e., non-convenience) dependencies?

The first of these questions is really a crux of the matter: if libbfd
can be shared and installable, then really I don't see any way except
- either explicitly forbid any third party to use your library, even
  though you install it shared,
- or have at least some sort of stable interface notion.

> (worry about 
> PIE here? We don't worry about it at present anywhere that I can see).

We have very minimal PIE support only currently in CVS HEAD, in compile
mode.

> (3) where the PIC resolver library is used *like a static library* when 
> building dependent shared libraries -- that is, used to satisfy undefined 
> symbols in the shared library if -no-undefined, but where the objects in the 
> PIC resolver library are not included wholesale via 

[ "not" correction included ]

> --whole-archive/--no-whole-archive -- and better yet, on win32 they should 
> be excluded from auto-export using -Wl,--exclude-lib -Wl,<PIC resolver 
> library name>.

Lots of systems don't allow symbol hiding (or, at least, Libtool
currently doesn't support it well on most systems).  What should happen
for them?  More to the point: what if libbfd uses the resolver libiberty
release x, while libfoo used release y of libiberty, we're on a system
without symbol hiding, and my program links against both libbfd and
libfoo?  The order of linkage will determine in which library the blow
up occurs, be that silent or spectacular, depending on how incompatible
x and y are.

> Also, these "static" libraries should not trigger the "you 
> can't create shared libs with static dependencies" filter within libtool.  

Several systems simply don't allow to mix PIC and non-PIC symbols.
On w32 this warning is pathetic, but on others we would have a problem
here.  (I can see why, on w32, you'd want to kill the warning here.)

> (Hmm. When -no-undefined is NOT specified, then there's a choice: you could 
> satisfy as many undefined symbols as you could by passing the resolver lib 
> to the linker, or you could simply drop the resolver entirely -- which would 
> match the current build procedure for libbfd & friends on non-win32...)

> I don't think it would be that difficult to add this facility to libtool -- 

No, it wouldn't.  The semantics are the hard part.  If we can't get
well-defined semantics, the new baby will be useful for binutils (and of
course the set of packages that use it) only.

> But I'd rather not -- especially this close (?) to 2.0final

Certainly not.

Cheers,
Ralf