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?  (Andrew Dunstan <andrew@dunslane.net>)
Список 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 по дате отправления:

Предыдущее
От: Stephan Szabo
Дата:
Сообщение: Re: constraints and sql92 information_schema compliance
Следующее
От: Tatsuo Ishii
Дата:
Сообщение: Re: possible design bug with PQescapeString()