- Add flag to control the 'missed extra shared lib' warning
Fri, Oct 19
Tue, Oct 16
- Improve Note.
- Improve wording.
Fix a bug in Note.
- Amend comments and add Note.
Mon, Oct 15
Mon, Oct 8
Sun, Oct 7
Sep 22 2018
May 11 2017
Not quite so, updated binutils allow us to build 64-bit GHC (which is currently impossible because of template-haskell package being miscompiled).
May 9 2017
The patch is accepted and applied to mainline binutils.
Now we should amend template-haskell.cabal with something like
if os(windows) && arch(x86_64) ghc-options: -opta-Wa,-mbig-obj -optl-Wl,--oformat -optl-Wl,pe-bigobj-x86-64
May 8 2017
Well, I've solved the problem, but this requires a patch to ld to enable pe-bigobj-x86-64 output for ln -r. I'll make a binutils ticket with the patch.
I've looked at the big-obj+prof problem and found that assembler is called with correct options but an extra phase is triggered, where ld -r is called to merge some auxiliary object files into the target object file.
May 7 2017
I tried to build latest GHC with my corrections to this patch and I've found that things don't work because of some other, completely unrelated bug somewhere in GHC driver(?).
I think the problem is in non-merged string literals sections.
May 3 2017
And this also reminds me of another problem which I mentioned earlier too.
I don't quite understand the purpose of the last -Wa,-mbig-obj addition.
May 2 2017
Fair enough, initially, I added -mbig-obj to every invocation of gcc from the driver. Which means
any object files coming out of GHC will be in the big-obj format. Perhaps this isn't needed.
Btw, I use GHC built with --split-sections and all my packages are built with --split-sections, and I use mbig-obj on a couple of packages (at least haskell-src-exts and GHC's template-haskell require this).
Yes, you said this before, and I don't see how. merging sections has no meaning as it doesn't change the object format. If I pass mbig-obj to the assembler, regardless of
the sections are merged or not the resulting object file uses the big-obj format. So I don't quite understand what you mean with "correct linker".
Unless you're saying linker scripts can also be used to change object formats.
Prelinked object files for GHCi are produced by ld linker, not an assembler.
But I think this use-case can happen pretty rarely, since when we create a library with GHC, we can *also* create a prelinked object file for GHCi, which should *not* have this problem.
With the correct linker used, prelinked GHCi object files *should* have all "sub"-sections merged into their "parent" sections, and we don't need anything from this.
Mar 27 2017
old and new schemes are meant regarding your patches to GHC. Perhaps, it would be better to name them "gcc-elf-like" and "visualc-like".
If you have only 5 section remained then you, perhaps, used the same linker script both for executables and GHCi prelinked object files which is wrong. You should use different scripts for them -- those with .x extension for executables and .xr for prelinked object files (I refer to the scripts I've posted on trac).
Nope, big-obj has nothing to do with the size of GHCi object files. The problem is that bintuils is still broken here, since native section merging is implemented only for "normal executables", but not for linked "without relocations" prelinked object files used by GHCi.
Jan 5 2017
Your second premise is wrong. Many have short path generation switched off. Me is an example.
Dec 14 2015
The culprit is that -T replaces builtin script completely. When I merged i386pep.xr (this is a builtin for ld -r on windows, one can find it in /mingw64/x86_64-w64-mingw32/lib/ldscripts directory under msys2 distribution or by running ld -r --verbose) with merge_sections.ld (see here:) all went OK, and now a COFF object file with merged sections is generated.
Oct 24 2015
To cure things one should add
This breaks Windows 64-bit (didn't try 32-bit) build immediately.
Aug 21 2015
In the context of example patch that conversion was perfectly safe because we put filepaths only into the response files.
GNU tools expect response files containing forward slashes in paths. Thus the corresponding conversion should be added (as is made in example patch, see normslash function there).
Aug 5 2015
COMDAT support (for which I reused existing weak symbols support) was absolutely necessary for gcc > 4.8. At least gcc 4.9.x didn't work without it. I didn't check gcc 5+ though.
Jan 20 2015
Could we hope TNTC refactoring using stock LLVM mechanism would automatically solve Trac #8974?
Oct 27 2014
I propose slightly different patchset for rts/Linker.c here: https://ghc.haskell.org/trac/ghc/ticket/9218#comment:12.