Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Bruce Momjian wrote: I would like to see some comments about AIX linking so we don't need to relearn this in 1-2 years. Something like http://archives.postgresql.org/pgsql-hackers/2006-09/msg00893.php or something more comprehensive? Maybe mentioning LIBPATH and -blibpath: might be good. Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Rocco Altier wrote: pg_regress normally tries to handle this by setting LD_LIBRARY_PATH ... does AIX use that or a similar symbol? The make check was successful in my previous testing of the last patch, so it appears that AIX was paying attention to LD_LIBRARY_PATH. Anyhow, I have updated the patch to set LIBPATH (AIX's version of LD_LIBRARY_PATH), in pg_regress and ecpg's pg_regress. I have tested this with default config options (enable-shared, enable-rpath). I am starting to test the other methods as well, but wanted to get this out first. LD_LIBRARY_PATH does not work on AIX - the AIX equivalent is LIBPATH. make check does not seem to rely on LD_LIBRARY_PATH, and it should work with my patch (it worked here). If pg_regress relies on LD_LIBRARY_PATH, it would have to be changed to set LIBPATH in the AIX case :^( The reason why all these problems manifest now is that - up to now - PostgreSQL used static linking on AIX and it was not necessary to find the shared library. Yours, Laurenz Albe ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Tom Lane wrote: The proposed patch to Makefile.shlib makes me gag :-( ... It is ugly. lying to make about what's the purpose of a rule is seldom a good idea. Please try as attached instead. I will ASAP. Also, I am *really* dubious about the change to ecpg/test/Makefile.regress --- if that's necessary then this whole exercise is wrong. For a dynamic build you do not need the change. Only a --disable-shared build will gag without it. I'll have a look at that too. Yours, Laurenz Albe ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Albe Laurenz [EMAIL PROTECTED] writes: Tom Lane wrote: Also, I am *really* dubious about the change to ecpg/test/Makefile.regress --- if that's necessary then this whole exercise is wrong. For a dynamic build you do not need the change. Only a --disable-shared build will gag without it. Ah. In that case I think the answer is that that makefile should be using $(libpq) or possibly $(libpq_pgport) from Makefile.global, rather than bare -lpq. regards, tom lane ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
I suspect that up to now the buildfarm had a static build of PostgreSQL. What is the output of 'ldd initdb' when it builds and runs correctly? Is libpq.so in a non-standard directory? If yes, one either has to export LIBPATH in the environment or link with -L/location/of/libpq for the executable to find it (similar to RPATH in Linux). Here is the working one: initdb needs: /usr/lib/libc.a(shr.o) /unix /usr/lib/libcrypt.a(shr.o) Here is the broken one: initdb needs: ../../../src/interfaces/libpq/libpq.so /usr/lib/libc.a(shr.o) /usr/lib/librtl.a(shr.o) /unix /usr/lib/libcrypt.a(shr.o) When run it shows: exec(): 0509-036 Cannot load program initdb because of the following errors: 0509-150 Dependent module libpq.so could not be loaded. 0509-022 Cannot load module libpq.so. 0509-026 System error: A file or directory in the path name does not exist. ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Rocco Altier wrote: Here is the working one: initdb needs: /usr/lib/libc.a(shr.o) /unix /usr/lib/libcrypt.a(shr.o) Here is the broken one: initdb needs: ../../../src/interfaces/libpq/libpq.so /usr/lib/libc.a(shr.o) /usr/lib/librtl.a(shr.o) /unix /usr/lib/libcrypt.a(shr.o) When run it shows: exec(): 0509-036 Cannot load program initdb because of the following errors: 0509-150 Dependent module libpq.so could not be loaded. 0509-022 Cannot load module libpq.so. 0509-026 System error: A file or directory in the path name does not exist. Yup, that's as expected :^) Up to now you have built against the static libpq.a I didn't add the right -blibpath to this patch that failed for you - the broken initdb is dynamically linked but does not know where to look for its shared library. The patch I just submitted to pgsql-patches should take care of that. It makes the executables look in --libdir. Yours, Laurenz Albe ---(end of broadcast)--- TIP 1: if posting/reading through Usenet, please send an appropriate subscribe-nomail command to [EMAIL PROTECTED] so that your message can get through to the mailing list cleanly
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Albe Laurenz [EMAIL PROTECTED] writes: Up to now you have built against the static libpq.a I didn't add the right -blibpath to this patch that failed for you - the broken initdb is dynamically linked but does not know where to look for its shared library. The patch I just submitted to pgsql-patches should take care of that. It makes the executables look in --libdir. Mmm ... what of make check's temporary installation? We need to have the executables search in the temporary install's libdir, *before* looking in the configured --libdir (which could easily contain an incompatible back-version libpq ...) pg_regress normally tries to handle this by setting LD_LIBRARY_PATH ... does AIX use that or a similar symbol? regards, tom lane ---(end of broadcast)--- TIP 9: In versions below 8.0, the planner will ignore your desire to choose an index scan if your joining column's datatypes do not match
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
From: Tom Lane [mailto:[EMAIL PROTECTED] Albe Laurenz [EMAIL PROTECTED] writes: Up to now you have built against the static libpq.a I didn't add the right -blibpath to this patch that failed for you - the broken initdb is dynamically linked but does not know where to look for its shared library. The patch I just submitted to pgsql-patches should take care of that. It makes the executables look in --libdir. Mmm ... what of make check's temporary installation? We need to have the executables search in the temporary install's libdir, *before* looking in the configured --libdir (which could easily contain an incompatible back-version libpq ...) pg_regress normally tries to handle this by setting LD_LIBRARY_PATH ... does AIX use that or a similar symbol? The make check was successful in my previous testing of the last patch, so it appears that AIX was paying attention to LD_LIBRARY_PATH. I am testing the new version of the patch now, so will report back shortly. Thanks, -rocco ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
From: Tom Lane [mailto:[EMAIL PROTECTED] Mmm ... what of make check's temporary installation? We need to have the executables search in the temporary install's libdir, *before* looking in the configured --libdir (which could easily contain an incompatible back-version libpq ...) pg_regress normally tries to handle this by setting LD_LIBRARY_PATH ... does AIX use that or a similar symbol? The make check was successful in my previous testing of the last patch, so it appears that AIX was paying attention to LD_LIBRARY_PATH. I am testing the new version of the patch now, so will report back shortly. From testing the new patch, it did not work for the regression tests in the buildfarm. Not sure why it did work before. Anyhow, I have updated the patch to set LIBPATH (AIX's version of LD_LIBRARY_PATH), in pg_regress and ecpg's pg_regress. I have tested this with default config options (enable-shared, enable-rpath). I am starting to test the other methods as well, but wanted to get this out first. -rocco ---(end of broadcast)--- TIP 6: explain analyze is your friend
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
With the patch attached this time... -rocco -Original Message- From: Rocco Altier Sent: Friday, September 15, 2006 2:04 PM To: Rocco Altier; 'Tom Lane'; 'Albe Laurenz' Cc: 'pgsql-hackers@postgresql.org' Subject: RE: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries ) From: Tom Lane [mailto:[EMAIL PROTECTED] Mmm ... what of make check's temporary installation? We need to have the executables search in the temporary install's libdir, *before* looking in the configured --libdir (which could easily contain an incompatible back-version libpq ...) pg_regress normally tries to handle this by setting LD_LIBRARY_PATH ... does AIX use that or a similar symbol? The make check was successful in my previous testing of the last patch, so it appears that AIX was paying attention to LD_LIBRARY_PATH. I am testing the new version of the patch now, so will report back shortly. From testing the new patch, it did not work for the regression tests in the buildfarm. Not sure why it did work before. Anyhow, I have updated the patch to set LIBPATH (AIX's version of LD_LIBRARY_PATH), in pg_regress and ecpg's pg_regress. I have tested this with default config options (enable-shared, enable-rpath). I am starting to test the other methods as well, but wanted to get this out first. -rocco aix.link.regression.patch Description: aix.link.regression.patch ---(end of broadcast)--- TIP 5: don't forget to increase your free space map settings
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Rocco Altier [EMAIL PROTECTED] writes: With the patch attached this time... The proposed patch to Makefile.shlib makes me gag :-( ... lying to make about what's the purpose of a rule is seldom a good idea. Please try as attached instead. Also, I am *really* dubious about the change to ecpg/test/Makefile.regress --- if that's necessary then this whole exercise is wrong. regards, tom lane *** src/Makefile.shlib.orig Thu Apr 27 22:53:20 2006 --- src/Makefile.shlib Fri Sep 15 18:11:30 2006 *** *** 96,103 soname = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) ifeq ($(PORTNAME), aix) ! shlib = lib$(NAME)$(DLSUFFIX) ! # SHLIB_LINK+= -lc endif ifeq ($(PORTNAME), darwin) --- 96,103 soname = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) ifeq ($(PORTNAME), aix) ! shlib = lib$(NAME)$(DLSUFFIX).$(SO_MAJOR_VERSION) ! haslibarule = yes endif ifeq ($(PORTNAME), darwin) *** *** 295,303 else # PORTNAME == aix # AIX case ! $(shlib): lib$(NAME).a $(MKLDEXPORT) lib$(NAME).a lib$(NAME)$(EXPSUFF) ! $(COMPILER) $(LDFLAGS_NO_L) $(LDFLAGS_SL) -o $@ $ -Wl,-bE:lib$(NAME)$(EXPSUFF) $(SHLIB_LINK) endif # PORTNAME == aix --- 295,307 else # PORTNAME == aix # AIX case ! $(shlib) lib$(NAME).a: $(OBJS) ! $(LINK.static) lib$(NAME).a $^ ! $(RANLIB) lib$(NAME).a $(MKLDEXPORT) lib$(NAME).a lib$(NAME)$(EXPSUFF) ! $(COMPILER) $(LDFLAGS_NO_L) $(LDFLAGS_SL) -o $(shlib) lib$(NAME).a -Wl,-bE:lib$(NAME)$(EXPSUFF) $(SHLIB_LINK) ! rm -f lib$(NAME).a ! $(AR) $(AROPT) lib$(NAME).a $(shlib) endif # PORTNAME == aix *** *** 350,355 --- 354,360 ifeq ($(enable_shared), yes) install-lib-shared: $(shlib) + ifneq ($(PORTNAME), aix) # we don't install $(shlib) on AIX $(INSTALL_SHLIB) $ '$(DESTDIR)$(libdir)/$(shlib)' ifneq ($(PORTNAME), cygwin) ifneq ($(PORTNAME), win32) *** *** 365,370 --- 370,376 endif endif # not win32 endif # not cygwin + endif # not aix endif # enable_shared ---(end of broadcast)--- TIP 3: Have you checked our extensive FAQ? http://www.postgresql.org/docs/faq
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
The patch did not work for me :-( My buildfarm members failed in local testing to execute the install-check, because initdb failed to find libpq.so. Make check did succeed, so I think there is a possibility of getting it working, but it won't be as simple as adding -brtl to the template. I suspect that up to now the buildfarm had a static build of PostgreSQL. What is the output of 'ldd initdb' when it builds and runs correctly? Is libpq.so in a non-standard directory? If yes, one either has to export LIBPATH in the environment or link with -L/location/of/libpq for the executable to find it (similar to RPATH in Linux). Yours, Laurenz Albe ---(end of broadcast)--- TIP 4: Have you searched our list archives? http://archives.postgresql.org
Re: [PATCHES] [HACKERS] Linking on AIX (Was: Fix linking of OpenLDAP libraries )
Albe Laurenz [EMAIL PROTECTED] writes: The patch did not work for me :-( Is libpq.so in a non-standard directory? If yes, one either has to export LIBPATH in the environment or link with -L/location/of/libpq for the executable to find it (similar to RPATH in Linux). libpq will definitely be in a nonstandard directory in buildfarm usage. It sounds like we should add the local equivalent of RPATH for AIX. Now I'm pretty dubious that -L is what we want --- -L should have the semantics of this is where to find the library right now. RPATH is used to point to an expected installation directory that might not contain the library at the time of linking ... or worse, might contain an old incompatible version of it. Does AIX have a true RPATH equivalent? regards, tom lane ---(end of broadcast)--- TIP 2: Don't 'kill -9' the postmaster
