What's with this lib suffix?

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