Build Bug: -lm should come after passing ../common/libor.a to linker

The following commit:

    commit e56747f9cf
    Author: Nick Mathewson <nickm@torproject.org>
    Date:   Tue Dec 15 14:32:55 2009 -0500

        Refactor a bit so that it is safe to include math.h, and mostly not needed.

introduced this line:

    tor_resolve_LDADD = -lm ../common/libor.a @TOR_LIB_WS32@

which caused the build to fail, because only ../common/libor.a
(via the embedded ../common/util.o via ../common/util.c)
referenced libm's `lround' and `log' symbols, so that the
linker (GNU ld) didn't bother to import those symbols before
reading ../common/libor.a, thus leaving those symbols undefined.

The solution was to swap the order, producing the line:

    tor_resolve_LDADD = ../common/libor.a -lm @TOR_LIB_WS32@

Signed-off-by: Michael Witten <mfwitten@gmail.com>
This commit is contained in:
Michael Witten 2010-01-16 21:13:31 +00:00 committed by Nick Mathewson
parent c32e8c292e
commit a5e83769b7

View File

@ -3,7 +3,7 @@ noinst_PROGRAMS = tor-checkkey
tor_resolve_SOURCES = tor-resolve.c tor_resolve_SOURCES = tor-resolve.c
tor_resolve_LDFLAGS = @TOR_LDFLAGS_libevent@ tor_resolve_LDFLAGS = @TOR_LDFLAGS_libevent@
tor_resolve_LDADD = -lm ../common/libor.a @TOR_LIB_WS32@ tor_resolve_LDADD = ../common/libor.a -lm @TOR_LIB_WS32@
tor_gencert_SOURCES = tor-gencert.c tor_gencert_SOURCES = tor-gencert.c
tor_gencert_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@ \ tor_gencert_LDFLAGS = @TOR_LDFLAGS_zlib@ @TOR_LDFLAGS_openssl@ \