Re: What's with this lib suffix?
От | Thomas Hallgren |
---|---|
Тема | Re: What's with this lib suffix? |
Дата | |
Msg-id | 4401B163.1060608@tada.se обсуждение исходный текст |
Ответ на | Re: What's with this lib suffix? (Andrew Dunstan <andrew@dunslane.net>) |
Ответы |
Re: What's with this lib suffix?
|
Список | pgsql-hackers |
Andrew Dunstan wrote: > > Enumkit's makefile uses pgxs happily to make foo.so without the lib > prefix. The relevant portion reads like this: > > MODULES = $(TYPENAME) > Yeah. But using MODULES your are assumed to have one object file per module. I need to use MODULE_big. Alvaro Herrera wrote: > You can just use the Makefile.shlib rules normally and then rename the > file during installation. > I could, but then I'll have to install it in order to run the tests. Today that's not necessary. I also I consider that solution a workaround for the lack of using proper plug-in naming in pgxs. On most platforms the ELF information in the resulting lib will be incorrect due to this: LINK.shared = $(COMPILER) -shared -Wl,-soname,$(soname) (the soname in my case becomes libpljava.so.0.0) My final solution was to add my own link, install, and uninstall. That works all the way. It would be nice with better support from pgxs though. That's where the support should be IMO and it seems a bit half hearted today. MODULE_big for instance, will automatically set the major and minor versions of the shared object to zero (because its known not to be used?). Another reason to have more distinct support for the plug-in naming is that it would be less confusing for people like myself ;-) Regards, Thomas Hallgren
В списке pgsql-hackers по дате отправления: