1. 07 Aug, 2009 1 commit
    • Ian Lynagh's avatar
      Add a kludge to fix building shared libs · 74df25b1
      Ian Lynagh authored
      The .dyn_hi files currently depend on the .dyn_hi files of modules that
      they import. But they actually want the .hi files of modules from
      another package.This we make the .dyn_hi files depend on the .hi files
      so we are sure that they exist and are up-to-date.
      74df25b1
  2. 04 Jun, 2009 1 commit
  3. 28 Apr, 2009 1 commit
  4. 26 Apr, 2009 1 commit
  5. 06 Feb, 2009 1 commit
  6. 10 Aug, 2008 1 commit
  7. 28 Aug, 2007 1 commit
  8. 15 Aug, 2007 1 commit
  9. 13 Aug, 2007 1 commit
    • gwright@antiope.com's avatar
      Fix build with external gmp library. · 24311993
      gwright@antiope.com authored
      ghc fails to build if you use an external gmp library. This is because
      ghc requires the header file gmp.h, which used to be provided by the
      internal gmp source code.  The file gmp.h is no longer part of the
      gmp source code, but is generated as part of the build procedure.
      If an external gmp is specified, the internal gmp is not build and the
      gmp.h file never gets generated.
      
      Of course, it was a bad idea anyway to use a header file from a potentially
      different version of the library.
      
      The patch sets HAVE_LIB_GMP if the gmp library is found during configuration
      and conditionalizes including the library header file on it.
      24311993
  10. 05 Jul, 2007 1 commit
  11. 05 Jun, 2007 1 commit
  12. 26 Mar, 2007 2 commits
  13. 17 Oct, 2006 1 commit
  14. 12 Oct, 2006 1 commit
    • Ian Lynagh's avatar
      Partially fix GHCi when unregisterised · 8c254946
      Ian Lynagh authored
      We were constructing info tables designed for TABLES_NEXT_TO_CODE,
      but were building without TABLES_NEXT_TO_CODE.
      
      This patch also fixes a bug when we are unregisterised on amd64 and
      have code with an address above 2^32.
      8c254946
  15. 25 Aug, 2006 1 commit
  16. 07 Apr, 2006 1 commit
    • Simon Marlow's avatar
      Reorganisation of the source tree · 0065d5ab
      Simon Marlow authored
      Most of the other users of the fptools build system have migrated to
      Cabal, and with the move to darcs we can now flatten the source tree
      without losing history, so here goes.
      
      The main change is that the ghc/ subdir is gone, and most of what it
      contained is now at the top level.  The build system now makes no
      pretense at being multi-project, it is just the GHC build system.
      
      No doubt this will break many things, and there will be a period of
      instability while we fix the dependencies.  A straightforward build
      should work, but I haven't yet fixed binary/source distributions.
      Changes to the Building Guide will follow, too.
      0065d5ab
  17. 24 Mar, 2006 1 commit
    • duncan.coutts@worc.ox.ac.uk's avatar
      mkDerivedConstants.c depends on ghcplatform.h · 354cefe7
      duncan.coutts@worc.ox.ac.uk authored
      I think this missing dep is what broke my parallel build
      I used make -j2 with ghc-6.4.2.20060323 and got:
      
      ------------------------------------------------------------------------
      ==fptools== make boot -wr --jobserver-fds=3,11 -j;
      in /var/tmp/portage/ghc-6.4.2_pre20060323/work/ghc-6.4.2.20060323/ghc/includes
      ------------------------------------------------------------------------
      Creating ghcplatform.h...
      Done.
      gcc -O -O2 -march=k8 -pipe -Wa,--noexecstack    -c mkDerivedConstants.c -o mkDerivedConstants.o
      In file included from ghcconfig.h:5,
                       from Stg.h:42,
                       from Rts.h:19,
                       from mkDerivedConstants.c:20:
      ghcplatform.h:1:1: unterminated #ifndef
      Done.
      						    
      With this patch applied I can no longer repoduce this build bug.
      So I think this patch should be applied to the cvs ghc-6-4-branch too.
      354cefe7
  18. 21 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-21 14:02:17 by simonmar] · 03a9ff01
      simonmar authored
      Big re-hash of the threaded/SMP runtime
      
      This is a significant reworking of the threaded and SMP parts of
      the runtime.  There are two overall goals here:
      
        - To push down the scheduler lock, reducing contention and allowing
          more parts of the system to run without locks.  In particular,
          the scheduler does not require a lock any more in the common case.
      
        - To improve affinity, so that running Haskell threads stick to the
          same OS threads as much as possible.
      
      At this point we have the basic structure working, but there are some
      pieces missing.  I believe it's reasonably stable - the important
      parts of the testsuite pass in all the (normal,threaded,SMP) ways.
      
      In more detail:
      
        - Each capability now has a run queue, instead of one global run
          queue.  The Capability and Task APIs have been completely
          rewritten; see Capability.h and Task.h for the details.
      
        - Each capability has its own pool of worker Tasks.  Hence, Haskell
          threads on a Capability's run queue will run on the same worker
          Task(s).  As long as the OS is doing something reasonable, this
          should mean they usually stick to the same CPU.  Another way to
          look at this is that we're assuming each Capability is associated
          with a fixed CPU.
      
        - What used to be StgMainThread is now part of the Task structure.
          Every OS thread in the runtime has an associated Task, and it
          can ask for its current Task at any time with myTask().
      
        - removed RTS_SUPPORTS_THREADS symbol, use THREADED_RTS instead
          (it is now defined for SMP too).
      
        - The RtsAPI has had to change; we must explicitly pass a Capability
          around now.  The previous interface assumed some global state.
          SchedAPI has also changed a lot.
      
        - The OSThreads API now supports thread-local storage, used to
          implement myTask(), although it could be done more efficiently
          using gcc's __thread extension when available.
      
        - I've moved some POSIX-specific stuff into the posix subdirectory,
          moving in the direction of separating out platform-specific
          implementations.
      
        - lots of lock-debugging and assertions in the runtime.  In particular,
          when DEBUG is on, we catch multiple ACQUIRE_LOCK()s, and there is
          also an ASSERT_LOCK_HELD() call.
      
      What's missing so far:
      
        - I have almost certainly broken the Win32 build, will fix soon.
      
        - any kind of thread migration or load balancing.  This is high up
          the agenda, though.
      
        - various performance tweaks to do
      
        - throwTo and forkProcess still do not work in SMP mode
      03a9ff01
  19. 17 Oct, 2005 1 commit
    • simonmar's avatar
      [project @ 2005-10-17 09:36:39 by simonmar] · 97ab9c1b
      simonmar authored
      if TARGETPLATFORM differs from HOSTPLATFORM, don't attempt to build
      DerivedConstants,h, ghcautoconf.h and GHCConstants.h.  If these aren't
      present, emit a message to remind the user to copy them from the
      target system.  Hopefully this should make bootstrapping slightly less
      error prone.
      97ab9c1b
  20. 27 Mar, 2005 1 commit
    • panne's avatar
      [project @ 2005-03-27 13:41:13 by panne] · 03dc2dd3
      panne authored
      * Some preprocessors don't like the C99/C++ '//' comments after a
        directive, so use '/* */' instead. For consistency, a lot of '//' in
        the include files were converted, too.
      
      * UnDOSified libraries/base/cbits/runProcess.c.
      
      * My favourite sport: Killed $Id$s.
      03dc2dd3
  21. 22 Mar, 2005 1 commit
  22. 02 Mar, 2005 1 commit
  23. 21 Feb, 2005 1 commit
  24. 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
  25. 08 Oct, 2004 1 commit
    • ross's avatar
      [project @ 2004-10-08 10:16:14 by ross] · 8af72d7e
      ross authored
      Make the sed command turning '#define PACKAGE_FOO "blah"' into
      '/* #undef PACKAGE_FOO */' more portable, though a tad less precise.
      
      The use of \| deep inside the pattern is a GNU extension (from sed 2.05).
      8af72d7e
  26. 19 Sep, 2004 1 commit
    • panne's avatar
      [project @ 2004-09-19 09:15:03 by panne] · f271c1f8
      panne authored
      Use some sed magic to avoid PACKAGE_FOO clashes introduced by the autoconf
      cleanup yesterday. Another option would have been using a plain "AC_INIT" in
      fptools/configure.ac (and probably the same for fptools/libraries/configure.ac),
      so only "leaf configure.ac"s have package info. Not quite sure what would be the
      nicest way to handle this yet...
      f271c1f8
  27. 13 Aug, 2004 1 commit
  28. 04 Sep, 2003 1 commit
  29. 21 Mar, 2003 1 commit
  30. 02 Mar, 2002 1 commit
    • sof's avatar
      [project @ 2002-03-02 17:49:42 by sof] · bb22180b
      sof authored
      Add the CPP flags used by an unregisterised build
      when compiling the .h generating utilities herein.
      As was, info table size was wrongly computed in
      the unregisterised case.
      bb22180b
  31. 11 Feb, 2002 1 commit
  32. 21 Nov, 2001 1 commit
  33. 19 Oct, 2001 1 commit
  34. 03 Oct, 2001 1 commit
    • simonmar's avatar
      [project @ 2001-10-03 13:57:42 by simonmar] · b4623557
      simonmar authored
      Tidy up ghc/includes/Constants and related things.
      
      Now all the constants that the compiler needs to know, such as header
      size, update frame size, info table size and so on are generated
      automatically into a header file, DeriviedConstants.h, by a small C
      program in the same way as NativeDefs.h.  The C code in the RTS is
      expected to use sizeof() directly (it already does).
      
      Also tidied up the constants in MachDeps.h - all the constants
      representing the sizes of various types are named SIZEOF_<foo>, to
      match the constants defined in config.h.  PrelStorable.lhs now doesn't
      contain any special knowledge about GHC's conventions as regards the
      size of certain types, this is all in MachDeps.h.
      b4623557
  35. 16 Jul, 2001 1 commit
  36. 08 Dec, 2000 1 commit
  37. 07 Aug, 2000 1 commit
  38. 02 Aug, 2000 1 commit
    • rrt's avatar
      [project @ 2000-08-02 14:13:26 by rrt] · 567b2505
      rrt authored
      Many fixes to DLLisation. These were previously covered up because code was
      leaking into the import libraries for DLLs, so the fact that some symbols
      were thought of as local rather than in another DLL wasn't a problem.
      
      The main problems addressed by this commit are:
      
      1. Fixes RTS symbols working properly when DLLised. They didn't before.
      2. Uses NULL instead of stg_error_entry, because DLL entry points can't be
         used as static initialisers.
      3. PrelGHC.hi-boot changed to be in package RTS, and export of PrelNum and
         PrelErr moved to PrelBase, so that references to primops & the like
         are cross-DLL as they should be.
      4. Pass imports around as Modules rather than ModuleNames, so that
         ModuleInitLabels can be checked to see if they're in a DLL or not.
      567b2505
  39. 02 Dec, 1998 1 commit