Обсуждение: 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