This project is mirrored from https://gitlab.haskell.org/ghc/ghc.git. Pull mirroring failed .
Repository mirroring has been paused due to too many failed attempts, and can be resumed by a project maintainer.
Last successful update .
  1. 28 Jan, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-01-28 12:55:17 by simonmar] · 153b9cb9
      simonmar authored
      Rationalise the BUILD,HOST,TARGET defines.
      
      Recall that:
      
        - build is the platform we're building on
        - host is the platform we're running on
        - target is the platform we're generating code for
      
      The change is that now we take these definitions as applying from the
      point of view of the particular source code being built, rather than
      the point of view of the whole build tree.
      
      For example, in RTS and library code, we were previously testing the
      TARGET platform.  But under the new rule, the platform on which this
      code is going to run is the HOST platform.  TARGET only makes sense in
      the compiler sources.
      
      In practical terms, this means that the values of BUILD, HOST & TARGET
      may vary depending on which part of the build tree we are in.
      
      Actual changes:
      
       - new file: includes/ghcplatform.h contains platform defines for
         the RTS and library code.
      
       - new file: includes/ghcautoconf.h contains the autoconf settings
         only (HAVE_BLAH).  This is so that we can get hold of these
         settings independently of the platform defines when necessary
         (eg. in GHC).
      
       - ghcconfig.h now #includes both ghcplatform.h and ghcautoconf.h.
      
       - MachRegs.h, which is included into both the compiler and the RTS,
         now has to cope with the fact that it might need to test either
         _TARGET_ or _HOST_ depending on the context.
      
       - the compiler's Makefile now generates
           stage{1,2,3}/ghc_boot_platform.h
         which contains platform defines for the compiler.  These differ
         depending on the stage, of course: in stage2, the HOST is the
         TARGET of stage1.  This was wrong before.
      
       - The compiler doesn't get platform info from Config.hs any more.
         Previously it did (sometimes), but unless we want to generate
         a new Config.hs for each stage we can't do this.
      
       - GHC now helpfully defines *_{BUILD,HOST}_{OS,ARCH} automatically
         in CPP'd Haskell source.
      
       - ghcplatform.h defines *_TARGET_* for backwards compatibility
         (ghcplatform.h is included by ghcconfig.h, which is included by
         config.h, so code which still #includes config.h will get the TARGET
         settings as before).
      
       - The Users's Guide is updated to mention *_HOST_* rather than
         *_TARGET_*.
      
       - coding-style.html in the commentary now contains a section on
         platform defines.  There are further doc updates to come.
      
      Thanks to Wolfgang Thaller for pointing me in the right direction.
      153b9cb9
  2. 27 Jan, 2005 22 commits
  3. 26 Jan, 2005 10 commits
  4. 24 Jan, 2005 1 commit
  5. 23 Jan, 2005 6 commits
    • wolfgang's avatar
      [project @ 2005-01-23 20:34:17 by wolfgang] · 1856c4c7
      wolfgang authored
      Distinguish between rodata and relrodata (relocatable read-only data) in the
      mangler.
      By default, use $T_HDR_rodata if $T_HDR_relrodata is not defined for a
      particular platform.
      1856c4c7
    • wolfgang's avatar
      [project @ 2005-01-23 18:50:40 by wolfgang] · e171a977
      wolfgang authored
      Make the NCG distinguish between the read-only data section and the
      "relocatable read-only data" section.
      Read-only data is supposed to be _really_ read-only, whereas "relrodata"
      can have relocations, but should not be modified by the program at runtime.
      
      For Linux, put relrodata into ".data" by default, as the dynamic linker
      tends to do evil things to avoid relocating things in read-only sections.
      e171a977
    • wolfgang's avatar
      [project @ 2005-01-23 18:18:05 by wolfgang] · 3463d1d3
      wolfgang authored
      Darwin / Mac OS X:
      
      For builds with dynamic libraries, fix up dynamic library paths
      ("install names") for binaries. Otherwise, a dynamically-linked stage2 ghc
      would contain the path names of the build directories.
      3463d1d3
    • panne's avatar
      [project @ 2005-01-23 17:05:31 by panne] · fa8246c7
      panne authored
      In the installed package.conf, all includeDirs were empty, so no GHC/package
      headers were found. This commit fixes that (in a hopefully correct way).
      fa8246c7
    • krasimir's avatar
      [project @ 2005-01-23 09:41:01 by krasimir] · 220f0ae7
      krasimir authored
      Use withProgName. Without it getProgName from the executed script will return
      "<interactive>"
      220f0ae7
    • wolfgang's avatar
      [project @ 2005-01-23 06:10:15 by wolfgang] · 6f985ae8
      wolfgang authored
      Add support for the dead code stripping feature of recent Apple linkers.
      If your code is compiled using the NCG, you can now specify
      -optl-W,-dead_strip on the GHC command line when linking.
      It will have basically the same effect as using split-objs to build the
      libraries.
      
      Advantages over split-objs:
          * No evil perl script involved
          * Requires no special handling when building libraries
      
      Disadvantages:
          * The current version of Apple's linker is slow when given the
            -dead_strip flag. _REALLY_ slow.
          * Mac OS X only.
      
      This works by making the NCG emit the .subsections_via_symbols directive.
      Additionally, we have to add an extra label at the top of every info table,
      and make sure that the entry code references it (otherwise the info table
      will be considered part of the preceding entry code).
      The mangler just removes the .subsections_via_symbols directive.
      6f985ae8