I am trying to build postgresql-7.2.3-r1 on gentoo-1.4-rc1 PPC, but backend comiplation gives me the following: ... access/SUBSYS.o: In function `XLogFlush': access/SUBSYS.o(.text+0x23cb8): undefined reference to `tas' access/SUBSYS.o(.text+0x23cb8): relocation truncated to fit: R_PPC_REL24 tas access/SUBSYS.o(.text+0x25964): more undefined references to `tas' follow access/SUBSYS.o: In function `CreateCheckPoint': access/SUBSYS.o(.text+0x25964): relocation truncated to fit: R_PPC_REL24 tas ... storage/SUBSYS.o: In function `s_lock': storage/SUBSYS.o(.text+0xe9f0): relocation truncated to fit: R_PPC_REL24 tas collect2: ld returned 1 exit status make[2]: *** [postgres] Error 1 make[2]: Leaving directory `/var/tmp/portage/postgresql-7.2.3-r1/work/postgresql-7.2.3/src/backend' ... Same postgresql release is build (ebuild) fine on Gentoo-1.4-rc1-x86. Same version of postgresql from vanilla sources is compiled fine on the same Gentoo-1.4-rc1-PPC. I thought the problem in ppc patches in postgresql ebuild, but they seem also fine. So, what else did I miss?
Later I've tried other 7.x ebuild - sma eresult. I've tried to comment out the call to patch in ebuild files - same results. But the most strange thing is that I've tried to build from vanilla sources of the same source code tarballs OUTSIDE of portage (tar zxvf $; cd $; ./configure ; make ) with the SAME --with config flags - the result was positive and postgresql has been build sucessfully. So, the problem is not in pathes. And I doubt the probelm is in the operating system in general. It's more likely that the problem is in somewhere in portage system. Unless I still miss something.
Hope you don't mind me transfering this to you trance...
If it makes any sense: that was on Powerbook Pismo with G3 and -O3. After I've just installed Gentoo on grey-G4 with -O2 it helped to compile. But now it cannot initialize: "vacuuming database template1... /usr/bin/initdb: line 647: 7666 Segmentation fault" Does it help?
not sure how active trance is, I took over the bug, as of yet I have been unable to make _any_ version of postgresql work on ppc w/ gcc 3.2 Will look into this further
ok, need some help I've built the latest one successfully with these cflags: -pipe -fsigned-char it seems that it doesnt like any -O optimization (is same for 2 other distros). I got past initdb, etc, but know next to nothing about postgresl, it complains about shared memory allocations and the like. Can you try to emerge it like this: USE="-*" CFLAGS="-pipe -fsigned-char" emerge /usr/portage/dev-db/postgresql/postgresql-7.2.3-r1.ebuild let me know if it's working ok, if it is I will commi to filter the -Ox flags and we can go from there.
I've been using postgresql 7.2.3-r1 on ppc (iMac G3), with the 1.4 rc, for a week or two now. I used the standard G3 optimisations from make.conf with no problems in compiling. There _is_ an issue with the init script: the line that calls postmaster does ask it to use too much shared memory (at least for this setup)- i.e. to accept too many connections (1024, which is the default - go figure). There may be a better fix, but a quick fix is to change that line to end with "-N 768 -B 2048". There also seem to be random issues with the config stage of the ebuild not getting the permissions right for setting up the data directory. Brute force (re-running the ebuild config until it got it right) worked for me. I've just installed gentoo 1.4 on my tiBook, and postgres failed to compile on first attempt. I'll follow up if I can get it to work.
hey daybird, thought you had dissappeared into the void there... try the CFLAGS from above if you would, seems to work for me,and stop by irc and say Hi! ;)
I confirm: <code>USE="-*" CFLAGS="-pipe -fsigned-char"</code> helps to compile and run without segfaults. <code>"-N 768 -B 2048"</code> helps to run after I added one more fix: the user postgres in /etc/passwd should have /bin/bash rather than /bin/false. Otherwise it doesn't start. I'll run more crashing regression tests later and report a problem if I'll meet such. Should new flags and rc.script (and et/c/passwd?) patch be included to the portage? P.S. Why -N 768? For personal development AND web-server's db-connection pool even -N 32 is enough. The real value anyway should be set by db admin after lots of perfomance and configuration tests, which are not related to portage.
Correction: ==== USE="-*" CFLAGS="-pipe -fsigned-char" helps to compile it without error (experienced on the PPC box with -O3 system-wide) and run it without segfaults (experienced on the PPC box with -O2 system-wide). "-N 768 -B 2048" helps to start it, although after I added one more fix: the user postgres in /etc/passwd should have /bin/bash rather than /bin/false. Otherwise it doesn't start. Besides, postgres user helps to create real users in the DB. (Should ebuild config also set up some default passwd for that user? Alternatively, should ebuild config also add root to the db user list?) I'll run more crashing regression tests later and report a problem if I'll meet such. Should new cflags and ebuild config changes be included to the portage? P.S. Why -N 768? For personal development AND web-server's db-connection pool even -N 32 is enough. The real value anyway should be set by db admin after lots of perfomance and configuration tests, which are not related to portage. Besides, the style of Gentoo is minimalistic: no unnecessary resource consumption, isn't it?
I have set these CFLAGS for ppc on latest build only, set all others as -ppc. Will pass this back to rphillips for other issues (I am truly a postgresql ludite and can't properly finish the non ppc specific parts)
rphillips: any comments etc on this situation?
Tossing this back to bug wranglers, it needs attention as this build is _always_ problematic and it's been come time now
I can't test this on PPC... I haven't had any trouble with the ebuild on x86.
I was looking for comments on this post: http://bugs.gentoo.org/show_bug.cgi?id=10800#c9 The ppc portions are taken care of already.
Can anyone else verify this? If so, this bug can be closed, as it appears to only be a PPC problem, and if that is now fixed, this bug is also resolved.
was looking for thoughts/answers on this quote from earlier: P.S. Why -N 768? For personal development AND web-server's db-connection pool even -N 32 is enough. The real value anyway should be set by db admin after lots of perfomance and configuration tests, which are not related to portage.
well I guess I will close this bug due to lack of interest for the postgres sql devs. rather disheartening to say the least.
