Library configure scripts should not clobber CPPFLAGS nor LDFLAGS
libraries/base/configure
currently clobbers CPPFLAGS
and LDFLAGS
when --with-iconv-includes
and --with-iconv-libraries
are given, but really it shouldn't.
I will soon submit a patch for this.
Here's what I stumbled upon (TL;DR):
This is somewhat related to #2933. I have libiconv installed in /usr/pkg
, which is a non-standard path that ld.so
normally doesn't search libraries for. So I built GHC with CONF_GCC_LINKER_OPTS_STAGE{0,1,2}
set to -Wl,-rpath,/usr/pkg/lib
so that GHC links executables with RPATH
pointing to /usr/pkg/lib
.
The build went fine until it started using ghc-stage2
and haddock
: they were causing segfaults in evacuate()
with a probability of about 70%, which suggested a heap corruption occuring somewhere. I tried rebuilding RTS with -O0 -g
, changed various parameters for GC, etc. Nothing changed.
Then I suddenly realized that libraries/base/configure
was the root cause of the problem. Those configure
scripts are executed with LDFLAGS
being set to the value of CONF_GCC_LINKER_OPTS_STAGE2
, which is -Wl,-rpath,/usr/pkg/lib
in my case, but libraries/base/configure
overwrites it to -L/usr/pkg/lib
when --with-iconv-libraries=/usr/pkg/lib
is given. On the other hand, FP_SEARCH_LIBS_PROTO(iconv)
appends -liconv
to $LIBS
so it will be linked to any conftest executables that follow, including one which will be generated by AC_CHECK_SIZEOF()
.
The problem is that if libraries listed in $LIBS
are in a non-standard path while rpath flags are missing (due to LDFLAGS
being clobbered in this case), conftest executables cannot run even if they can be linked. And if anything goes wrong during AC_CHECK_SIZEOF(T)
, it considers sizeof(T)
as 0 unless T
is known to be an existing type:
...
checking for library containing iconv... -liconv
checking for library containing locale_charset... none required
checking size of struct MD5Context... 0
...
This means SIZEOF_STRUCT_MD5CONTEXT
gets defined to 0, GHC.Fingerprint.fingerprintData
allocates 0 bytes on the heap, MD5Init
/Update
/Final
corrupts the heap and then Bad Things will happen.
I have found the problem on NetBSD/amd64 but I'm sure the same thing happens on every ELF platform.
Trac metadata
Trac field | Value |
---|---|
Version | 7.11 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Build System |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |