Thread: Linking a shared library against a C function

In the course of developing my XML parser hooks I've been using an
external XML parser (expat) which is built as a shared library. The 
C functions I'm writing need to access functions within that library.

Is it OK just to link the .so of my backend function against the expat
library? i.e. to do

gcc -shared -lexpat -o pgxml.so pgxml.o 

as the link stage (it seems to work fine) -or is there a portability 
problem with this?

IF this is OK, would it be sensible to change the platform-specific 
makefile %.so rule to allow the specification of extra instance specific 
flags i.e. (example from Makefile.linux)

%.so: %.o       $(CC) -shared -o $@ $<

changed to:

%.so: %.o$(CC) -shared $(DLLINKFLAGS) -o $@ $< 

or something similar, which would prevent me from having to override
the global rule and allow greater portability.

Thanks

John

John Gray writes:

> Is it OK just to link the .so of my backend function against the expat
> library? i.e. to do
>
> gcc -shared -lexpat -o pgxml.so pgxml.o
>
> as the link stage (it seems to work fine) -or is there a portability
> problem with this?

On some platforms the dynamic loader will have to load the libexpat.so
object separately before the pgxml.so object, otherwise loading the latter
will fail with unresolved symbols.  (This is either because the dynamic
loader ignores the libraries dependencies, or because the system doesn't
allow shared libraries to have dependencies at all.)  In those cases the
only solution is to use something like libtool.  However, those systems
are getting rarer, so you ought to be safe as a contrib item anyway.

> IF this is OK, would it be sensible to change the platform-specific
> makefile %.so rule to allow the specification of extra instance specific
> flags i.e. (example from Makefile.linux)
>
> %.so: %.o
>         $(CC) -shared -o $@ $<
>
> changed to:
>
> %.so: %.o
>     $(CC) -shared $(DLLINKFLAGS) -o $@ $<
>
> or something similar, which would prevent me from having to override
> the global rule and allow greater portability.

Use the Makefile.shlib interface.  The rules in Makefile.port aren't very
powerful.

-- 
Peter Eisentraut   peter_e@gmx.net   http://funkturm.homeip.net/~peter