deriveConstants fails on OpenBSD

On OpenBSD 5.5 compilation of current HEAD fails with:

inplace/bin/deriveConstants --gen-header -o includes/dist-derivedconstants/header/DerivedConstants.h --tmpdir includes/dist-derivedconstants/header/ --gcc-program "/usr/bin/gcc" --gcc-flag -fno-stack-protector --gcc-flag -Iincludes --gcc-flag -Iincludes/dist --gcc-flag -Iincludes/dist-derivedconstants/header --gcc-flag -Iincludes/dist-ghcconstants/header --gcc-flag -Irts --gcc-flag -fcommon --nm-program "/usr/bin/nm"
nm: unknown option -- P
usage: nm [-aCegnoprsuw] [file ...]
deriveConstants: readProcess: /usr/bin/nm "-P" "includes/dist-derivedconstants/header/tmp.o" (exit 1): failed
includes/ghc.mk:167: recipe for target 'includes/dist-derivedconstants/header/DerivedConstants.h' failed
gmake[1]: *** [includes/dist-derivedconstants/header/DerivedConstants.h] Error 1
Makefile:71: recipe for target 'all' failed
gmake: *** [all] Error 2

This is due to OpenBSD's nm not supporting the -P option.

Perhaps it can be fixed by using 'objdump --syms' instead of 'nm -P' (see attached OpenBSD-only patch).

Trac metadata

Trac field	Value
Version	7.9
Type	Bug
TypeOfFailure	OtherFailure
Priority	normal
Resolution	Unresolved
Component	Build System
Test case
Differential revisions
BlockedBy
Related
Blocking
CC
Operating system
Architecture

changed weight to 5

added Tbug Trac import labels

Attached file 0001-Hack-to-replace-nm-P-with-objdump-syms.patch (download).

Hi Roland, I'm afraid replacing nm with objdump is too invasive change. Few months ago various Solaris users including myself were working on extending deriveConstants to work with non-GNU nm and usage of nm -P is what's working on linux, freebsd, windows and solaris. I'm not sure about others but for example objdump is completely missing on Solaris so I would rather prefer to stick to what we do have now in nm functionality. Let me ask, isn't there some other OpenBSD's nm option which may be used to get that working? IMHO not using -P for OpenBSD and/or using some other option is still less invasive change than changing to objdump completely for all other platforms. Thanks for you care about OpenBSD! Karel

Trac metadata

Trac field	Value
CC	→ kgardas

Removing the -P option (and adapting the pattern matching) in DeriveConstants.hs yields the following error:

"inplace/bin/ghc-stage1" -static  -H32m -O -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header -Iincludes/dist-ghcconstants/header -Irts -Irts/dist/build -DCOMPILING_RTS -this-package-key rts -dcmm-lint      -i -irts -irts/dist/build -irts/dist/build/autogen -Irts/dist/build -Irts/dist/build/autogen           -O2    -c rts/HeapStackCheck.cmm -o rts/dist/build/HeapStackCheck.o

rts/HeapStackCheck.cmm:97:18: parse error on input `['

Apparently this is due to a wrong value being derived for REP_bdescr_link:

$ grep '#define REP_bdescr_link' ./includes/dist-derivedconstants/header/DerivedConstants.h
#define REP_bdescr_link b0

1. ..which in turn comes from nm's output:

$ nm ./includes/dist-derivedconstants/header/tmp.o | grep REP_bdescr_link
00000001 C derivedConstantREP_bdescr_link

On the other hand, objdump outputs 9 instead of 1:

$ objdump -t ./includes/dist-derivedconstants/header/tmp.o | grep REP_bdescr_link
0000000000000009       O *COM*  0000000000000001 derivedConstantREP_bdescr_link

With this value (9), REP_bdescr_link is derived as 'b64' instead of 'b0' and thus HeapStackCheck.cmm compiles. No matter what options are passed to OpenBSD's nm, it won't output '9' for derivedconstantREP_bdescr_link.

Does this have to be handled differently on different systems or is there another way?

Yes, someone (maybe you roland?) reported the same problem on #ghc a couple months ago. I agree there doesn't seem to be any way to get the relevant information out of OpenBSD's nm.

GHC contains three different reimplementations of various parts of autoconf's functionality (DeriveConstants, mkGmpDerivedConstants, hsc2hs). I'm increasingly tempted to tear out all of them and replace them with a pile of autoconf. But, I'm not going to get around to it any time soon.

In the short term, we could detect in GHC's configure whether nm -P has (one of) the expected output(s) on a test object file, and if not, try objdump instead; then put whichever one worked into a new autoconf variable and use that as the --nm-program argument to DeriveConstants, and teach it to parse the objdump format too.

Trac metadata

Trac field	Value
Differential revisions	→ D332

The above patch (Phab:D332) switches from nm to objdump if System.Info.os == "openbsd". /usr/bin/objdump is part of the OpenBSD base system, so should always be there.

mentioned in commit 2cc20650

closed

Trac metadata

Trac field	Value
Resolution	Unresolved → ResolvedFixed

The new Hadrian build system has been merged. Relabeling the tickets concerning the legacy make build system to prevent confusion.

Trac metadata

Trac field	Value
Component	Build System → Build System (make)

added ghc build failure label

added Pnormal label