Hi@ll, I tried to compile my php in version 5.2.8, but always when he tried to compile postgres relevent stuff like the postgres extension and/or pdo it fails with the follow error. The funny thing is that the include path "/usr/include/postgresql" exists, but the compile command said "-I/usr/include/postgresql/libpq-4". I don't have this directory. ubuntu-steffen ~ # ll /usr/include/postgres* lrwxrwxrwx 1 root root 42 17. Okt 15:48 /usr/include/postgres_ext.h -> /usr/include/postgresql-8.3/postgres_ext.h lrwxrwxrwx 1 root root 27 17. Okt 15:48 /usr/include/postgresql -> /usr/include/postgresql-8.3 /usr/include/postgresql-8.3: insgesamt 132 -rw-r--r-- 1 root root 632 5. Dez 09:18 ecpg_config.h -rw-r--r-- 1 root root 2600 5. Dez 09:18 ecpgerrno.h -rw-r--r-- 1 root root 2776 5. Dez 09:18 ecpg_informix.h -rw-r--r-- 1 root root 2380 5. Dez 09:18 ecpglib.h -rw-r--r-- 1 root root 2560 5. Dez 09:18 ecpgtype.h drwxr-xr-x 3 root root 4096 28. Okt 14:36 informix drwxr-xr-x 3 root root 4096 5. Dez 09:19 internal drwxr-xr-x 2 root root 4096 5. Dez 09:19 libpq -rw-r--r-- 1 root root 18410 5. Dez 09:18 libpq-fe.h -rw-r--r-- 2 root root 21701 5. Dez 09:18 pg_config.h -rw-r--r-- 2 root root 8969 5. Dez 09:18 pg_config_manual.h -rw-r--r-- 3 root root 766 5. Dez 09:18 pg_config_os.h -rw-r--r-- 1 root root 814 5. Dez 09:18 pgtypes_date.h -rw-r--r-- 1 root root 588 5. Dez 09:18 pgtypes_error.h -rw-r--r-- 1 root root 1485 5. Dez 09:18 pgtypes_interval.h -rw-r--r-- 1 root root 2306 5. Dez 09:18 pgtypes_numeric.h -rw-r--r-- 1 root root 1057 5. Dez 09:18 pgtypes_timestamp.h -rw-r--r-- 2 root root 1837 5. Dez 09:18 postgres_ext.h drwxr-xr-x 2 root root 4096 5. Dez 09:19 postmaster drwxr-xr-x 22 root root 4096 5. Dez 09:19 server -rw-r--r-- 1 root root 834 5. Dez 09:18 sql3types.h -rw-r--r-- 1 root root 1267 5. Dez 09:18 sqlca.h Does anyone knows something about ?!?!? regards j0inty Reproducible: Always Steps to Reproduce: 1.emerge =postgresql-server-8.3.5 2.emerge php 3. Actual Results: In file included from /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/pdo_pgsql.c:31: /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/php_pdo_pgsql_int.h:27:28: error: libpq/libpq-fs.h: No such file or directory /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/pdo_pgsql.c:34:23: error: pg_config.h: No such file or directory /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/pdo_pgsql.c: In function 'zm_info_pdo_pgsql': /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/pdo_pgsql.c:123: error: 'PG_VERSION' undeclared (first use in this function) /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/pdo_pgsql.c:123: error: (Each undeclared identifier is reported only once /var/tmp/portage/dev-lang/php-5.2.8/work/php-5.2.8/ext/pdo_pgsql/pdo_pgsql.c:123: error: for each function it appears in.) make: *** [ext/pdo_pgsql/pdo_pgsql.lo] Error 1 Expected Results: A fine compiled file ;)
Created attachment 175349 [details] build log
Created attachment 175351 [details] emerge --info
Just curious, if I got you right this is not a problem which has been introduced in 5.2.8, right? Which other versions have you tested? I just want to know this as we need 5.2.8* stable rather soon because of security problems and whether this bug should be preventing us from doing so or not. Will have a deeper look at your issue later.
Hi, I was able to fix this problem by doing the following steps: cd /usr/include/postgresql ln -s . libpq-4 With that link the postgresql and pdo extensions compiled fine. regards j0inty
===Similar issues with other postgres apps? Is your postgres installation from the dev-db/postgresql-{base,server} (the newer) ebuilds, or is it from the dev-db/postgresql|dev-db/libpq (old) ebuilds? Have you made an upgrade from libpq before? I noticed that many emerge errors happened after I upgraded from postgresql/libpq ebuilds to the later postgresql-{base,server} ebuilds, errors of the same class as the error reported above. I did some head-bashing and discovered that programs keep trying to locate /usr/include/postgresql/libpq-4, which is wrong behavior on postgres-base which uses a different directory structure. try to see if other postgres-dependent apps merge properly without the libpq-4 symlink. On my case, I found that ruby-postgres and clisp also couldn't compile, as with I think a few other apps that I needed for tinyERP. For ebuilds running autoconf, the issue is quite similar with the program failing to find includes at libpq-4 or other similar stuff. ===pg_config leftovers Upon examination, I found that the build logs reference /usr/bin/pg_config, which you might think would belong to either postgresql-base or the eselect-postgresql ebuilds, but my equery says no way, no packages own the file. So I have a running theory. My theory is that installing and removing postgresql/libpq can somehow leave /usr/bin/pg_config without properly deleting it, and installing eselect-postgres will happily not clobber the file when it comes time to generate the pg_config. Which is right behavior for eselect-postgresql itself, but requires some vigilant log-reading to detect and results in hard to diagnose problems with the build system. pg_config is _then_ used by the build system to determine which libraries/includes to use when building php. When the old pg_config is left hanging around, it then reports the wrong folders to the build system, and all sorts of ebuilds would go crazy without their postgres. To determine if you have the situation I described, try running pg_config and determine if the postgresql libraries detected match the version that you have with you. If not, something must have gone when eselect-postgresql generated the config. Double double check that the pg_config doesn't belong to any other package with equery belongs /usr/bin/pg_config and if not, remove the file, and have eselect-postgresql generate new configs with eselect postgresql reset-all eselect postgresql set-all 8.3 #or whatever version you have with you eselect postgresql update and try reemerging /without/ the libpq-4 symlink workaround. Your php should compile properly, and so should pretty much anything depending on postgres. It did on my system. === Determining the cause of the leftover. To test the theory, I'd have to add and remove postgresql/libpq and postgresql-{base,server}/eselect-postgresql, then track how pg_config fares with various sequences of installation. It'll take quite a while, and I won't be happy to do it on production.
Hi, (In reply to comment #5) > ===Similar issues with other postgres apps? > Is your postgres installation from the dev-db/postgresql-{base,server} (the > newer) ebuilds, or is it from the dev-db/postgresql|dev-db/libpq (old) ebuilds? > Have you made an upgrade from libpq before? You are right. I upgraded from a previous version of postgresql. > I noticed that many emerge errors happened after I upgraded from > postgresql/libpq ebuilds to the later postgresql-{base,server} ebuilds, errors > of the same class as the error reported above. I did some head-bashing and > discovered that programs keep trying to locate /usr/include/postgresql/libpq-4, > which is wrong behavior on postgres-base which uses a different directory > structure. That must be the reason, because all my problems gone away when I add my fix. > try to see if other postgres-dependent apps merge properly without the libpq-4 > symlink. On my case, I found that ruby-postgres and clisp also couldn't > compile, as with I think a few other apps that I needed for tinyERP. For > ebuilds running autoconf, the issue is quite similar with the program failing > to find includes at libpq-4 or other similar stuff. I only found my reported 2 packages, but I don't needed more at time. > ===pg_config leftovers > Upon examination, I found that the build logs reference /usr/bin/pg_config, > which you might think would belong to either postgresql-base or the > eselect-postgresql ebuilds, but my equery says no way, no packages own the > file. > > So I have a running theory. My theory is that installing and removing > postgresql/libpq can somehow leave /usr/bin/pg_config without properly deleting > it, and installing eselect-postgres will happily not clobber the file when it > comes time to generate the pg_config. Which is right behavior for > eselect-postgresql itself, but requires some vigilant log-reading to detect and > results in hard to diagnose problems with the build system. > > pg_config is _then_ used by the build system to determine which > libraries/includes to use when building php. When the old pg_config is left > hanging around, it then reports the wrong folders to the build system, and all > sorts of ebuilds would go crazy without their postgres. > > To determine if you have the situation I described, try running > pg_config > and determine if the postgresql libraries detected match the version that you > have with you. If not, something must have gone when eselect-postgresql > generated the config. Double double check that the pg_config doesn't belong to > any other package with > equery belongs /usr/bin/pg_config > > and if not, remove the file, and have eselect-postgresql generate new configs > with > eselect postgresql reset-all > eselect postgresql set-all 8.3 #or whatever version you have with you > eselect postgresql update > > and try reemerging /without/ the libpq-4 symlink workaround. Your php should > compile properly, and so should pretty much anything depending on postgres. It > did on my system. The results of pg_config and this "workaround", I can't report at this moment, because I have to be back at work on monday the 12.01.2009. > === Determining the cause of the leftover. > To test the theory, I'd have to add and remove postgresql/libpq and > postgresql-{base,server}/eselect-postgresql, then track how pg_config fares > with various sequences of installation. It'll take quite a while, and I won't > be happy to do it on production. > regards j0inty
First, thanks for your analysis. This does not seem to be a php related issue but rather a update gone wrong in the postgresql department. As i've no experience there, i'm cc'ing the postgresql maintainers. @postgresql: can you have a look and state whether the discussed scenario is plausible/could cause this failure? Please close/reassign this bug as appropiate.
The problem, as has been shown in other bugs, seems to stem from dev-db/libpq still being present after dev-db/postgresql-base is emerged, and then dev-db/libpq being unmerged, which results in pertinent files/symbolic links being removed. The solution is to NOT circumvent the block.
+ 02 Jun 2010; Patrick Lauer <patrick@gentoo.org> + +postgresql-base-7.4.29-r1.ebuild, +postgresql-base-8.0.25-r1.ebuild, + +postgresql-base-8.1.21-r1.ebuild, +postgresql-base-8.2.17-r1.ebuild, + +postgresql-base-8.3.11-r1.ebuild, + +files/postgresql-base-8.4-9.0-heimdal_strlcpy.patch, + +postgresql-base-8.4.4-r1.ebuild, +postgresql-base-9.0_beta1-r1.ebuild: + Fixes for #313765, #251046, #294462, #300793, #274836, #296714, #238817, + #278228, #263096, #246397, #285953. Thanks to Aaron Swenson for collecting + the fixes and testing.
