ghc fails to build in a Gentoo prefix on an openSUSE 12.1 host. An $ emerge ghc gives the attached output. Reproducible: Always
Created attachment 308527 [details] build.log
Created attachment 308529 [details] emerge --info
Created attachment 308771 [details] emerge --info
The ghc-6.12.3-r2 build also fails repeatedly on a standard Gentoo install (Gentoo 4.5.3-r2, gcc version 4.5.3). I tried both 'emerge ghc' and 'emerge dev-lang/wxhaskell'. Both fail at exactly the same spot with exactly the same error (the latter after installing quite a bit of other stuff). I am not sure how to add this information to an existing bug report, however I am going to add the various traces & log data as requested on the error message. Thanks!
Created attachment 308773 [details] build log
Created attachment 308775 [details] emerge pqv
The following instructions start off OK: http://www.haskell.org/haskellwiki/Gentoo/HaskellPlatform Then produce the following error: * ERROR: dev-haskell/cgi-3001.1.7.1 failed (compile phase): * setup build failed * * Call stack: * ebuild.sh, line 85: Called src_compile * environment, line 2525: Called haskell-cabal_src_compile * environment, line 1932: Called cabal_src_compile * environment, line 491: Called cabal-build * environment, line 332: Called die * The specific snippet of code: * ./setup "$@" || die "setup build failed" I will post logs momentarily!
Created attachment 308797 [details] emerge haskill-platform error: emerge --info
Created attachment 308799 [details] emerge haskill-platform error: emerge --pqv
Created attachment 308801 [details] emerge haskill-platform error: build.log
We appreciate your enthusiasm but you are making it EXTREMELY confusing by posting logs for BOTH Gentoo Prefix and Gentoo Linux...
(In reply to comment #11) > We appreciate your enthusiasm but you are making it EXTREMELY confusing by > posting logs for BOTH Gentoo Prefix and Gentoo Linux... Oh no, and build.logs for DIFFERENT packages... that doesn't help anything.
My apologies & thank you for your quick response -- I am attempting to install ghc (only, as part of another install). The Gentoo instructions for installing ghc recommend using the haskill-platform instructions to install ghc (along with all of the correct supporting platforms) instead of installing ghc directly -- see the link in my earlier comment for details. So these are all problems related to installing ghc-6.12.30-r2 on a current Gentoo platform. I understood the Gentoo bug reporting instructions to read that I should add onto existing bug reports for the same problem instead of starting a new bug report. But it seems these are not actually the same bug?? In any event, my apologies!
Comment on attachment 308527 [details] build.log I can reproduce this "path relocation failed" error on my amd64-linux system: * ERROR: dev-lang/ghc-6.12.3-r1 failed (prepare phase): * path relocation failed for '/home/raid2/maier/gentoo-prefix.NOBACKUP/var/tmp/portage/dev-lang/ghc-6.12.3-r1/work/usr/lib/ghc-6.12.3/package.conf.d/*' *
(In reply to comment #5) > Created attachment 308773 [details] > build log Your build failure [...] /bin/sh: inplace/bin/mkdirhier: Permission denied [...] very much resembles the parallel build issue reported and discussed in bug 326347 See comment 19 for a workaround.
Thank you very much! Setting MAKEOPTS=-j2 (down from -j25) ran very slowly, but did not produce any errors during the installation. Several weeks ago I installed ghc on a quad-core x86 platform with no problems (-j5), so this was very likely the same problem as reported in 326347.
> ../../prefix/linux/amd64/make.defaults:LIBDIR_amd64="lib" Any reason prefix does it? ghc uses bootsrapped binary on amd64. We could add hacks to ebuild to handle lib64->lib, but LIBDIR just seems to be incorrect. Both amd64 and and amd64-nomultilib use LIBDIR_amd64=lib64. $ fgrep -R LIBDIR_amd64 . ./features/64bit-native/make.defaults:LIBDIR_amd64="lib64" ./features/multilib/make.defaults:LIBDIR_amd64="lib64" ./features/multilib/make.defaults:LIBDIR_amd64_fbsd="lib64" ./prefix/linux/amd64/make.defaults:LIBDIR_amd64="lib" ./prefix/ChangeLog: LIBDIR_amd64 is def needed, otherwise stuff gets installed to usr//blah, ^^ heh, looks more like a bug in profiles of lack of 64native. ./prefix/ChangeLog: instead of usr/$LIBDIR_amd64/blah ./prefix/ChangeLog: setting LIBDIR_amd64 to null 'fixes' things, not sure why 'eclass/multilib.eclass' also defaults to lib64.
(In reply to comment #17) > > ../../prefix/linux/amd64/make.defaults:LIBDIR_amd64="lib" > > Any reason prefix does it? Just following the FHS (and it makes sense to have native 64bit (only) libs in lib on a non-multilib system). (Hint: If you research other distros, you will find that Gentoo Linux is unique) Anyway, it is too invasive to change LIBDIR to get one package (ghc) to work.
> Anyway, it is too invasive to change LIBDIR to get one package (ghc) to work. sure, we'll workaround it for prefix.
oh crap, you guys merged Prefix support in gx86?
*** Bug 427026 has been marked as a duplicate of this bug. ***
As I understand the problem the precompiled ghc binary (which we are using for bootstrapping) may have a different libdir than the prefix (in my case on amd64-linux it is lib64 and lib, respectively). Therefore, parts of the build process that interact with the precompiled binary and use get_libdir fail. We need a way to know the what the precompiled binary thinks its libdir is. ghc has a --print-libdir option which gives us that information. I created a new function in the ebuild, get_binary_libdir that runs the binary ghc with the --print-libdir option. Unfortunatly, this does not solve the problem as the binary ghc fails to run with: ghc: error while loading shared libraries: libgmp.so.10: cannot open shared object file: No such file or directory libgmp is install in the prefix, but I suspect ghc is not finding it because it is looking in a different libdir. Changing the get_binary_libdir function to just report a hardcoded lib64 (in my case) appears to work (I'm still waiting on the build to complete, but it has made it past the earlier src_prepare problem). Possible solutions in what I think is order of desirability: 0) fix get_binary_libdir to report the correct libdir by testing if lib, lib64, and lib32 exist in sucession and report the first one that exists. 1) do a full ghc bootstrap starting with ghc compiled to C as source material. 2) make special precompiled ghc binaries for prefix that use the smae libdir as the profiles.
Created attachment 320618 [details, diff] add get_binary_libdir function and uses instead of get_libdir in the two required places
Created attachment 320642 [details, diff] use correct pathc for binary libdir ghc built and functions with when I hardcoded amd64 for the binary libdir, so I implemented option 0 from comment 22. It works on my amd64-linux system, and I hope that is generic enough to work on platforms that have lib or lib32 as the binary libdir. It will not work on platforms that use none of lib, lib64, or lib32 as the binary libdir, but I am not aware of such a platform. Testing a feedback is appreciated.
Created attachment 320644 [details, diff] use correct path for binary libdir Fixes the PaX marking to use get_binary_libdir instead of being commented out.
I just wanted to correct something that I said in comment 22: I claimed that ghc --print-libdir failed because the libdir it was looking in (in my case lib64) was not the same as the libdir where libgmp was installed (lib). This is not the case since ghc works for bootstrapping where its view on what the libdir is hasn't changed. I think that I was unable to run ghc at that point because it did not know about prefix since relocate_path had not been run on it yet. (Unfortunatly, relocate_path needs to know the binary libdir). Sorry for any confusion.
I don't know what the problem actually is with compiling glc on amd64 platforms, however the suggestion (comment #15 below) to set MAKEOPTS=-j2 (down from -j25) ran very slowly, but did not produce any errors during the installation & the installed glc is working just fine. It seems perhaps there is a synchronization issue in the make/build subsystem on amd64 when the number of cores becomes too large (see the comments on the other discussion forum referenced)??
(In reply to comment #26) > I just wanted to correct something that I said in comment 22: I claimed that > ghc --print-libdir failed because the libdir it was looking in (in my case > lib64) was not the same as the libdir where libgmp was installed (lib). This > is not the case since ghc works for bootstrapping where its view on what the > libdir is hasn't changed. I think that I was unable to run ghc at that point > because it did not know about prefix since relocate_path had not been run on > it yet. (Unfortunatly, relocate_path needs to know the binary libdir). > > Sorry for any confusion. I lost you here, but the original comment/analysis made sense to me. Thanks
> I lost you here, but the original comment/analysis made sense to me. Thanks The distiction that I was trying to make doesn't affect my patch at all, so no harm, no foul. ☺
I'd focus on 7.4/7.6 instead
