hp2ps: Deviation.c:(.text+0x42b): undefined reference to `sqrt'

[slyfox]

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.

[asuffield]

Why on earth is ghc linking libiberty anyway? That can't be right.

(Why does gentoo have a libiberty installed? That is not right)

All of this bug report is completely misleading. This has got nothing to do with libbfd or libiberty, neither of which defines atan. The correct diagnostic line was this one:

conftest.c:109: warning: conflicting types for built-in function 'atan'

Somebody added a builtin atan function to gcc. Hence, you no longer need to link libm in order to use atan.

The test in configure.ac needs changing to check for sqrt. That's all.

[slyfox]

Sigh, i tried so hard.

Replying to asuffield:

All of this bug report is completely misleading. This has got nothing to do with libbfd or libiberty, neither of which defines atan. The correct diagnostic line was this one: {{{ conftest.c:109: warning: conflicting types for built-in function 'atan' }}} Somebody added a builtin atan function to gcc. Hence, you no longer need to link libm in order to use atan. The test in configure.ac needs changing to check for sqrt. That's all.

Nope, autoconf's atan intentionally has nonbuiltin prototype, different from gcc's to test _linkage_. No matter what builting gcc has - it will not link w/o libm, and it does not link on my system (with the same warning), so your point is incorrect. Builtin does not affect process of libm needness resolution. Look at my system:

configure:18619: gcc -o conftest -g -O2   conftest.c -lbfd -liberty  >&5
conftest.c:108: warning: conflicting types for built-in function 'atan'
/tmp/ccSFmqh0.o: In function `main':
/tmp/z/ghc-6.10.4/conftest.c:119: undefined reference to `atan'
collect2: ld returned 1 exit status
configure:18625: $? = 1

The second - sqrt will be found in libbfd as well, as original bug reporter has libm in depends on libbfd (don't ask me why, being silly it's absolutely legal).

[slyfox]

BTW, sqrt has builtin primitive on that gcc too.

[asuffield]

Ah, now it makes sense. Easy fix then: move the libm test above the libbfd test.

[slyfox]

libm-fix.dpatch - fixes LIBM detection

[simonmar]

See also #3724

[simonmar]

Pushed:

Fri Dec  4 21:40:12 GMT 2009  Sergei Trofimovich <slyfox@inbox.ru>
  * configure.ac: fix libm checks (Trac #3730)
  
  libbfd pulled libm as dependency and broke LIBM= detection.
  
  Patch moves libm in library tests as early as possible.
  Thanks to asuffield for suggesting such a simple fix.
  Thanks to Roie Kerstein and Renato Gallo for finding
  and tracking down the issue.

[igloo]

Merged