Summary: | Make postgresql compatible with multilib-native | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Bernhard Frauendienst <gentoo> |
Component: | New packages | Assignee: | PgSQL Bugs <pgsql-bugs> |
Status: | RESOLVED WONTFIX | ||
Severity: | enhancement | CC: | ferret-bgo, mva, pgsql-bugs |
Priority: | High | ||
Version: | 2008.0 | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | patch for postgresql-{base,server}-8.4.2 for multilib-native compatibility |
Description
Bernhard Frauendienst
2010-01-05 18:11:07 UTC
Created attachment 215321 [details, diff]
patch for postgresql-{base,server}-8.4.2 for multilib-native compatibility
Something I should probably add: the main reason why we actually need 32bit binaries for postgres is that most build systems and ebuilds depending on postgresql use pg_config --libdir to find the postgresql libraries. If this binary only exists as 64bit, 32bit applications will try to link against 64bit pgsql libs, which of course fails. PS: Apologies for CC'ing the postgresql herd, I was told (too late) that I shouldn't have done this. Won't happen again ;) Good idea. native-multilib is still a good while away, so there's nothing we can do now. Reopen if it ever becomes a real issue :) Comment on attachment 215321 [details, diff]
patch for postgresql-{base,server}-8.4.2 for multilib-native compatibility
Unfortunately, this solution will not work. libexec is reserved for executables that are not meant to be directly invoked by the user or a script.
The eselect module is now a bit more sophisticated and can handle multilib, in theory.
I will consider this if there is someone that can provide an example of some program that will not work with PostgreSQL, and if there is sufficient demand.
Otherwise, I lack the interest in supporting such a setup as I am on 64-bit no-multilib.
*** Bug 589340 has been marked as a duplicate of this bug. *** |