Speex dev - Jan 2008 - PIC issues... Linking statically to speex when generating a shared library..

The short:  Linking to libspeex.a when generating a .so using libtool
results in a non-portability warning.  This is due to PIC code and non-PIC
code intermingling.
How can I go about fixing this whilst still using an installed libspeex
present on the user's system?


The long:
I am using autoconf + libtool to generate a codec plugin for speex
(sipXmediaLib), and I'm trying to eliminate the libspeex.so shared library
dependency -- I'd like to have it all in one package - so all that is needed
is to drop a single plugin that is then dlopened by our application to
supply support for the speex codec (and other codecs too, but that
conversation doesn't belong here).

Here's how I link statically to libspeex now in the plugin's Makefile.am
--
which intermingles PIC code (the non-library source in the new shared
library) and position dependent code (libspeex.a):
    codec_speex_la_SOURCES = PlgSpeex.c speex_nb.c speex_uwb.c speex_wb.c
    codec_speex_la_LIBADD = @SPEEX_ROOT@/libspeex/.libs/libspeex.a
    codec_speex_la_LDFLAGS = -module -avoid-version

(which, I just spotted, will not be correct for installed versions of speex
-- only ones we build -- since installed versions will not have the .a in a
.lib directory -- but in any case, it should illustrate things well enough)

This generates the warning from libtool:
    *** Warning: Linking the shared library codec_speex.la against the
    *** static library
../../../../../sipXmediaLib/contrib/libspeex/libspeex/.libs/libspeex.a is
not portable!

It seems this is a problem for a lot of projects..

Is there a way to do this portably?
Is there a good reason that speex (and many other projects) build static
libraries with position dependent code and not PIC?  (Given that I have
never seen this done, I'm guessing there must be a good reason)

-- 
Keith Kyzivat

SIPez LLC.
SIP VoIP, IM and Presence Consulting
http://www.SIPez.com
tel: +1 (617) 273-4000
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.xiph.org/pipermail/speex-dev/attachments/20080104/ca23ca9e/attachment.htm

Try adding '-fPIC -DPIC' to the CFLAGS environment variable (don't
forget to set the optimisations and everything else if you do that).

	Jean-Marc

Keith Kyzivat a ?crit :
> The short:  Linking to libspeex.a when generating a .so using libtool
> results in a non-portability warning.  This is due to PIC code and non-PIC
> code intermingling.
> How can I go about fixing this whilst still using an installed libspeex
> present on the user's system?
> 
> 
> The long:
> I am using autoconf + libtool to generate a codec plugin for speex
> (sipXmediaLib), and I'm trying to eliminate the libspeex.so shared
library
> dependency -- I'd like to have it all in one package - so all that is
needed
> is to drop a single plugin that is then dlopened by our application to
> supply support for the speex codec (and other codecs too, but that
> conversation doesn't belong here).
> 
> Here's how I link statically to libspeex now in the plugin's
Makefile.am --
> which intermingles PIC code (the non-library source in the new shared
> library) and position dependent code (libspeex.a):
>     codec_speex_la_SOURCES = PlgSpeex.c speex_nb.c speex_uwb.c speex_wb.c
>     codec_speex_la_LIBADD = @SPEEX_ROOT@/libspeex/.libs/libspeex.a
>     codec_speex_la_LDFLAGS = -module -avoid-version
> 
> (which, I just spotted, will not be correct for installed versions of speex
> -- only ones we build -- since installed versions will not have the .a in a
> .lib directory -- but in any case, it should illustrate things well enough)
> 
> This generates the warning from libtool:
>     *** Warning: Linking the shared library codec_speex.la against the
>     *** static library
> ../../../../../sipXmediaLib/contrib/libspeex/libspeex/.libs/libspeex.a is
> not portable!
> 
> It seems this is a problem for a lot of projects..
> 
> Is there a way to do this portably?
> Is there a good reason that speex (and many other projects) build static
> libraries with position dependent code and not PIC?  (Given that I have
> never seen this done, I'm guessing there must be a good reason)
> 
> 
> 
> ------------------------------------------------------------------------
> 
> _______________________________________________
> Speex-dev mailing list
> Speex-dev@xiph.org
> http://lists.xiph.org/mailman/listinfo/speex-dev