Re: Linking a shared library against a C function
От | Peter Eisentraut |
---|---|
Тема | Re: Linking a shared library against a C function |
Дата | |
Msg-id | Pine.LNX.4.30.0108060213510.11162-100000@peter.localdomain обсуждение исходный текст |
Ответ на | Linking a shared library against a C function ("John Gray" <jgray@beansindustry.co.uk>) |
Список | pgsql-hackers |
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
В списке pgsql-hackers по дате отправления: