linker error with new linker

["John Calcote" <jcalcote at novell dot com>]

Hi all -- 
 
I've run into a problem with a late version of the GNU linker (ld) that
wasn't there in previous versions. I now get the following error on my
project openslp:
 
gcc -shared [...] .libs/libslp_reg.o 
-Wl,--whole-archive ../common/.libs/libcommonlibslp.a 
-Wl,--no-whole-archive -lm -lpthread -lnsl -lresolv -Wl,-soname 
-Wl,libslp.so.1 -o .libs/libslp.so.1.0.0
[...] x86_64-suse-linux/bin/ld: 
../common/.libs/libcommonlibslp.a(slp_atomic.o): relocation R_X86_64_32

against `a local symbol' can not be used when making a shared object; 
recompile with -fPIC
 
I think I know what's happening here. We're building a shared library
from a set of static libraries. The static libraries were built with GNU
autotools configure script and makefiles automatically. We're just
reusing those "convenience" libraries to build our ultimate target - a
shared library. I don't know why the linker allowed this in the past,
but it now appears to care that the original static libraries that we're
linking into the shared object were NOT built with the -fPIC flag
(naturally - they're STATIC libraries).
 
If this assumption is correct, then I believe it's really a good thing
- we SHOULD use all -fPIC flagged code in shared libraries. But I'm not
sure why it's become important in this later version of the linker.
 
SuSE Linux 10 box - ld is 2.16.91.0.2 20050720 (packaged with gcc
4.0.2): works fine.
 
SuSE Enterprise Linux 10 Beta 8 - ld is newer (whatever SuSE's
packaging along with gcc 4.1.0-5): generates the above error. 
Here's my problem. Convenience libraries are good. They allow us to
break large sets of files up into smaller sets of objects (static
libraries) that we can deal with from one build directory to another. I
can reference a static library later in my build easily from another
directory. This is fairly common practice, I believe. With the advent of
this new linker error, what can I do to maintain this model? I don't
ship the static convenience libraries as part of my package. They just
make the build system a bit more modular. Is there a recommended
approach to fixing this issue without reorganizing my entire automake
system? 
 
For now, I going to try to override the static library flags LDFLAGS
for the convenience libraries and force the -fPIC flag on, which should
work fine since I don't expect consumers to use these convenience
libraries. But if there's a better way, please let me know.
 
Thanks in advance,
John Calcote
Novell, Inc