| Commit message (Collapse) | Author | Age | Files | Lines |
|---|
| |
|
|
|
|
|
|
|
| |
With glibc, things like _POSIX_C_SOURCE and _ISOC99_SOURCE are
additive, but on FreeBSD they are mutually exclusive. However, it
turns out we only need to define _POSIX_C_SOURCE and _XOPEN_SOURCE to
get all the C99 stuff we need too, so there's no need for any #ifdefs.
Submitted by: Gabor PALI <pgj@FreeBSD.org>
|
| |
|
|
|
|
|
|
| |
We just about got away with this on x86 which isn't
alignment-sensitive. The result of the memory load is compared
against a few different values, but there is a fallback case that
happened to be the right thing when the pointer was tagged. A good
bug to find, nonetheless.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
With gcc 4.4 we get
Error: can't resolve `.note.GNU-stack' {.note.GNU-stack section} - `.Ltext0' {.text section}
when running gcc with the -g flag. To work around this we unset
CFLAGS when running the test.
|
| |
|
|
|
|
|
|
|
|
| |
It used to make the build work on cygwin, but now it breaks it instead:
config.status: creating include/Makefile
gawk: ./confLqjohp/subs.awk:1: BEGIN {\r
gawk: ./confLqjohp/subs.awk:1: ^ backslash not last character on line
config.status: error: could not create include/Makefile
make[2]: *** [libffi/stamp.ffi.configure-shared] Error 1
make[1]: *** [all] Error 2
|
| |
|
|
|
|
|
|
| |
Fixes a build failure on OS X 10.6. When linking
rts/dist/build/libHSrts-ghc6.13.20100519.dylib
we got
ld: symbol dyld_stub_binding_helper not defined (usually in crt1.o/dylib1.o/bundle1.o)
collect2: ld returned 1 exit status
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Later packages are supposed to shadow earlier ones in the stack,
unless the ordering is overriden with -package-id flags.
Unfortunately an earlier fix for something else had sorted the list of
packages so that it was in lexicographic order by installedPackageId,
and sadly our test (cabal/shadow) didn't pick this up because the
lexicographic ordering happened to work for the test. I've now fixed
the test so it tries both orderings.
|
| |
|
|
| |
We now tell it where to find ld, nm and ar
|
| | |
|
| |
|
|
| |
This will hopefully fix #2889.
|
| |
|
|
|
|
|
| |
1. allow multiple threads to call startTimer()/stopTimer() pairs
2. disable the timer around fork() in forkProcess()
A corresponding change to the process package is required.
|
| | |
|
| | |
|
| | |
|
| |
|
|
| |
Spotted by Marco Túlio Gontijo e Silva
|
| | |
|
| |
|
|
|
| |
We still need the workaround for when compiling HEAD with 6.12.2
|
| |
|
|
| |
The libtool creates "libffi.dylib" and "libffi.5.dylib" but not "libffi.5.0.9.dylib". Having it in libffi_DYNAMIC_LIBS causes an infinite makefile loop.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
|
| |
I had incorrectly "optimised" checkHiBootIface so that it forgot
to update the "knot-tied" type environment.
This patch fixes the HEAD
|
| |
|
|
|
|
|
|
|
|
|
| |
As well as fixing #4019, I rejigged the way that Ord instances are
generated, which should make them faster in general. See the
Note [Generating Ord instances].
I tried to measure the performance difference from this change, but
the #4019 fix only removes one conditional branch per iteration, and
I couldn't measure a consistent improvement. But still, tihs is
better than before.
|
| |
|
|
|
|
|
|
| |
We eta-expand things with INLINE pragmas;
see Note [Eta-expanding INLINE things].
But I eta-expanded it the wrong amount when the function
was overloaded. Ooops.
|
| | |
|
| |
|
|
|
|
|
| |
When using the bootstrapping compiler, we now explicitly constrain
the version of boot packages (Cabal, extensible-exceptions, etc) to the
in-tree version, so that the build system is less fragile should the
user have a newer version installed for the bootstrapping compiler.
|
| |
|
|
|
|
| |
This fixes a problem when building with GHC 6.12 on Windows, where
dependencies on stage 0 (bootstrapping compiler) packages have absolute
paths c:/ghc/..., and make gets confused by the colon.
|
| | |
|
| | |
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
|
| |
It now understand the ghc-stage[123] names we use in-tree, and it won't
go looking for any old ghc-pkg if it can't find the one that matches
ghc.
|
| | |
|
| | |
|
| |
|
|
|
| |
Broken by "Split part of the Task struct into a separate struct
InCall".
|
| |
|
|
|
|
|
|
|
|
| |
Default currently NO.
Validate passed with GhcDynamic=YES on x86/Linux here.
The compiler is currently slower on x86 when linked -dynamic,
because the GC inner loop has been adversely affected by -fPIC, I'm
looking into how to fix it.
|
| |
|
|
|
| |
When GHCi is linked dynamically, we still want to be able to load
non-dynamic object files.
|
| | |
|
| | |
|
| | |
|
| |
|
|
|
| |
We were failing to externalise the wrapper id for a function
that had one.
|
| | |
|
| | |
|
