When building, I get this error: make[3]: Leaving directory `/gentoo/var/tmp/portage/dev-db/postgresql-base-9.0_beta2-r1/work/postgresql-9.0beta2/src/interfaces/libpq' x86_64-apple-darwin10-gcc -no-cpp-precomp -O2 -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -bundle -multiply_defined suppress libpqwalreceiver.o -bundle_loader ../../../../src/backend/postgres -L../../../../src/interfaces/libpq -L../../../../src/port -lpq -o libpqwalreceiver.so collect2: ld terminated with signal 6 [Abort trap] got unhandled exception: file not found: ../../../../src/backend/postgres terminate called after throwing an instance of 'char const*' make[2]: *** [libpqwalreceiver.so] Error 1 If I don't apply postgresql-9.0-base.2.patch, this doesn't happen. I don't have any idea what that patch does or why it's a good idea so I haven't taken a stab at fixing it. FWIW, Makefile.darwin, which is from upstream, references this "src/backend/postgres" directory, which doesn't exist. But as I said, pristine sources will compile fine. Reproducible: Always Configure line: ./configure --prefix=/gentoo/usr --build=x86_64-apple-darwin10 --host=x86_64-apple-darwin10 --mandir=/gentoo/usr/share/man --infodir=/gentoo/usr/share/info --datadir=/gentoo/usr/share --sysconfdir=/gentoo/etc --localstatedir=/gentoo/var/lib --prefix=/gentoo/usr/lib/postgresql-9.0 --datadir=/gentoo/usr/share/postgresql-9.0 --docdir=/gentoo/usr/share/doc/postgresql-9.0 --sysconfdir=/gentoo/etc/postgresql-9.0 --includedir=/gentoo/usr/include/postgresql-9.0 --mandir=/gentoo/usr/share/postgresql-9.0/man --enable-depend --without-tcl --without-perl --without-python --with-readline --without-krb5 --without-gssapi --enable-nls --without-pam --enable-integer-datetimes --with-openssl --disable-thread-safety --with-zlib --without-ldap
Upstream says, "FWIW, src/backend/postgres would typically be a file generated during the build process, not a directory."
@postgres/patrick: any idea what's going wrong here? The base.2.patch seems a huge aggregation of misc fixes to me.
(In reply to comment #2) > @postgres/patrick: any idea what's going wrong here? The base.2.patch seems a > huge aggregation of misc fixes to me. > That's a good question. On my system it doesn't build without the patches.
Created attachment 237633 [details] emerge --info, in case it helps
The patch in question removes certain bits of various lists that determine what will be compiled. In this case, we only need to compile the client libraries and applications. So it isn't a collection of fixes, it's a collection of tweaks or toggles, if you will.
Created attachment 238501 [details] build.log That does make sense. Here's the full build log. Is there anything else I can provide to illuminate the problem?
9.0_beta3 will hit the tree sometime soon. We'll see if it fixes this automagically.
9.0_beta3 is in the tree now. Please tell us if the issue persists.
This problem persists in beta3: make[3]: Leaving directory `/gentoo/var/tmp/portage/dev-db/postgresql-base-9.0_beta3/work/postgresql-9.0beta3/src/interfaces/libpq' x86_64-apple-darwin10-gcc -no-cpp-precomp -O2 -pipe -march=nocona -msse -mfpmath=sse -Wall -Wmissing-prototypes -Wpointer-arith -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv -bundle -multiply_defined suppress -o libpqwalreceiver.so libpqwalreceiver.o -L../../../../src/port -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs -L../../../../src/interfaces/libpq -lpq -bundle_loader ../../../../src/backend/postgres collect2: ld terminated with signal 6 [Abort trap] got unhandled exception: file not found: ../../../../src/backend/postgres terminate called after throwing an instance of 'char const*' make[2]: *** [libpqwalreceiver.so] Error 1
(In reply to comment #9) > This problem persists in beta3: > > > make[3]: Leaving directory > `/gentoo/var/tmp/portage/dev-db/postgresql-base-9.0_beta3/work/postgresql-9.0beta3/src/interfaces/libpq' > x86_64-apple-darwin10-gcc -no-cpp-precomp -O2 -pipe -march=nocona -msse > -mfpmath=sse -Wall -Wmissing-prototypes -Wpointer-arith > -Wdeclaration-after-statement -Wendif-labels -fno-strict-aliasing -fwrapv > -bundle -multiply_defined suppress -o libpqwalreceiver.so libpqwalreceiver.o > -L../../../../src/port -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs > -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs -Wl,-dead_strip_dylibs > -Wl,-dead_strip_dylibs -L../../../../src/interfaces/libpq -lpq -bundle_loader > ../../../../src/backend/postgres > collect2: ld terminated with signal 6 [Abort trap] > got unhandled exception: file not found: ../../../../src/backend/postgres > terminate called after throwing an instance of 'char const*' > make[2]: *** [libpqwalreceiver.so] Error 1 > What happens if you set MAKEOPTS="-j1"? (My thinking here is maybe a job is getting too far ahead.) BTW, there's a beta4 available now. Give that a shot as well. (A simple name change of the ebuild and a 'repoman manifest' in the ebuild's directory will do the trick.) Additionally, this should be reported upstream -- pgsql-bugs at postgresql.org -- if this doesn't happen with 8.4.4. We didn't change a whole heck of a lot from the older version to this version. And what we did change shouldn't have caused this issue. (We being the guys handling the x86-portage version of the ebuild, not the Prefix version.)
Alas, beta4 with MAKEOPTS="-j1" gives the same error. I originally filed this as PostgreSQL #5537, but came here when they said they were able to build fine on 10.6.4 x86_64. I would like to repro this on raw MacOS and a fresh Prefix install before going back to them.
Same problem in rc1.
9.0.0 is in the x86 tree now.
9.0.1 gives the same error. Bump?
Created attachment 254923 [details, diff] PostgreSQL Darwin Patch See if this patch does the trick.
The patch does not appear to have made any difference, unfortunately.
In the past I've made an account available on my machine for debugging. If that would be helpful, send me your public key and I'll send the login info.
Same error on 9.0.2. Maybe this could help: http://postgresql.1045698.n5.nabble.com/Re-COMMITTERS-pgsql-Improved-parallel-make-support-tp3263262p3266483.html
(In reply to comment #18) > Same error on 9.0.2. > > Maybe this could help: > > http://postgresql.1045698.n5.nabble.com/Re-COMMITTERS-pgsql-Improved-parallel-make-support-tp3263262p3266483.html > Upstream has a tendency to not back port patches to makefiles. I'm not comfortable enough with makefiles to really fiddle with that stuff. There are some other things, though, that I've discovered about the current postgresql-9.0-base.3.patch that I'm going to fix and we'll see if that helps matters.
> Upstream has a tendency to not back port patches to makefiles. I'm not > comfortable enough with makefiles to really fiddle with that stuff. > > There are some other things, though, that I've discovered about the current > postgresql-9.0-base.3.patch that I'm going to fix and we'll see if that helps > matters. > P.S.: I did see those changes that they talked about in the 9.1alpha3 makefiles.
The upstream sources do not exhibit this problem, and I've traced the issue to a specific hunk in postgresql-9.0-base.3.patch. Postgres builds properly if this section is removed from postgresql-9.0-base.3.patch: --- postgresql-9.0beta3.orig/src/backend/Makefile 2010-07-05 14:54:37.000000000 -0400 +++ postgresql-9.0beta3/src/backend/Makefile 2010-07-11 23:46:58.347527452 -0400 @@ -45,7 +45,7 @@ ########################################################################## -all: submake-libpgport submake-schemapg postgres $(POSTGRES_IMP) +all: someheaders ifneq ($(PORTNAME), cygwin) ifneq ($(PORTNAME), win32) @@ -114,7 +114,7 @@ endif # aix # Update the commonly used headers before building the subdirectories -$(SUBDIRS:%=%-recursive): $(top_builddir)/src/include/parser/gram.h $(top_builddir)/src/include/catalog/schemapg.h $(top_builddir)/src/include/utils/fmgroids.h $(top_builddir)/src/include/utils/probes.h +someheaders $(SUBDIRS:%=%-recursive): $(top_builddir)/src/include/parser/gram.h $(top_builddir)/src/include/utils/fmgroids.h $(top_builddir)/src/include/utils/probes.h # run this unconditionally to avoid needing to know its dependencies here: submake-schemapg: I'll attach a complete, functioning postgresql-9.0-base.3.patch.
Created attachment 263391 [details] corrected postgresql-9.0-base.3.patch file
That patch isn't quite corrected yet. As soon as I have a working Prefix, I'll be able to check my fixes. I'll be sure to keep your changes in mind if my changes still don't result in success.
Fixed. dev-db/postgresql-base/ChangeLog: 21 Mar 2011; Aaron W. Swenson <titanofold@gentoo.org> +postgresql-base-8.2.20-r1.ebuild, +postgresql-base-8.3.14-r1.ebuild, +postgresql-base-8.4.7-r1.ebuild, +postgresql-base-9.0.3-r1.ebuild: Fixes bugs 353750, 326699 and 355945
The latest version in my $EPREFIX/usr/portage is still postgresql-base-9.0.2 which seems to be unpached and doesn't compile. Is the fix still hanging somewhere?
Yes, in the main gentoo-x86 tree, not the Prefix tree.
hmmm, I synced that not too long ago Would it be an option to skip the Prefix overlay's ebuilds entirely and just try and see what happens if we switch to gx86's ones?
@Fabian: I'm still bumping into the original "ld: file not found: ../../../../src/backend/postgres" issue with postgresql-base-9.0.2 after "emerge --sync".
I'm going to drop the prefix overlay versions, and get postgresql straight from gx86, we can check then what the status is. It's getting too confusing for me now.
Okay, please drop a comment here if you'd like me to test on Darwin. (Should we reopen this bug?)
ok, reopening. I just committed the switch, should be taken into the regen, so available on rsync in half an hour or so
Mind that only the -r* version of the ebuilds are Prefix compatible. And none of those are stable, yet.
we don't do stable keywords, so I don't see a direct problem there :)
postgresql-base-9.0.3-r1 and postgresql-server-9.0.3-r3 emerge on i386 Darwin. However, as was to be expected on Prefix, "eselect postgresql set-all 9.0" causes "!!! Error: -1 Selected installation doesn't provide PostgreSQL service". And "emerge --config =dev-db/postgresql-server-9.0.3-r3" gets stuck at the "Are you ready to continue?" question (no answer is recognized). I can figure out why tomorrow, it's a little late now.
Are you using eselect-postgresql 0.4?
Actually, take a look at app-admin/eselect-postgresql-1.0.4. (Should fix a fair bit of the issues in 1.0.3.) And should be mostly Prefix compatible. (Maybe 100%? I don't know, you tell me.)
(In reply to comment #35) > Are you using eselect-postgresql 0.4? Yes.
ok, I'll copy eselect-postgresql straight from gx86 then too. thanks Aaron for your work/support
I've submitted a bug/patch to fix the answer matchers in pkg_config: #326699
postgresql-base-9.0.3-r1 and postgresql-server-9.0.3-r3 emerge *and work* fine on Darwin i386. Two problems, however, I'm not sure how to tackle: (1) The "chmod" and "su" lines in pkg_config are no good on Prefix. Are there wrappers which could be used instead? (2) The server configuration files are no longer in the DATADIR ($EPREFIX/var/lib/postgresql/9.0/data), but in $EPREFIX/etc/postgresql-9.0. I don't see how to tell pg_ctl to look for the configuration files in another place but the DATADIR, is there a way? It works fine if I symlink the files in $EPREFIX/etc/postgresql-9.0 to the DATADIR
(In reply to comment #40) > postgresql-base-9.0.3-r1 and postgresql-server-9.0.3-r3 emerge *and work* fine > on Darwin i386. > > Two problems, however, I'm not sure how to tackle: > > (1) > The "chmod" and "su" lines in pkg_config are no good on Prefix. Are there > wrappers which could be used instead? > > (2) > The server configuration files are no longer in the DATADIR > ($EPREFIX/var/lib/postgresql/9.0/data), but in $EPREFIX/etc/postgresql-9.0. I > don't see how to tell pg_ctl to look for the configuration files in another > place but the DATADIR, is there a way? It works fine if I symlink the files in > $EPREFIX/etc/postgresql-9.0 to the DATADIR pg_ctl -D /etc/postgresql-9.0 -o '--data_directory=/var/lib/postgresql/9.0/data' start
Oh, and fowners should be used instead. I'll fix that. As for su, I don't know.
(In reply to comment #42) > Oh, and fowners should be used instead. I'll fix that. > > As for su, I don't know. Actually, no, it shouldn't. fowners will change to ${S}/${path}. pkg_config() just may never play nice with systems that don't understand su and chown. I'm up for a patch though that will make it play nice if there's a reliable way to determine the host environment. Additionally, the mkdir, chown, chmod and su steps are necessary to get the database cluster files owned by the 'postgres' system user, which is different from the 'postgres' database superuser. Now, because Prefix is a strange beast, those steps could be skipped if the server will be started by a user other than 'postgres'. http://www.postgresql.org/docs/9.0/static/app-initdb.html
> pg_ctl -D /etc/postgresql-9.0 -o > '--data_directory=/var/lib/postgresql/9.0/data' start Funky, "where there's a will, there's a way". Thanks for the hint.
we usually do use prefix || chown bla, but wrapping the part in if [[ ${EUID} == 0 ]] ; then works for me too (and may be more correct)
12 Apr 2011; Aaron W. Swenson <titanofold@gentoo.org> +postgresql-server-8.2.20-r3.ebuild, +postgresql-server-8.3.14-r3.ebuild, +postgresql-server-8.4.7-r3.ebuild, +postgresql-server-9.0.3-r4.ebuild: Prefix related changes to side step some of the things that can't be done on Prefix. Give those a go.
So, is this all fixed now?
I'm satisfied.
ok, closing then, thanks all!
