Charles Wilson wrote:
I'd still like to be able to build my convenience library as both pic
and non-pic tho. And I still want to prevent libiberty.a(non-pic) from
getting the --whole-archive treatment when it comes to libbfd.a.
...
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.)
No, you're missing the point of my statement: I *know* you don't want to
mix pic and non-pic.
After doing a bit of reading, the statements above are a little too
strong. It's not that you can't mix pic and non-pic (or at least, it's
not obviously the case; we'll dig deeper -- see below). At the surface
level, it is simply that where -fpic/-fPIC makes a difference, you
cannot include non-pic in a shared library. However, there's no reason
you can't include pic in a static library: you just lose a little
efficiency (from the AutoBook)
"In practice, you can link PIC objects into a static archive for a small
overhead in execution and load speed..."
e.g. shared << pic only
static << pic and non-pic ok
Which I guess is why: if pic available, libtool defaults to using pic
objects in the convenience lib, unless specifically directed otherwise.
And yet, that same, single, convenience lib (which is pic) will be
used when creating both static and shared libraries that depend on it.
Digging deeper:
On cygwin/mingw *at present*, the only difference between pic and
non-pic is that the former objects were compiled with "-DPIC
-DDLL_EXPORT". This could cause trouble for convenience libs that are
sensitive to DLL_EXPORT (and isn't that the point? otherwise, why bother
to -D it?) -- because while the machine code is more-or-less the same
(that is, gcc doesn't generate machine instructions differently _on its
own_) -- some packages might behave differently _at the source code
level_ due to the different -Ddefines
One example is libltdl itself, as we discovered a few months ago:
#if !defined(LT_SCOPE)
# if defined(__WINDOWS__) || defined(__CYGWIN__)
#if defined(DLL_EXPORT)
# define LT_SCOPE extern __declspec(dllexport)
#endif
#if defined(LIBLTDL_DLL_IMPORT)
# define LT_SCOPE extern __declspec(dllimport)
#endif
# endif
# if !defined(LT_SCOPE)
#define LT_SCOPEextern
# endif
#endif
So, we come full circle: now it's clear that the libtool assumption of
"hey, if pic available, then just always use pic when building
convenience libs (unless instructed otherwise via no-pic/--without-pic);
that way, the result is "safe" for use regardless", breaks down on
cygwin/mingw!
So, perhaps it really is time to revisit this assumption...see
Alexandre Oliva, February 2001 [ignoring the bits about "installable
convenience libraries (??!!)]
http://sources.redhat.com/ml/automake/2001-02/msg00304.html
"And I wish convenience libraries could still come
in PIC and non-PIC versions, just like object files. Currently, every
time you create a convenience archive, you don't get the non-PIC
objects, unless the PIC objects aren't available."
There's still some issues with convenience libs themselves (where the
following discussion ignores ALL of the above, no new library types, no
new -exclude-lib option), like:
(a) we should build a pic version and stuff it inside .libs/ if
-enable-shared, and put a regular version in . if -enable-static
...
(b) When linking a shared lib where a convenience lib appears in the
deps, use the one in the .libs/ directory
(c) ??? when linking a PIE executable where a convenience lib appears
in the deps, use the one in the .libs/ directory
(d) when creating a static lib where a convenience lib appears in the
deps, use the one in the . directory when doing the explode-and-
incorporate thing.
(e) when creating a next-level convenience lib that has THIS
convenienece lib as a dep, again, create a pic version in .libs and
a non-pic version in . In each case, use the "matching" version of
the dependency when doing the explode-and-incorporate thing.
(f) In all other cases, use the "regular" lib
[replace 'explode-and-incorporate thing' with 'partial linking thing' if
your platform supports it]
These improvements to "regular" convenience libraries are, IMO,
necessary for proper operation where pic/no-pic makes a difference.
And, as detailed above w.r.t. "-DDLL_EXPORT", even when -fpic itself
makes no difference.
I tried to figure out what it would take to do the above, but the maze
of twisty little passages all the same made my head hurt. It *looks*
like the build-a-convenience-lib codeflow "borrows" the "build an oldlib
(e.g. static archive)" machinery, but jiggers with the list-of-objects.
If so, then this task will be rather tricky (I think), because the
build-a-convenience-lib codeflow will need to be disentangled, so that
it ha
