summaryrefslogtreecommitdiff
path: root/rules/build-package-way.mk
Commit message (Collapse)AuthorAgeFilesLines
* Update Wiki URLs to point to GitLabTakenobu Tani2019-03-251-2/+2
| | | | | | | | | | | | | | | | | | | | | | | This moves all URL references to Trac Wiki to their corresponding GitLab counterparts. This substitution is classified as follows: 1. Automated substitution using sed with Ben's mapping rule [1] Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy... New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy... 2. Manual substitution for URLs containing `#` index Old: ghc.haskell.org/trac/ghc/wiki/XxxYyy...#Zzz New: gitlab.haskell.org/ghc/ghc/wikis/xxx-yyy...#zzz 3. Manual substitution for strings starting with `Commentary` Old: Commentary/XxxYyy... New: commentary/xxx-yyy... See also !539 [1]: https://gitlab.haskell.org/bgamari/gitlab-migration/blob/master/wiki-mapping.json
* Rip out object splittingBen Gamari2019-03-051-5/+0
| | | | | | | | | | | | | | | The splitter is an evil Perl script that processes assembler code. Its job can be done better by the linker's --gc-sections flag. GHC passes this flag to the linker whenever -split-sections is passed on the command line. This is based on @DemiMarie's D2768. Fixes Trac #11315 Fixes Trac #9832 Fixes Trac #8964 Fixes Trac #8685 Fixes Trac #8629
* Fix bindist for ghci libraryZejun Wu2019-01-061-4/+4
| | | | | | | | | | | | | | | | | | | | Summary: https://phabricator.haskell.org/D5169 built libghci for both vanilla way and profiling way. We need to include both in the bindist list so they will be installed. Test Plan: ``` $ grep '^BuildFlavour' mk/build.mk BuildFlavour=perf $ make test_bindist $ grep HSghc-prim bindist-list.uniq ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.o ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3.a ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3-ghc8.7.20190101.so ghc-8.7.20190101/libraries/ghc-prim/dist-install/build/libHSghc-prim-0.5.3_p.a ```
* Merge sections in profiling .a to .p_o and use it whenever it existsZejun Wu2018-12-171-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: We do this for vanilla way already. Let's also merge sections for profiling way and use it instead of the .a library when it exists. Test Plan: ``` $ inplace/bin/ghc-stage2 --interactive -prof -fexternal-interpreter GHCi, version 8.7.20180921: http://www.haskell.org/ghc/ :? for help Prelude> pid <- System.Posix.Process.getProcessID Prelude> maps <- readFile $ "/proc/" ++ show pid ++ "/maps" Prelude> pid 3807346 Prelude> putStrLn $ unlines $ take 20 $ lines maps 00400000-02103000 r-xp 00000000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02104000-02106000 r--p 01d03000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02106000-02417000 rw-p 01d05000 00:1a 199277344 /data/users/watashi/ghc/inplace/lib/bin/ghc-iserv-prof 02417000-0280a000 rw-p 00000000 00:00 0 [heap] 40098000-400b0000 rwxp 000d2000 00:1a 199276023 /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o 400b7000-400d8000 rwxp 00000000 00:00 0 401d1000-401d2000 rwxp 000e9000 00:1a 199276023 /data/users/watashi/ghc/libraries/bytestring/dist-install/build/HSbytestring-0.10.8.2.p_o 40415000-40419000 rwxp 0000b000 00:1a 199275165 /data/users/watashi/ghc/libraries/deepseq/dist-install/build/HSdeepseq-1.4.4.0.p_o 404f8000-40526000 rwxp 000af000 00:1a 199274234 /data/users/watashi/ghc/libraries/ghc-prim/dist-install/build/HSghc-prim-0.5.3.p_o ``` Reviewers: simonmar, bgamari, austin, hvr Reviewed By: simonmar Subscribers: rwbarton, carter Differential Revision: https://phabricator.haskell.org/D5169
* Don't use ld.gold when building libraries for GHCiSimon Marlow2018-02-211-2/+5
| | | | | | | | | | | | | | | | | | | Summary: ld.gold is buggy when using -r and a linker script. See upstream bug https://sourceware.org/bugzilla/show_bug.cgi?id=22266 This has been causing various brokenness for the GHC runtime linker, where we load these broken object files. Test Plan: Test program from #14675 Reviewers: bgamari, RyanGlScott, alpmestan, hvr, erikd Subscribers: rwbarton, thomie, erikd, carter GHC Trac Issues: #14328, #14675, #14291 Differential Revision: https://phabricator.haskell.org/D4431
* Add gen-dll as replacement for dll-splitTamar Christina2017-08-291-14/+17
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: This tool can be used to generate dll's for any list of object files given to it. It will then repartition them automatically to fit within a dll and generates as many dll's as needed to do this. Cyclic dependencies between these generated dlls are handle automatically so there is no need to tell it how to partition. It is also a lot more general than `dll-split` as it is able to split any package not just `libGHC`. It also uses a trick using GNU style import libraries to hide the splitting from the rest of the pipeline. Which means come linking time you don't need to know which dll contains what symbol or how many split dlls were created. The import libraries are by default created with libtool. However since libtool is BFD based it is very slow. So if present and detected by configure the `genlib` tool from the msys2 project is used. This makes a difference of about ~45 minutes when compiling. To install `genlib` run `pacman -Sy mingw-w64-$(uname -m)-tools-git`. More detailed explaination of the process can be found here https://ghc.haskell.org/trac/ghc/wiki/WindowsDynamicLinking Test Plan: ./validate Reviewers: austin, hvr, bgamari, erikd, simonmar Reviewed By: bgamari Subscribers: snowleopard, rwbarton, thomie, erikd, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3883
* Remove dll-split.Tamar Christina2017-08-291-40/+3
| | | | | | | | | | | | | | | | | | | | This patch removes dll-split from the code base, the reason is dll-split no longer makes any sense. It was designed to split a dll in two, but we now already have many more symbols than would fit inside two dlls. So we need a third one. This means there's no point in having to maintain this list as it'll never work anyway and the solution isn't scalable. Test Plan: ./validate Reviewers: austin, bgamari Reviewed By: bgamari Subscribers: rwbarton, thomie, #ghc_windows_task_force GHC Trac Issues: #5987 Differential Revision: https://phabricator.haskell.org/D3882
* Implement split-sections support for windows.Tamar Christina2017-07-081-1/+7
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: Initial implementation of split-section on Windows. This also corrects section namings and uses the platform convention of `$` instead of `.` to separate sections. Implementation is based on @awson's patches to binutils. Binutils requires some extra help when compiling the libraries for GHCi usage. We drop the `-T` and use implicit scripts to amend the linker scripts instead of replacing it. Because of these very large GHCi object files, we need big-obj support, which will be added by another patch. Test Plan: ./validate Reviewers: awson, austin, bgamari Subscribers: dfeuer, rwbarton, thomie, snowleopard, #ghc_windows_task_force GHC Trac Issues: #12913 Differential Revision: https://phabricator.haskell.org/D3383
* ghc: tweak cross-compilation to mingw32Sergei Trofimovich2017-04-231-5/+5
| | | | | | | | | | | | | | | The build failure when cross-compiling from linux to windows looks like: HC [stage 1] ghc/stage2/build/tmp/ghc-stage2.exe Call hs_init_ghc() from your main() function to set these options. /usr/libexec/gcc/i686-w64-mingw32/ld: cannot find -lHSghc-8.3-0 Similar to commit 745032dd02da511067c2939259ed212852187e0f ("rts: tweak cross-compilation to mingw32") decision to split stage2 should be done based based on TargetOS, not HostOS. Signed-off-by: Sergei Trofimovich <slyfox@gentoo.org>
* Always build GHCi libsSimon Marlow2017-03-151-4/+0
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | Since the introduction of -split-sections, using GHCi with the RTS linker is really slow: ``` $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter) GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. real 0m3.793s ``` (when we use `-fexternal-interpreter` it uses the RTS linker by default, you can make it use the system linker by adding `-dynamic`) Building the GHCi libs doesn't take much time or space in the GHC build, but makes things much quicker for people using the RTS linker: ``` $ time (echo :quit | ./inplace/bin/ghc-stage2 --interactive -fexternal-interpreter) GHCi, version 8.1.20170304: http://www.haskell.org/ghc/ :? for help Prelude> Leaving GHCi. real 0m0.285s ``` So I propose that we build and ship them unconditionally. Test Plan: validate, perf tests above Reviewers: bgamari, austin, niteria, erikd, Phyx Reviewed By: bgamari Subscribers: rwbarton, thomie, snowleopard Differential Revision: https://phabricator.haskell.org/D3298
* fix OpenBSD linkage (wxneeded)Sergei Trofimovich2016-12-171-1/+1
| | | | | | | | | | | | | | | | | | | | There is two types of options passed directly to 'ld' (and not to 'gcc' driver): - CONF_LD_LINKER_OPTS_STAGE$4 - EXTRA_LD_OPTS This changedoes two things: - split 'EXTRA_LD_OPTS' into two variables: - EXTRA_LD_OPTS (accepts 'gcc' wrapper options) - EXTRA_LD_LINKER_OPTS (accepts raw 'ld' options) - wraps all LD_LINKER options as '-Wl,' when passed to 'gcc' driver. Fixes https://phabricator.haskell.org/D2776 Signed-off-by: Sergei Trofimovich <siarheit@google.com>
* Fix Windows builds after D1242Tamar Christina2015-11-211-1/+5
| | | | | | | | | | | | | | | | | | | | | | | Summary: Only use the merge_sections.ld linker script if SplitSections is enabled. I thought I had a way to make the linker script actually work on Windows and produce object files instead of image files (by using the "INSERT AFTER" linker script command to get the default script's output format setting), but that fix caused ghci to crash with an illegal instruction on startup. Gave up and made a simpler fix of just disabling this for normal builds, as it's only really relevant with SplitSections enabled anyway. Reviewers: austin, thomie, bgamari Reviewed By: austin, thomie Subscribers: Phyx, thomie Differential Revision: https://phabricator.haskell.org/D1505 GHC Trac Issues: #8405
* Implement function-sections for Haskell code, #8405Simon Brenner2015-11-121-2/+4
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This adds a flag -split-sections that does similar things to -split-objs, but using sections in single object files instead of relying on the Satanic Splitter and other abominations. This is very similar to the GCC flags -ffunction-sections and -fdata-sections. The --gc-sections linker flag, which allows unused sections to actually be removed, is added to all link commands (if the linker supports it) so that space savings from having base compiled with sections can be realized. Supported both in LLVM and the native code-gen, in theory for all architectures, but really tested on x86 only. In the GHC build, a new SplitSections variable enables -split-sections for relevant parts of the build. Test Plan: validate with both settings of SplitSections Reviewers: dterei, Phyx, austin, simonmar, thomie, bgamari Reviewed By: simonmar, thomie, bgamari Subscribers: hsyl20, erikd, kgardas, thomie Differential Revision: https://phabricator.haskell.org/D1242 GHC Trac Issues: #8405
* Revert "Build system: don't add ALL_HC_OPTS when linking"Ben Gamari2015-10-291-2/+2
| | | | | | | This reverts commit 9fc2d777f53110040f48ab27643a16888fa377f5. This appears to cause interface file issues during rebuilds. Punting back to @thomie for further investigation.
* Build system: don't add ALL_HC_OPTS when linkingThomas Miedema2015-10-281-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | | | Summary: The current scheme in rules/distdir-way-opts.mk is something like this: GHC_LD_OPTS = MOST_HC_OPTS + ALL_LD_OPTS MOST_DIR_HC_OPTS = MOST_HC_OPTS + -odir,-hidir,-stubdir ALL_HC_OPTS = MOST_DIR_HC_OPTS + -hisuf,-osuf,-hcsuf,-split-objs,-dynamic-too Notice that both ALL_HC_OPTS and GHC_LD_OPTS include MOST_HC_OPTS, and currently both got added when linking. Adding MOST_HC_OPTS twice results in overly long and hard to decipher command lines (and build logs). This commit fixes that. Afaik, -odir,-hidir,-stubdir,-hisuf,-osuf,-hcsuf,-spit-objs,-dynamic-too are all not needed when linking, so this change should be safe to make. GHC_LD_OPTS is for linking, ALL_HC_OPTS is for compiling. ALL_HC_OPTS was added to the linking commands in 37a6a52facd1c3999ce4472c50b0030568be1e04, to make sure -no-user-package-conf would be in the options list. It still is after this change. Reviewers: austin, bgamari Differential Revision: https://phabricator.haskell.org/D1379
* Build system: comments only [skip ci]Thomas Miedema2015-10-271-9/+10
|
* Build system: fix `make -j1` (#10973)Thomas Miedema2015-10-171-0/+4
| | | | | | | | | | | | | | | | | | | | There are multiple hacks all over the build system to account for the fact that the ghc package uses different build subdirectories (stage1/stage2) than the other packages (dist/dist-install). One such hack filtered on 'ghc%', with the intention of filtering the ghc package only. After renaming bin-package-db to ghc-boot (d2f9972a35ce05ceb8a78893e433ef1df06f73ef, Phab:D1313, #10796), ghc-boot also got caught in the hack, which broke the build when running without parallelism. This patch replaces the before mentioned hack by a different one, such that filtering on 'ghc%' is no longer necessary. See Note [inconsistent distdirs]. Reviewed by: austin Differential Revision: https://phabricator.haskell.org/D1333
* Rename PACKAGE_KEY and LIB_NAME in build system.Edward Z. Yang2015-10-141-7/+7
| | | | Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu>
* Make $1 in $1_$2_$3_FOO actually be directory.Edward Z. Yang2015-06-231-4/+4
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: Previously, we used $1_$2_PACKAGE_KEY to parametrize $1. But the documentation says that $1 should be the directory... and we're now putting the libraries in $1_$2_LIB_NAME. So use /that/. This is just alpha-renaming, so as long as we're consistent, there's no material difference.) I also fixed a bug of a package ID calculation which I missed first time around, which was tickled by this change. BTW, this means DEP_KEYS and TRANSITIVE_DEP_KEYS are unused, so remove them from ghc-cabal. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1010
* Rename $1_$2_$3_LIB_NAME to LIB_FILE.Edward Z. Yang2015-06-221-2/+2
| | | | | | | | | | | | | | | | | | | | | | | | | Summary: When we introduced user-friendly library names (e.g. unix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d instead of unix_G4Yo1pNtYrk8nCq1cx8P9d) we added a new variable to be written out by ghc-cabal, $1_$2_LIB_NAME. What I didn't realize at the time was that this conflicts with an existing variable in the build system, $1_$2_$3_LIB_NAME, which (confusingly) refers to something like 'libHSunix-2.7.1.0-G4Yo1pNtYrk8nCq1cx8P9d.so'. This is pretty confusing (despite never conflicting), so I renamed this variable to LIB_FILE for enhanced greppability. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: austin Subscribers: thomie, bgamari Differential Revision: https://phabricator.haskell.org/D1002
* Update Cabal submodule to latest 1.22 snapshotEdward Z. Yang2015-03-111-3/+3
| | | | | | | | | | | | | | | This changes the library file name format NOTE: This patch originally updated to Cabal HEAD, but was reduced to update to Cabal 1.22 HEAD by hvr as this is needed in order to update the filepath submodule to version 1.4.0, and subsequently to be cherry-picked into the ghc-7.10 branch Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Reviewed By: austin Differential Revision: https://phabricator.haskell.org/D707
* Package keys (for linking/type equality) separated from package IDs.Edward Z. Yang2014-08-051-6/+8
| | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | This patch set makes us no longer assume that a package key is a human readable string, leaving Cabal free to "do whatever it wants" to allocate keys; we'll look up the PackageId in the database to display to the user. This also means we have a new level of qualifier decisions to make at the package level, and rewriting some Safe Haskell error reporting code to DTRT. Additionally, we adjust the build system to use a new ghc-cabal output Make variable PACKAGE_KEY to determine library names and other things, rather than concatenating PACKAGE/VERSION as before. Adds a new `-this-package-key` flag to subsume the old, erroneously named `-package-name` flag, and `-package-key` to select packages by package key. RFC: The md5 hashes are pretty tough on the eye, as far as the file system is concerned :( ToDo: safePkg01 test had its output updated, but the fix is not really right: the rest of the dependencies are truncated due to the fact the we're only grepping a single line, but ghc-pkg is wrapping its output. ToDo: In a later commit, update all submodules to stop using -package-name and use -this-package-key. For now, we don't do it to avoid submodule explosion. Signed-off-by: Edward Z. Yang <ezyang@cs.stanford.edu> Test Plan: validate Reviewers: simonpj, simonmar, hvr, austin Subscribers: simonmar, relrod, carter Differential Revision: https://phabricator.haskell.org/D80
* Fix inplace dynamic linking on OS X (#8266)Christiaan Baaj2014-01-281-1/+0
| | | | Signed-off-by: Austin Seipp <austin@well-typed.com>
* Globally replace "hackage.haskell.org" with "ghc.haskell.org"Simon Marlow2013-10-011-2/+2
|
* Fix the dynmaic library paths in the libs, as well as in the programsIan Lynagh2013-06-221-0/+1
| | | | Part of #7833
* Some build system refactoringIan Lynagh2013-04-201-2/+2
|
* Add a check that the Windows DLL split is OK; fixes #7780Ian Lynagh2013-04-071-0/+11
|
* Build system fix: really print the number of symbols in DLLsIan Lynagh2013-04-061-1/+1
|
* When making a DLL, print the number of symbols that are in itIan Lynagh2013-04-061-0/+1
|
* By default, use the dynamic way for programs in the GHC treeIan Lynagh2013-03-151-1/+1
| | | | | In particular, this means that GHCi will use DLLs, rather than loading object files itself.
* Finish adding support for 2 DLLs in the ghc package; fixes #5987Ian Lynagh2013-03-131-3/+17
|
* Fix building the GHC package DLL on WindowsIan Lynagh2013-03-111-8/+33
| | | | | | We now put a handful of modules in a separate DLL. For now the list is hand-written, but we could automate it in the future.
* Rename hs-suffix-rules to hs-suffix-way-rulesIan Lynagh2013-02-211-1/+1
|
* Finish removing BootingFromHcIan Lynagh2013-02-171-4/+0
|
* Small build system refactoringIan Lynagh2013-01-111-2/+0
| | | | hs-suffix-rules now calls hs-suffix-rules-srcdir, saving some duplication
* Remove some dependenciesIan Lynagh2012-11-181-11/+0
| | | | | | I don't think we need these, and they haven't been doing anything useful for dynamic-by-default builds anyway as they hardcode the 'v' way.
* Give dynamic libraries, as well as programs, RPATHsIan Lynagh2012-11-081-2/+2
| | | | Based on a patch from markwright in #3072.
* Get dynamic-by-default mostly working on OS XIan Lynagh2012-10-141-1/+2
|
* Double a couple of $s for consistencyIan Lynagh2012-10-141-2/+2
|
* Don't set dynlib install names when buildingIan Lynagh2012-10-141-1/+0
| | | | | | | | When building things to run in the build tree, we want the install name to be the location in the build tree. Bindists may be installed somewhere other than the configured install location, so we weren't even necessarily setting it to the right value.
* Fix test for GHCi lib buildingIan Lynagh2012-10-131-1/+3
|
* Fix typoIan Lynagh2012-10-131-1/+1
|
* Don't build the HS*.o files when DYNAMIC_BY_DEFAULTIan Lynagh2012-10-121-0/+2
| | | | | We don't use them (we use the .so/.dll instead), so no point generating them.
* Fix a dependency bug in the build systemSimon Marlow2012-10-081-2/+6
| | | | | | | I've been meaning to track this one down for a long time. Occasionally a build will fail with an error about a .so library being truncated; the reason was that we weren't tracking the dependencies of the GHC stage2 .so library correctly.
* Add missing flag for respecting EXTRA_LIBDIRGabor Pali2012-08-081-1/+1
|
* Link the extra-libraries when making a .so for a package (#7062)Simon Marlow2012-07-111-0/+1
| | | | | I don't think I completely understand what's going on here, but this does seem to fix it, and morally it seems like the right thing.
* On Windows, detect if DLLs have too many symbols; trac #5987Ian Lynagh2012-06-291-0/+3
| | | | | The test isn't very pretty; it involves trawling through the objdump -p output. I couldn't find an easier way, unfortuantely.
* Merge remote-tracking branch 'origin/pretty-build'Paolo Capriotti2012-06-081-4/+4
|\
| * A build-system tweak for more readable build output.Iavor S. Diatchki2012-04-271-4/+4
| | | | | | | | | | | | | | | | | | | | | | This change reduces the (default) verbosity of the build system. This makes it easier to spot warnings in the output and, also, it makes it easier to estimate how far along are we in the build process by just glancing at the output. To get the traditional fully verbose output, set V=1, like this: make V=1
* | Enable and fix building dynlibs on Win64Ian Lynagh2012-05-051-1/+1
|/
View Lorry Controller Status