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