postgresql-server fails to cross-compile unconditionally, because of dependency on "pg_config --configure" that is incorrectly called from / rather than SYSROOT and will therefore provide the wrong --host and --build values (or fail if / does not have native copy postgresql-server). Note that the package otherwise cross-compiles cleanly (as well as postgresql-base does). Reproducible: Always
Created attachment 373410 [details, diff] Adds sysroot to the prefix This fixes the problem, though there is probably a better way, as I believe the direct use of ${SYSROOT} in an ebuild is generally discouraged.
Firstly, it should be: local PO="${EROOT%/}" Secondly, that doesn't work in the way that you're describing. pg_config is a binary, not a shell script, so it will fail to execute pg_config at all. As it happens, it still manages to build because the options returned by pg_config are not strictly required. It falls back to a mixture of defaults and values provided by Portage. While the values provided by Portage are correct, I suspect the other default values may be wrong.
What would the suggested fix be, then? If the output of pg_config is not necessary, perhaps we should simply not use it for cross-compilation. It can also be possible to create two copies of the binary, one native and one cross-compiled. That sounds like something the pg build system does not even expect natively though, and I'd expect that even upstream cross-compiles somehow.
I have an idea but no time now, will post later.
Created attachment 383548 [details, diff] Alternative solution patch The sensible way to fix this might have been to copy the flags given in postgresql-base but that isn't going to work without adding a bunch more USE flags to IUSE. Not great. Here is a patch that implements an alternative solution that isn't particularly elegant but does work and requires little code. The "strings" tool can reveal the configure flags without actually running the binary. Anyone got any better ideas? ;) I'm still facing an issue though as I get undefined reference to `pthread_sigmask' when building pg_ctl. I'll investigate further soon.
That sounds .... shady. And I'd be very worried about future compatibility. One thing to consider is that the build split into -base -server etc. is generally Gentoo-specific. One thing is packaging the binaries/libs separately, another is actually building them separately. I don't know much about the considerations behind splitting the packages (which happened a long time ago), but merging the packages back into one seem like a straightforward possible solution (though I doubt someone will be willing), because in the upstream, they really are just one. The packages have to ALWAYS be exactly matched anyway and building them separately really seems like creating problems out of thin air. Another would be to leave some sort of build drop from the -base package and copy/reuse that for subsequent packages, ie. circumvent the need to call pg_config in another way. Eg. the config.log or simply a text file with the variables needed. Since versions need to be matched, there's no worry about back/forward compatibility between ebuild versions - they never mix anyway. Either way, I don't care very much how is it fixed, as long as it ultimately cross-compiles. :)
(In reply to Zdenek Behan from comment #6) > That sounds .... shady. And I'd be very worried about future compatibility. Shady perhaps but I can't think of any instance where it would fail. If it breaks later due to upstream changes, c'est la vie. It can always be amended. > One thing to consider is that the build split into -base -server etc. is > generally Gentoo-specific. One thing is packaging the binaries/libs > separately, another is actually building them separately. > > I don't know much about the considerations behind splitting the packages > (which happened a long time ago), but merging the packages back into one > seem like a straightforward possible solution (though I doubt someone will > be willing), because in the upstream, they really are just one. The packages > have to ALWAYS be exactly matched anyway and building them separately really > seems like creating problems out of thin air. I disagree. It is split for a good reason. It allows you to install the client and libraries without the much larger server. I think this approach is cleaner than using USE flags. Other distros tend to split it up even more. Fedora further separates the client programs from the libraries, for example. > Another would be to leave some sort of build drop from the -base package and > copy/reuse that for subsequent packages, ie. circumvent the need to call > pg_config in another way. Eg. the config.log or simply a text file with the > variables needed. Since versions need to be matched, there's no worry about > back/forward compatibility between ebuild versions - they never mix anyway. This is not a bad idea but requires a little more upheaval. I guess we should leave this decision to the maintainer. > Either way, I don't care very much how is it fixed, as long as it ultimately > cross-compiles. :) My thoughts exactly. Cross-compiling is rarely pretty and often breaks anyway so I think the odd ugly hack can be excused. I did manage to get it to build. The pthread error was an odd one. During configure, it checks to see whether -pthread works, which it does but it also double checks to see whether any warnings are issued. The presence of -I/usr/include/xml2 causes a -Wpoison-system-directories warning so it ruled the -pthread flag out. xslt-config also causes a similar problem later on in the build by emitting a -L/usr/lib64 flag. I've managed to work around these under my cross-boss system but fixing them properly will probably require the addition of pkg-config checks. I would want to see such changes go upstream.
(In reply to Zdenek Behan from comment #6) > That sounds .... shady. And I'd be very worried about future compatibility. > > One thing to consider is that the build split into -base -server etc. is > generally Gentoo-specific. One thing is packaging the binaries/libs > separately, another is actually building them separately. > > I don't know much about the considerations behind splitting the packages > (which happened a long time ago), but merging the packages back into one > seem like a straightforward possible solution (though I doubt someone will > be willing), because in the upstream, they really are just one. The packages > have to ALWAYS be exactly matched anyway and building them separately really > seems like creating problems out of thin air. > > Another would be to leave some sort of build drop from the -base package and > copy/reuse that for subsequent packages, ie. circumvent the need to call > pg_config in another way. Eg. the config.log or simply a text file with the > variables needed. Since versions need to be matched, there's no worry about > back/forward compatibility between ebuild versions - they never mix anyway. > > > Either way, I don't care very much how is it fixed, as long as it ultimately > cross-compiles. :) I've never liked the split ebuilds. I went along with it because that's where they were at when I picked them up, but had to wait a while before I could move back to a unified ebuild. And I mean really unified. Not the libpq and postgresql packages we had before. https://github.com/titanofold/titanofold-gentoo-x86/tree/master/dev-db/postgresql I have worked on unifying one. It seems to work.
(In reply to Aaron W. Swenson from comment #8) > I've never liked the split ebuilds. I went along with it because that's > where they were at when I picked them up, but had to wait a while before I > could move back to a unified ebuild. And I mean really unified. Not the > libpq and postgresql packages we had before. > > https://github.com/titanofold/titanofold-gentoo-x86/tree/master/dev-db/ > postgresql > > I have worked on unifying one. It seems to work. That really looks much more promising than any voodoo we could try to fix this. And it would work even going forward. Any chance of getting that into the tree?
If that's the way you want to go, it's fine by me.
(In reply to Zdenek Behan from comment #9) > (In reply to Aaron W. Swenson from comment #8) > > I've never liked the split ebuilds. I went along with it because that's > > where they were at when I picked them up, but had to wait a while before I > > could move back to a unified ebuild. And I mean really unified. Not the > > libpq and postgresql packages we had before. > > > > https://github.com/titanofold/titanofold-gentoo-x86/tree/master/dev-db/ > > postgresql > > > > I have worked on unifying one. It seems to work. > > That really looks much more promising than any voodoo we could try to fix > this. And it would work even going forward. Any chance of getting that into > the tree? That's the plan. I'm deciding whether or not to gradually introduce it, or do a mass move. The major advantage is that only a flag needs to be flipped rather than changing the entire PostgreSQL ecosystem. I want to skip the whole virtual package transition.
(In reply to Zdenek Behan from comment #9) > (In reply to Aaron W. Swenson from comment #8) > > I've never liked the split ebuilds. I went along with it because that's > > where they were at when I picked them up, but had to wait a while before I > > could move back to a unified ebuild. And I mean really unified. Not the > > libpq and postgresql packages we had before. > > > > https://github.com/titanofold/titanofold-gentoo-x86/tree/master/dev-db/ > > postgresql > > > > I have worked on unifying one. It seems to work. > > That really looks much more promising than any voodoo we could try to fix > this. And it would work even going forward. Any chance of getting that into > the tree? Okay, so while not in gentoo-x86, you can use Layman to access the overlay. https://github.com/titanofold/titanofold-gentoo-x86 Instructions are in the README.md. I've finished unifying all the current supported PostgreSQL branches. In a different git branch, I'm working on how to best convert dependencies on the split ebuilds in the rest of the tree.
I think I've sniffed out all the packages that have a dependency on PostgreSQL, modified the dependencies, and have committed them to my overlay. Please give it a go, and report any issues with the overlay on GitHub.
dev-db/postgresql (the unified ebuilds) have been committed to the tree, along with virtual package, and dependencies have been updated. This solution is to use the new, unified ebuilds.
Thank you for this!
