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 |