Joachim Breitner <m...@joachim-breitner.de> writes: > [Resent, as ghc-dev does not like my other address. Sorry Ben] > > Hi, > > > Am Sonntag, den 30.11.2014, 10:56 -0500 schrieb Ben Gamari: >> > thanks. I tried to build ghc-7.8.4-rc1 on Debian, and it failed on arm*. >> > First, because it picked llvm-3.5. After I tightened the dependencies to >> > use llvm-3.4, it failed with >> > dll-split: internal error: evacuate(static): strange closure >> > type 0 >> > (GHC version 7.8.3.20141119 for arm_unknown_linux) >> >> Indeed this looks like ld.bfd is being used. > > hmm, that’s annoying that --with-ld does not do the right thing. Is > there a bug reported about this? > Not that I know of. It would be good if it did the right thing although I'm afraid that the gold issue described below means that it wouldn't make much difference in practice; I don't think we want to be in the business of building in hacks working around linker quirks into our build system.
>> > I then followed your advice from somewhere else and passed >> > "--with-ld=ld.gold" to ./configure, but with the same effect: >> >> Unfortunately I don't think this will be sufficient. I believe this >> will only set the `LD` variable in the build system, which as far qas I >> know is never used. We always call gcc to do our linking for us; >> gcc will in turn just use whatever `ld` it finds in `PATH`. For this >> reason I have resorted to simply adding a directory containing a symlink >> to `ld.gold` to `PATH`. This is what this script[1] does. > > hmm, I’ll need to port that somehow to how the Debian package is built. > But it seems to be cleaner to use the -B flag to gcc, available at least > on Debian, according to > https://gcc.gnu.org/ml/gcc/2010-10/msg00147.html. > > What would be a reliable way to make the build system pass > -B/usr/bin/ld.gold to gcc? Is > SRC_HC_OPTS += -optc-B/usr/bin/ld.gold > in mk/build.mk a good idea? > Indeed this is much cleaner. I just wanted a way to accomplish this without editing build.mk. >> Unfortunately it's also a bit more subtle than this; it's very likely >> that the ghc you are bootstrapping from contains relocations that aren't >> supported by gold. For this reason you'll likely need to build some of >> the utilities with `ld.bfd` the continue the build with `ld.gold`. The >> above script implements this fairly reliably. > > What would be the symptoms of that problem? > You'll see an error message of the form, /usr/bin/ld.gold: error: /usr/lib/ghc/libHSrts.a(GetTime.o): requires unsupported dynamic reloc R_ARM_THM_MOVW_ABS_NC; recompile with -fPIC I'm tempted to just try implementing this relocation type but sadly these sorts of patches always take longer to get right than I expect. Cheers, - Ben
pgpR7JVVHNiE9.pgp
Description: PGP signature
_______________________________________________ ghc-devs mailing list ghc-devs@haskell.org http://www.haskell.org/mailman/listinfo/ghc-devs