Обсуждение: What's with this lib suffix?

I have a PL/Java bug entry from Peter E. that reads "It is customary in PostgreSQL land and 
elsewhere, that dynamically loadable modules do not have a lib prefix (compare plpgsql.so, 
pltcl.so, etc.).  So I suggest that the shared object installed by PL/Java also be called 
exactly pljava.so.".

I'd like to follow customary practices but as it turns out, I'm not the one adding the 'lib' 
prefix. It's done by the Makefile.shlib that comes bundled with pgxs. Here you can read 
things like:
 # Default shlib naming convention used by the majority of platforms shlib        =
lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)shlib_major    = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
shlib_bare   = lib$(NAME)$(DLSUFFIX)
 

and sure enough, that's what gets used too. So what goes?

Personally, I'd prefer to keep the 'lib' prefix since it really *is* the default naming 
convention on all *n[iu]x platforms I've been in contact with. Not so on Windows though so 
perhaps that should change in Makefile.shlib?

I'm confused.

Kind Regards,
Thomas Hallgren

Thomas Hallgren wrote:
>   # Default shlib naming convention used by the majority of platforms
>   shlib        =
> lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
> shlib_major    = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
>   shlib_bare    = lib$(NAME)$(DLSUFFIX)
>
> and sure enough, that's what gets used too. So what goes?

You are confusing the naming convention for shared libraries that are 
intended to be linked into programs (or other libraries) at build time, 
which normally have to be named libsomething.so because that is what 
the compiler/linker flag -lsomething resolves to, with the naming 
convention for shared libraries that are intended to be loaded at 
run-time (sometimes called plug-ins), which require no particular 
naming.

Examples:

$ ls -1 /usr/lib/postgresql/8.1/lib/
ascii_and_mic.so
cyrillic_and_mic.so
euc_cn_and_mic.so
euc_jp_and_sjis.so
euc_kr_and_mic.so
euc_tw_and_big5.so
latin2_and_win1250.so
latin_and_mic.so
pljava.so
plpgsql.so
...

$ ls -1 /usr/lib/samba/vfs/
audit.so
cap.so
default_quota.so
expand_msdfs.so
extd_audit.so
fake_perms.so
full_audit.so
netatalk.so
readonly.so
recycle.so
shadow_copy.so

$ ls -1 /lib/security/
pam_access.so
pam_debug.so
pam_deny.so
pam_env.so
pam_filter.so
pam_ftp.so
...

$ ls -1 /usr/lib/apache2/modules/
httpd.exp
mod_actions.so
mod_asis.so
mod_auth_anon.so
mod_auth_dbm.so
mod_auth_digest.so
mod_auth_ldap.so
mod_cache.so
...

$ ls -1 /usr/lib/valgrind/x86-linux/
...
vgpreload_core.so
vgpreload_helgrind.so
vgpreload_massif.so
vgpreload_memcheck.so

-- 
Peter Eisentraut
http://developer.postgresql.org/~petere/

Peter Eisentraut wrote:
> Thomas Hallgren wrote:
>   
>>   # Default shlib naming convention used by the majority of platforms
>>   shlib        =
>> lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
>> shlib_major    = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
>>   shlib_bare    = lib$(NAME)$(DLSUFFIX)
>>
>> and sure enough, that's what gets used too. So what goes?
>>     
>
> You are confusing the naming convention for shared libraries that are 
> intended to be linked into programs (or other libraries) at build time, 
> which normally have to be named libsomething.so because that is what 
> the compiler/linker flag -lsomething resolves to, with the naming 
> convention for shared libraries that are intended to be loaded at 
> run-time (sometimes called plug-ins), which require no particular 
> naming.
>
>   
In that case, I'd appreciate some advice on how to use the pgxs package 
to compile a 'plug-in'. Looks to me it's only designed to compile 
'shared libraries'.

Regards,
Thomas Hallgren

Thomas Hallgren wrote:

> In that case, I'd appreciate some advice on how to use the pgxs package 
> to compile a 'plug-in'. Looks to me it's only designed to compile 
> 'shared libraries'.

You can just use the Makefile.shlib rules normally and then rename the
file during installation.  PL/pgSQL does things this way:


# In order to use Makefile.shlib, we allow it to build a static
# library libplpgsql.a, which we just ignore, as well as a shared
# library that it will insist on naming $(shlib). We don't want to
# call it that when installed, however, so we ignore the install-shlib
# rule and do this instead:

install: installdirs all
ifeq ($(enable_shared), yes)   $(INSTALL_SHLIB) $(shlib) $(DESTDIR)$(pkglibdir)/plpgsql$(DLSUFFIX)
else   @echo "*****"; \    echo "* PL/pgSQL was not installed due to lack of shared library support."; \    echo
"*****"
endif


-- 
Alvaro Herrera                                http://www.CommandPrompt.com/
The PostgreSQL Company - Command Prompt, Inc.

Thomas Hallgren wrote:

> Peter Eisentraut wrote:
>
>> Thomas Hallgren wrote:
>>  
>>
>>>   # Default shlib naming convention used by the majority of platforms
>>>   shlib        =
>>> lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION).$(SO_MINOR_VERSION)
>>> shlib_major    = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION)
>>>   shlib_bare    = lib$(NAME)$(DLSUFFIX)
>>>
>>> and sure enough, that's what gets used too. So what goes?
>>>     
>>
>>
>> You are confusing the naming convention for shared libraries that are 
>> intended to be linked into programs (or other libraries) at build 
>> time, which normally have to be named libsomething.so because that is 
>> what the compiler/linker flag -lsomething resolves to, with the 
>> naming convention for shared libraries that are intended to be loaded 
>> at run-time (sometimes called plug-ins), which require no particular 
>> naming.
>>
>>   
>
> In that case, I'd appreciate some advice on how to use the pgxs 
> package to compile a 'plug-in'. Looks to me it's only designed to 
> compile 'shared libraries'.
>
>

Enumkit's makefile uses pgxs happily to make foo.so without the lib 
prefix. The relevant portion reads like this:

MODULES = $(TYPENAME)

DATA_built = $(TYPENAME)-install.sql

ENUMS = junk

SRCS += $(TYPENAME).c
OBJS = $(SRCS:.c=.o)

PGXS := $(shell pg_config --pgxs)
include $(PGXS)


With this,
 make TYPENAME=foo ENUMS='"foo","bar"'

produces foo.so.


HTH

cheers

andrew

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

Thomas Hallgren wrote:

> 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.



Yes, I see that now.

Maybe we should add a MODULE_dyn target to pgxs.mk.

cheers

andrew