NetBSD 9.x have libcurses with a newer major version than the
bootstrap kit is linked against. For now, work around this with
compat80. (This could also be dealt with by creating versioned
bootstrap kits, but that's more involved, and NetBSD 9.x is pre-
release software, so best to leave this off for now.) Thanks to
Greg Troxel for the compat80 hint.
These flags are only used for creating static GHCi libraries
(HS*.o). Setting them to ${LDFLAGS} does more harm than good because
our ${LDFLAGS} contains -Wl,* flags. It's true that
../../mk/wrapper/cmd-sink-ld transforms them but those flags will also
be baked into the compiler (see ${WRKSRC}/compiler/ghc.mk) so they
cause problems when used outside the buildlink.
In Haskell FFI, "ccall" is actually an interface to C ABI rather than
C API. That is, GHC generates direct references to the symbol even if
it's actually defined as a cpp macro or something like that, because
GHC knows nothing about those macros in foreign headers.
I will later send these patches to the upstream.
Refactored bootstrap.mk with no semantic changes in this commit. I
will soon upload some of bootkits derived from wip/ghc to LOCAL_PORTS
but only for safe ones. Here's a note about safety:
* NetBSD/amd64, FreeBSD/i386, Darwin/ppc [SAFE]: These kits were built
on my secured private machines under my exclusive control. I'm
planning to upload them.
* Linux/amd64 [UNSAFE]: I built my kit for this one on a machine
shared with my co-workers with root access. I won't upload it.
* NetBSD/i386 [UNSAFE]: I built my kit for this one on an Amazon EC2
instance (although it's private). I won't upload it either.
For other developers, please do not upload any bootkits derived from
unsafe ones mentioned above, because they have some degree of
possibility of being compromised. And please keep in mind that
machines shared with someone or on a cloud hosting service should be
avoided for building bootkits.
We don't want our bootkits to have a run-time dependency on libgcc. In
fact GHC's implementation of Haskell exception handling does not
depend on libgcc's facilities so it is attractive to do the same for
"normal" build... but we can't. This is because Haskell programs may
call C functions via FFI, and those C functions may call C++ functions
in turn, possibly in a different shared library.
But on some platforms, gcc automagically inserts a dependency on a
shared libgcc when -lpthread is given, which is seemingly unavoidable.
The problem only occurs when $(WhatGccIsCalled) is an absolute path to
the "real" gcc (e.g. "/usr/bin/gcc"), which happens if we run
${WRKSRC}/configure with an option something like
"--with-gcc=/usr/bin/gcc". As long as we use "--with-gcc" with a
command name (i.e. ${CC}, not ${CCPATH}), everything works fine
without any problems.
This is because dtrace(1) executes cpp in a rather weird way: it calls
execvp("/usr/bin/gcc", argv) with argv set to {"gcc", "-E", "-xc",
...}, not {"/usr/bin/gcc", "-E", "-xc", ...}.
When GCC is called that way, it needs to find platform-specific
subprograms by walking through ${PATH}. And if it sees an executable
named "gcc" which in fact isn't actually gcc, it gets confused and
dies with an error:
% cat dtrace-emu.c
#include <unistd.h>
#include <stdio.h>
int main() {
char *argv[] = {"gcc", "-E", NULL};
execvp("/usr/bin/gcc", argv);
return 0;
}
% gcc dtrace-emu.c -o /tmp/gcc
% /tmp/gcc
powerpc-apple-darwin9-gcc-4.0.1: no input files
% PATH=/tmp/gcc /tmp/gcc
gcc: installation problem, cannot exec '/tmp/powerpc-apple-darwin9-gcc-4.0.1':
No such file or directory
And even if the problem should really be addressed, it should be done
in the wrapper framework because dtrace(1) is actually a part of
compiler toolchain.
