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 _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
