I have both a postgres 8.4 and 9.0 installation on a machine because I am doing some performance comparisons between the two. If I use "eselect postgresql ..." to switch both the Utilities and Service over to 9.0, I can see that the include/ and lib/ symlinks are made correctly. If I compile a test program and link against -lpq, then run ldd ./a.out, that shows me it will _run_ against libpq.so.5 within the postgresql-8.4/lib directory. The only thing I notice is that in /etc/env.d, both are present, and since the lib is libpq.so.5.3 in both cases, it seems to just pick the first one. I know Aaron mentions a new eselect module for postgresql in bug #343883, so this may already be fixed in that.
Yes, I have taken this into consideration and the updated module will handle this properly. This bug will remain open as it will be a month or two before the module can hit the tree. (Init script and ebuild changes need to take place, so those updates have to hit the tree first.)
Excellent, thanks for the update. For the interim I will just do "LD_LIBRARY_PATH=/path/to/the/one/i/want ./my_prog", does that sound reasonable?
(In reply to comment #2) > Excellent, thanks for the update. For the interim I will just do > "LD_LIBRARY_PATH=/path/to/the/one/i/want ./my_prog", does that sound > reasonable? > Yup, that should do it.
Please review app-admin/eselect-postgresql-1.0.3. It should resolve this issue.
Hmm, it does not seem to be making the library symlink in /usr/lib(64) for me
(In reply to comment #5) > Hmm, it does not seem to be making the library symlink in /usr/lib(64) for me I need more details, please. I don't have a 64 bit system to test the module on, so I had to make a couple logical leaps. Where is it failing? Where is the lib actually located?
It doesn't seem to fail, there just is not a symlink in /usr/lib64 (but the include symlink is correct it seems). My libs are located in: /usr/lib64/postgresql-9.0/lib64/libpq.so.* /usr/lib64/postgresql-8.4/lib64/libpq.so.* Just ask if you need anything else.
(In reply to comment #7) > Just ask if you need anything else. You've been a great deal of help. Thanks for the quick response.
eselect-postgresql-1.0.4 has been committed. Please review.
Hmm still not working for me. When I attempt to switch with 'eselect postgresql set 9.0' (or 8.4), I get something like: Setting 8.4 as the default installation... Removing old links...done. Generating new links.../usr/share/eselect/modules/postgresql.eselect: line 190: /etc/eselect/postgresql/active: Is a directory done. Not sure what the warning means, or if it's relevant. Despite this, my /usr/include/postgresql and /usr/lib/libpq.so seems to be set correctly. Also, my LDPATH seems to always be using 8.4's .so. If I link a small test program (like int main() {} ) with g++ test.cpp -lqp Then ldd ./a.out, I always see libpq.so.5 => /usr/lib64/postgresql-8.4/lib64/libpq.so.5 (0x00007f073ca5e000) Even if I have 9.0 selected for the test. Hope that helps.
Try: eselect postgresql update That should clean up the remnants from <app-admin/eselect-postgresql-1.0.3
seems to have worked, all lib and include symlinks seems to set up correctly
*** Bug 361563 has been marked as a duplicate of this bug. ***
*** Bug 359361 has been marked as a duplicate of this bug. ***
02 Apr 2011; Aaron W. Swenson <titanofold@gentoo.org> -eselect-postgresql-1.0.3.ebuild, -eselect-postgresql-1.0.4.ebuild, +eselect-postgresql-1.0.6.ebuild: Remove obsolete ebuilds. Fixes bugs #327441, 352147 and 292122.
(In reply to comment #14) > *** Bug 359361 has been marked as a duplicate of this bug. *** I don't think this is eselect related (maybe only for compiling 3rd party apps against postgresql-base) , the postgresql-server ebuilds shouldn't use the e.g. /usr/lib/libpq libs but the libs of their corresponding slot. But they do this. I mad this experience when emerging 9.0 with an active 8.1 slot. The links in /usr/lib and /usr/include are all set up correctly, but still my libpqwalreceiver.so was linked to the libpq from the 8.1 slot. So fixing wrong symlinks is one story, but using the right libs at linking/emerging is another. I already wrote im my (#359361) report, that I think the order of -L opts when linking should be changed, i.e. slotted libs BEFORE /usr/lib, but I'm not a gcc/makefile guru. Gerhard
"But they do this". should be But they DON'T do this. Sorry.
(In reply to comment #17) > "But they do this". should be But they DON'T do this. Sorry. Shouldn't post that early in the morning ;-) The original post was OK, so IMHO when linking a 9.0 slotted package, there should never ever be references to the (symlinked) libs of libpq of an other slot (was the case for libpqwalreceiver.so when I tried to emerge postgresql-server-9.0.3-r3 while having an active 8.1 slot installed) Phew, now I got it right. :-)
(In reply to comment #18) > (In reply to comment #17) > > "But they do this". should be But they DON'T do this. Sorry. > > Shouldn't post that early in the morning ;-) The original post was OK, so IMHO > when linking a 9.0 slotted package, there should never ever be references to > the (symlinked) libs of libpq of an other slot (was the case for > libpqwalreceiver.so when I tried to emerge postgresql-server-9.0.3-r3 while > having an active 8.1 slot installed) > Phew, now I got it right. :-) Please try these steps, and if the issue persists, open a new bug as the issue isn't as described on this bug: emerge =app-admin/eselect-postgresql-1.0.6 emerge =dev-db/postgresql-base-9.0.3-r1 emerge =dev-db/postgresql-server-9.0.3-r3
Will try this tomorrow. BTW, someone linked my original bug report http://bugs.gentoo.org/show_bug.cgi?id=361563 as a duplicate to this one, but I think it is different.
