hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt'
Start of story is here: http://bugs.gentoo.org/show_bug.cgi?id=293208
In short: LIBM variable is wrongly fulfilled by test:
configure:8389: checking for atan
configure:8389: x86_64-pc-linux-gnu-gcc -o conftest -march=nocona -O2 -pipe -Wl,-O1 conftest.c -lbfd -liberty >&5
conftest.c:109: warning: conflicting types for built-in function 'atan'
configure:8389: $? = 0
thus test leads to
LIBM=''
, then that sole LIBM passed to hp2ps and hp2ps fails, as no -lbfd -liberty were passed:
gcc -o hp2ps -O -march=native -O2 -pipe -Wa,--noexecstack -I../../includes
-Wall AreaBelow.o AuxFile.o Axes.o Curves.o Deviation.o Dimensions.o
Error.o HpFile.o Key.o Main.o Marks.o PsFile.o Reorder.o Scale.o Shade.o
TopTwenty.o TraceElement.o Utilities.o
Deviation.o: In function `Deviation':
Deviation.c:(.text+0x42b): undefined reference to `sqrt'
AFAIU, before testing for atan presence in -lm ghc should hide his previously found $LIBS, as LIBM is planned to be used separately.
And separate issue: hp2ps (and other utils/) does not seem to respect external LDFLAGS
some spam on #ghc (nothing new):
21:02:36 < trofi> hi, i seem to have found small bunch of bugs in ghc-6.10.4/ghc-6.12
21:03:32 < trofi> I don't like how LIBM variable is detected. It leads to bugs like
http://bugs.gentoo.org/show_bug.cgi?id=293208
21:04:41 < trofi> first test finds atan in absolutely unrelated libs: configure:17837: /usr/bin/gcc -o conftest -g -O2
conftest.c -lbfd -liberty >&5
21:04:49 < trofi> and decides LIBM=''
21:06:13 < trofi> is it standard autotools practice to grind libraries together?
21:06:36 < trofi> i thought they should be tested separately
21:09:21 < pejo> trofi, so in what library is atan on your OS?
21:10:19 < trofi> libm
21:10:53 < trofi> the problem is autoconf tests not only libm, but libs he found before: -lbfd and -liberty
21:13:04 < trofi> (at a time)
21:13:12 < pejo> What autoconf tests depends on how you've written your tests. If it finds atan in either libiberty or libbdf,
then it doesn't need libm, does it?
21:13:32 < trofi> yes it doesn't
21:13:49 < trofi> but ghc build system does not pass those libraries to build some utils
21:13:55 < trofi> it passes only LIBM
21:14:11 < trofi> which is "obviously" empty
21:14:55 < trofi> it's another bug - when some utils are built there is no respect of user's LDFLAGS variable
Sorry for describing bug in reverse order. Seems like ghc-6.12 is affected too.
Trac metadata
Trac field | Value |
---|---|
Version | 6.10.4 |
Type | Bug |
TypeOfFailure | OtherFailure |
Priority | normal |
Resolution | Unresolved |
Component | Build System |
Test case | |
Differential revisions | |
BlockedBy | |
Related | |
Blocking | |
CC | |
Operating system | |
Architecture |