diff --git a/doc/FAQ_AIX b/doc/FAQ_AIX deleted file mode 100644 index 9d65f59124..0000000000 --- a/doc/FAQ_AIX +++ /dev/null @@ -1,493 +0,0 @@ -======================================================= -Frequently Asked Questions (FAQ) for PostgreSQL -AIX Specific -TO BE READ IN CONJUNCTION WITH THE NORMAL FAQ -======================================================= -Last updated: $Date: 2007/10/09 01:28:24 $ - -Topics - -- AIX 4.3.2 Port Report -- AIX 5.3 Additional Information -- AIX, readline, and postgres 8.1.x: -- AIX Memory Management: An Overview -- Statistics Collector Fun on AIX - ------ - -From: Zeugswetter Andreas -$Date: 2007/10/09 01:28:24 $ - -On AIX 4.3.2 PostgreSQL compiled with the native IBM compiler xlc -(vac.C 5.0.1) passes all regression tests. Other versions of OS and -compiler should also work. If you don't have a powerpc or use gcc you -might see rounding differences in the geometry regression test. - -Use the following configure flags in addition to your own -if you have readline or libz there: ---with-includes=/usr/local/include --with-libraries=/usr/local/lib - -There will probably be warnings about 0.0/0.0 division and duplicate -symbols which you can safely ignore. - -Compiling PostgreSQL with gcc (2.95.3) on AIX also works. - -You need libm.a that is in the fileset bos.adt.libm. (Try the -following command.) -$ lslpp -l bos.adt.libm - - ---- -From: Christopher Browne -Date: 2005-07-15 - -On AIX 5.3, there have been some problems getting PostgreSQL to -compile and run using GCC. - -1. You will want to use a version of GCC subsequent to 3.3.2, - particularly if you use a prepackaged version. We had good - success with 4.0.1. - - Problems with earlier versions seem to have more to do with the - way IBM packaged GCC than with actual issues with GCC, so that if - you compile GCC yourself, you might well have success with an - earlier version of GCC. - -2. AIX 5.3 has a problem where sockadr_storage is not defined to be - large enough. In version 5.3, IBM increased the size of - sockaddr_un, the address structure for UNIX Domain Sockets, but - did not correspondingly increase the size of sockadr_storage. - - The result of this is that attempts to use UDS with PostgreSQL - lead to libpq overflowing the data structure. TCP/IP connections - work OK, but not UDS, which prevents the regression tests from - working. - - The nonconformance may be readily demonstrated by compiling and - running the following C program which calculates and compares the - sizes of the various structures: - -test_size.c ------------- - ----------- snip here - test_size.c ---------------------------- -#include -#include -#include -int main (int argc, char *argv[]) { - struct sockaddr_storage a; - struct sockaddr_un b; - printf("Size of sockadr_storage: %d\n", sizeof(a)); - printf ("Size of sockaddr_un:%d\n", sizeof(b)); - - if (sizeof(a) >= sizeof(b)) - printf ("Conformant to RFC 3493\n"); - else - printf ("Non-conformant to RFC 3493\n"); -} ----------- snip here - test_size.c ---------------------------- - - -The problem was reported to IBM, and is recorded as bug report -PMR29657. - -An immediate resolution is to alter _SS_MAXSIZE to = 1025 in -/usr/include/sys/socket.h, which will resolve the immediate problem. - -It appears that the "final" resolution will be to alter _SS_MAXSIZE to -1280, making the size nicely align with page boundaries. - -IBM will be providing a fix in the next maintenance release (expected -in October 2005) with an updated socket.h. ---- -PMR29657 was resolved in APAR IY74147: INCOMPATIBILITY BETWEEN -SOCKADDR_UN AND SOCKADDR_STORAGE STRUCT - -APAR information -APAR number IY74147 -Reported component name AIX 5.3 -Reported component ID 5765G0300 -Reported release 530 -Status CLOSED PER -PE NoPE -HIPER NoHIPER -Submitted date 2005-07-18 -Closed date 2005-07-18 -Last modified date 2005-09-06 - -If you upgrade to maintenance level 5300-03, that will include this -fix. Use the command "oslevel -r" to determine what maintenance level -you are at. ---- -From: Christopher Browne -Date: 2005-07-15 - -Some of the AIX tools may be "a little different" from what you may be -accustomed to on other platforms. If you are looking for a version of -ldd, useful for determining what object code depends on what -libraries, the following URLs may help you... - -http://www.faqs.org/faqs/aix-faq/part4/section-22.html - -http://www.han.de/~jum/aix/ldd.c - ---- -From: Christopher Browne -Date: 2005-11-02 - -On AIX 5.3 ML3 (e.g. maintenance level 5300-03), there is some problem -with the handling of the pointer to memcpy. It is speculated that -this relates to some linker bug that may have been introduced between -5300-02 and 5300-03, but we have so far been unable to track down the -cause. - -At any rate, the following patch, which "unwraps" the function -reference, has been observed to allow PG 8.1 pre-releases to pass -regression tests. - -The same behaviour (albeit with varying underlying functions to -"blame") has been observed when compiling with either GCC 4.0 or IBM -XLC. - ------------- per Seneca Cunningham ------------------- - -The following patch works on the AIX 5.3 ML3 box here and didn't cause -any problems with postgres on the x86 desktop. It's just a cleaner -version of what I tried earlier. - -*** dynahash.c.orig Tue Nov 1 19:41:42 2005 ---- dynahash.c Tue Nov 1 20:30:33 2005 -*************** -*** 670,676 **** - - - /* copy key into record */ - currBucket->hashvalue = hashvalue; -! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize); - - - /* caller is expected to fill the data field on return */ - - ---- 670,687 ---- - - - /* copy key into record */ - currBucket->hashvalue = hashvalue; -! if (hashp->keycopy == memcpy) -! { -! memcpy(ELEMENTKEY(currBucket), keyPtr, keysize); -! } -! else if (hashp->keycopy == strncpy) -! { -! strncpy(ELEMENTKEY(currBucket), keyPtr, keysize); -! } -! else -! { -! hashp->keycopy(ELEMENTKEY(currBucket), keyPtr, keysize); -! } - - - /* caller is expected to fill the data field on return */ - ------------- per Seneca Cunningham ------------------- - ---- - -AIX, readline, and postgres 8.1.x: ----------------------------------- - -If make check doesn't work on AIX with initdb going into an infinite -loop or failing with child processes terminated with signal 11, the -problem could be the installed copy of readline. Previously a patch to -dynahash.c was suggested to get around this, don't use it, better ways -to get postgres working exist. - -See -for details about the problem. - -Working around the problem: ---------------------------- -Try one of the following: - -o Use the new 8.2devel backend Makefile: - -After the matter of readline's export list and the problems that were -occurring on AIX because of it being linked to the backend, a filter -to exclude unneeded libraries from being linked against the backend was -added. Get revision 1.112 of src/backend/Makefile from CVS and replace -the copy that came with postgres with it. Build normally. - -o Use libedit - -There are a few libedit ports available online. Build and install the -desired port. If libreadline.a can be found in /lib, /usr/lib, or in -any location passed to postgres' configure via "--with-libraries=", -readline will be detected and used by postgres. IBM's rpm of readline -creates a symlink to /opt/freeware/lib/libreadline.a in /lib, so merely -excluding /opt/freeware/lib from the passed library path does not stop -readline from being used. - -If the linker cannot avoid finding libreadline.a, use revision 1.433 -configure.in and 1.19 config/programs.m4 from CVS, change 8.2devel to -the appropriate 8.1.x in configure.in and run autoconf. Add the -configure flag "--with-libedit-preferred". - -If the version of libedit used calls its "history.h" something other -than history.h, place a symlink called history.h to it somewhere that -the C preprocessor will check. - -o Configure with "--without-readline" - -postgres can be configured with the option "--without-readline". When -this is enabled, postgres will not link against libreadline or libedit. -psql will not have history, tab completion, or any of the other niceties -that readline and libedit bring, but external readline wrappers exist -that add that functionality. - -o Use readline 5.0 - -Readline 5.0 does not induce the problems, however it does export -memcpy and strncpy when built using the easy method of "-bexpall". Like -4.3, it is possible to do a build that does not export these symbols, -but it does take considerable manual effort and the creation of export -files. - -References ----------- -"AIX 5L Porting Guide" - IBM Redbook - http://www.redbooks.ibm.com/redbooks/pdfs/sg246034.pdf - http://www.redbooks.ibm.com/abstracts/sg246034.html?Open - -"Developing and Porting C and C++ Applications on AIX" - IBM Redbook - http://www.redbooks.ibm.com/redbooks/pdfs/sg245674.pdf - http://www.redbooks.ibm.com/abstracts/sg245674.html?Open - ------ - -AIX Memory Management: An Overview -================================== - -by Seneca Cunningham... - -AIX can be somewhat peculiar with regards to the way it does memory -management. You can have a server with many multiples of gigabytes of -RAM free, but still get out of memory or address space errors when -running applications. - -Two examples of AIX-specific memory problems --------------------------------------------- -Both examples were from systems with gigabytes of free RAM. - -a) createlang failing with unusual errors - Running as the owner of the postgres install: - -bash-3.00$ createlang plpgsql template1 - createlang: language installation failed: ERROR: could not load library - "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the - address space for the process. - - Running as a non-owner in the group posessing the postgres install: - -bash-3.00$ createlang plpgsql template1 - createlang: language installation failed: ERROR: could not load library - "/opt/dbs/pgsql748/lib/plpgsql.so": Bad address - -b) out of memory errors in the postgres logs - Every memory allocation near or greater than 256MB failing. - - -The cause of these problems ----------------------------- - -The overall cause of all these problems is the default bittedness and -memory model used by the server process. - -By default, all binaries built on AIX are 32-bit. This does not -depend upon hardware type or kernel in use. These 32-bit processes -are limited to 4GB of memory laid out in 256MB segments using one of a -few models. The default allows for less than 256MB in the heap as it -shares a single segment with the stack. - -In the case of example a), above, check your umask and the permissions -of the binaries in your postgres install. The binaries involved in -that example were 32-bit and installed as mode 750 instead of 755. -Due to the permissions being set in this fashion, only the owner or a -member of the possessing group can load the library. Since it isn't -world-readable, the loader places the object into the process' heap -instead of the shared library segments where it would otherwise be -placed. - -Solutions and workarounds -------------------------- -In this section, all build flag syntax is presented for gcc. - -The "ideal" solution for this is to use a 64-bit build of postgres, -but that's not always practical. Systems with 32-bit processors can -build, but not run, 64-bit binaries. - -If a 32-bit binary is desired, set LDR_CNTRL to "MAXDATA=0xn0000000", -where 1 <= n <= 8, before starting the postgres server and try different -values and postgresql.conf settings to find a configuration that works -satisfactorily. This use of LDR_CNTRL tells AIX that you want the -server to have $MAXDATA bytes set aside for the heap, allocated in -256MB segments. - -When you find a workable configuration, ldedit can be used to modify -the binaries so that they default to using the desired heap size. - -PostgreSQL might also be rebuilt, passing configure -LDFLAGS="-Wl,-bmaxdata:0xn0000000" to achieve the same effect. - -For a 64-bit build, set OBJECT_MODE to 64 and pass CC="gcc -maix64" -and LDFLAGS="-Wl,-bbigtoc" to configure. If you omit the export of -OBJECT_MODE, your build may fail with linker errors. When OBJECT_MODE -is set, it tells AIX's build utilities such as ar, as, and ld what -type of objects to default to handling. - -Overcommit ----------- - -By default, overcommit of paging space can happen. While I have not -seen this occur, AIX will kill processes when it runs out of memory -and the overcommit is accessed. The closest to this that I have seen -is fork failing because the system decided that there was not enough -memory for another process. Like many other parts of AIX, the paging -space allocation method and out-of-memory kill is configurable on a -system- or process-wide basis if this becomes a problem. - -References and resources ------------------------- -"Large Program Support" - AIX Documentation: General Programming Concepts: Writing and Debugging Programs - http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/lrg_prg_support.htm - -"Program Address Space Overview" - AIX Documentation: General Programming Concepts: Writing and Debugging Programs - http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/address_space.htm - -"Performance Overview of the Virtual Memory Manager (VMM)" - AIX Documentation: Performance Management Guide - http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/resmgmt2.htm - -"Page Space Allocation" - AIX Documentation: Performance Management Guide - http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf7.htm - -"Paging-space thresholds tuning" - AIX Documentation: Performance Management Guide - http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf6.htm - -"Developing and Porting C and C++ Applications on AIX" - IBM Redbook - http://www.redbooks.ibm.com/redbooks/pdfs/sg245674.pdf - http://www.redbooks.ibm.com/abstracts/sg245674.html?Open - - -Statistics Collector Fun on AIX --------------------------------- - -When implementing PostgreSQL version 8.1 on AIX 5.3, we periodically -ran into problems where the statistics collector would "mysteriously" -not come up successfully. - -This appears to be the result of unexpected behaviour in the IPv6 -implementation. It looks like PostgreSQL and IPv6 do not play very -well together at this time on AIX. - -Any of the following actions "fix" the problem. - -1. Delete the localhost ipv6 address - -(as root) -# ifconfig lo0 inet6 ::1/0 delete - -2. Remove IPv6 from net services. The file /etc/netsvc.conf, on AIX, -is roughly equivalent to /etc/nsswitch.conf on Solaris/Linux. - -The default, on AIX, is thus: - - hosts=local,bind - -Replace this with: - - hosts=local4,bind4 - -to deactivate searching for IPv6 addresses. - - -Shared Linking --------------- - -Shared libraries in AIX are different from shared libraries in Linux. - -A shared library on AIX is an 'ar' archive containing shared objects. A -shared object is produced by the linker when invoked appropriately (e.g. -with -G), it is what we call a shared library on Linux. - --> On AIX, you can do a static as well as a dynamic --> link against a shared library, it depends on how you --> invoke the linker. - -When you link statically, the shared objects from the library are added -to your executable as required; when you link dynamically, only -references to the shared objects are included in the executable. - -Consequently you do not need a separate static library on AIX if you -have a dynamic library. - -However, you CAN have static libraries (ar archives containing *.o -files), and the linker will link against them. This will of course -always be a static link. - -When the AIX linker searches for libraries to link, it will look for a -library libxy.a as well as for a single shared object libxy.so when you -tell it to -lyx. When it finds both in the same directory, it will -prefer libpq.a unless invoked with -brtl. - -This is where the problem occurs: - -By default, PostgreSQL will (in the Linux way) create a shared object -libpq.so and a static library libpq.a in the same directory. - -Up to now, since the linker was invoked without the -brtl flag, linking -on AIX was always static, as the linker preferred libpq.a over libpq.so. - -We could have solved the problem by linking with -brtl on AIX, but we -chose to go a more AIX-conforming way so that third party programs -linking against PostgreSQL libraries will not be fooled into linking -statically by default. - -The 'new way' on AIX is: -- Create libxy.so.n as before from the static library - libxy.a with the linker. -- Remove libxy.a -- Recreate libxy.a as a dynamic library with - ar -cr libxy.a libxy.so.n -- Only install libxy.a, do not install libxy.so - -Since linking is dynamic on AIX now, we have a new problem: - -We must make sure that the executable finds its library even if the -library is not installed in one of the standard library paths (/usr/lib -or /lib). - -On Linux this is done with an RPATH, on AIX the equivalent is LIBPATH -that can be specified at link time with -blibpath: -. If you do not specify the LIBPATH, it is automatically computed from -the -L arguments given to the linker. The LIBPATH, when set, must -contain ALL directories where shared libraries should be searched, -including the standard library directories. - -Makefile.aix has been changed to link executables with a LIBPATH that -contains --libdir when PostgreSQL is configured with --enable-rpath (the -default). - -The AIX equivalent for the Linux environment variable LD_LIBRARY_PATH is -LIBPATH. - -The regression tests rely on LD_LIBRARY_PATH and have to be changed to -set LIBPATH as well. - -Laurenz Albe - diff --git a/doc/src/sgml/installation.sgml b/doc/src/sgml/installation.sgml index 7c86d2521f..c87bd3a477 100644 --- a/doc/src/sgml/installation.sgml +++ b/doc/src/sgml/installation.sgml @@ -1,4 +1,4 @@ - + <![%standalone-include[<productname>PostgreSQL</>]]> @@ -2041,6 +2041,302 @@ kill `cat /usr/local/pgsql/data/postmaster.pid` installation issues. </para> + <sect2 id="installation-notes-aix"> + <title>AIX + + + AIX + installation on + + + + PostgreSQL on AIX works, but getting it installed properly can be + challenging. Both AIX version 4.3 and 5.3 are supported in + theory. You can use GCC or the native IBM compiler xlc. In + general, using recent versions of AIX and PostgreSQL helps. Check + the build farm for up to date information about which versions of + AIX are known to work. + + + + Use the following configure flags in addition + to your own if you have Readline or libz + there: --with-includes=/usr/local/include + --with-libraries=/usr/local/lib. + + + + If you don't have a PowerPC or use GCC you might see rounding + differences in the geometry regression test. There will probably + be warnings about 0.0/0.0 division and duplicate symbols which you + can safely ignore. + + + + Some of the AIX tools may be a little different + from what you may be accustomed to on other platforms. If you are + looking for a version of ldd, useful for + determining what object code depends on what libraries, the + following URLs may help you: + , + . + + + + AIX 4.3.2 + + + On AIX 4.3.2, you need libm.a that is in the + fileset bos.adt.libm. Try the following command: + +$ lslpp -l bos.adt.libm + + + + + + GCC issues + + + On AIX 5.3, there have been some problems getting PostgreSQL to + compile and run using GCC. + + + + You will want to use a version of GCC subsequent to 3.3.2, + particularly if you use a prepackaged version. We had good + success with 4.0.1. Problems with earlier versions seem to have + more to do with the way IBM packaged GCC than with actual issues + with GCC, so that if you compile GCC yourself, you might well + have success with an earlier version of GCC. + + + + + Unix-domain sockets broken + + + AIX 5.3 has a problem + where sockadr_storage is not defined to + be large enough. In version 5.3, IBM increased the size of + sockaddr_un, the address structure for + Unix-domain sockets, but did not correspondingly increase the + size of sockadr_storage. The result of + this is that attempts to use Unix-domain sockets with PostgreSQL + lead to libpq overflowing the data structure. TCP/IP connections + work OK, but not Unix-domain sockets, which prevents the + regression tests from working. + + + + The problem was reported to IBM, and is recorded as bug report + PMR29657. If you upgrade to maintenance level 5300-03, that will + include this fix. Use the command oslevel -r + to determine what maintenance level you are at. An immediate + resolution is to alter _SS_MAXSIZE to = 1025 in + /usr/include/sys/socket.h. + + + + + Memory Management + + + + AIX can be somewhat peculiar with regards to the way it does + memory management. You can have a server with many multiples of + gigabytes of RAM free, but still get out of memory or address + space errors when running applications. One example + is createlang failing with unusual errors. + For example, running as the owner of the PostgreSQL installation: + +-bash-3.00$ createlang plpgsql template1 +createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": A memory address is not in the address space for the process. + + Running as a non-owner in the group posessing the PostgreSQL + installation: + +-bash-3.00$ createlang plpgsql template1 +createlang: language installation failed: ERROR: could not load library "/opt/dbs/pgsql748/lib/plpgsql.so": Bad address + + Another example is out of memory errors in the PostgreSQL server + logs, with every memory allocation near or greater than 256 MB + failing. + + + + The overall cause of all these problems is the default bittedness + and memory model used by the server process. By default, all + binaries built on AIX are 32-bit. This does not depend upon + hardware type or kernel in use. These 32-bit processes are + limited to 4 GB of memory laid out in 256 MB segments using one + of a few models. The default allows for less than 256 MB in the + heap as it shares a single segment with the stack. + + + + In the case of the createlang example, above, + check your umask and the permissions of the binaries in your + PostgreSQL installation. The binaries involved in that example + were 32-bit and installed as mode 750 instead of 755. Due to the + permissions being set in this fashion, only the owner or a member + of the possessing group can load the library. Since it isn't + world-readable, the loader places the object into the process' + heap instead of the shared library segments where it would + otherwise be placed. + + + + The ideal solution for this is to use a 64-bit + build of PostgreSQL, but that is not always practical, because + systems with 32-bit processors can build, but not run, 64-bit + binaries. + + + + If a 32-bit binary is desired, set LDR_CNTRL to + MAXDATA=0xn0000000, + where 1 <= n <= 8, before starting the PostgreSQL server, + and try different values and postgresql.conf + settings to find a configuration that works satisfactorily. This + use of LDR_CNTRL tells AIX that you want the + server to have MAXDATA bytes set aside for the + heap, allocated in 256 MB segments. When you find a workable + configuration, + ldedit can be used to modify the binaries so + that they default to using the desired heap size. PostgreSQL can + also be rebuilt, passing configure + LDFLAGS="-Wl,-bmaxdata:0xn0000000" + to achieve the same effect. + + + + For a 64-bit build, set OBJECT_MODE to 64 and + pass CC="gcc -maix64" + and LDFLAGS="-Wl,-bbigtoc" + to configure. (Options for + xlc might differ.) If you omit the export of + OBJECT_MODE, your build may fail with linker errors. When + OBJECT_MODE is set, it tells AIX's build utilities + such as ar, as, and ld what + type of objects to default to handling. + + + + By default, overcommit of paging space can happen. While we have + not seen this occur, AIX will kill processes when it runs out of + memory and the overcommit is accessed. The closest to this that + we have seen is fork failing because the system decided that + there was not enough memory for another process. Like many other + parts of AIX, the paging space allocation method and + out-of-memory kill is configurable on a system- or process-wide + basis if this becomes a problem. + + + + References and resources + + + + <ulink url="http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/lrg_prg_support.htm">Large Program Support</ulink> + + + AIX Documentation: General Programming Concepts: Writing and Debugging Programs + + + + + + <ulink url="http://publib.boulder.ibm.com/infocenter/pseries/topic/com.ibm.aix.doc/aixprggd/genprogc/address_space.htm">Program Address Space Overview</ulink> + + + AIX Documentation: General Programming Concepts: Writing and Debugging Programs + + + + + + <ulink url="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/resmgmt2.htm">Performance Overview of the Virtual Memory Manager (VMM)</ulink> + + + AIX Documentation: Performance Management Guide + + + + + + <ulink url="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf7.htm">Page Space Allocation</ulink> + + + AIX Documentation: Performance Management Guide + + + + + + <ulink url="http://publib.boulder.ibm.com/infocenter/pseries/v5r3/topic/com.ibm.aix.doc/aixbman/prftungd/memperf6.htm">Paging-space thresholds tuning</ulink> + + + AIX Documentation: Performance Management Guide + + + + + <ulink url=" http://www.redbooks.ibm.com/abstracts/sg245674.html?Open">Developing and Porting C and C++ Applications on AIX</ulink> + + IBM Redbook + + + + + + + Statistics Collector Issues + + + + When implementing PostgreSQL version 8.1 on AIX 5.3, we + periodically ran into problems where the statistics collector + would mysteriously not come up successfully. This + appears to be the result of unexpected behaviour in the IPv6 + implementation. It looks like PostgreSQL and IPv6 do not play + very well together at this time on AIX. + + + + Any of the following actions fix the problem. + + + + Delete the IPv6 address for localhost: + +(as root) +# ifconfig lo0 inet6 ::1/0 delete + + + + + + + Remove IPv6 from net services. The + file /etc/netsvc.conf on AIX is roughly + equivalent to /etc/nsswitch.conf on + Solaris/Linux. The default, on AIX, is thus: + +hosts=local,bind + + Replace this with: + +hosts=local4,bind4 + + to deactivate searching for IPv6 addresses. + + + + + + + Cygwin diff --git a/src/Makefile.shlib b/src/Makefile.shlib index 5bf5b818c1..f6136a7a87 100644 --- a/src/Makefile.shlib +++ b/src/Makefile.shlib @@ -6,7 +6,7 @@ # Copyright (c) 1998, Regents of the University of California # # IDENTIFICATION -# $PostgreSQL: pgsql/src/Makefile.shlib,v 1.117 2008/09/01 08:50:09 petere Exp $ +# $PostgreSQL: pgsql/src/Makefile.shlib,v 1.118 2008/11/24 11:59:37 petere Exp $ # #------------------------------------------------------------------------- @@ -479,6 +479,7 @@ ifeq ($(enable_shared), yes) install-lib-shared: $(shlib) installdirs-lib ifdef soname # we don't install $(shlib) on AIX +# (see http://archives.postgresql.org/message-id/52EF20B2E3209443BC37736D00C3C1380A6E79FE@EXADV1.host.magwien.gv.at) ifneq ($(PORTNAME), aix) $(INSTALL_SHLIB) $< '$(DESTDIR)$(libdir)/$(shlib)' ifneq ($(PORTNAME), cygwin)