[nanomsg] incorrect configure guess for NN_HAVE_ATOMIC_SOLARIS
- From: Mark Mitchell <mark.mitchell@xxxxxxxxxxxxx>
- To: <nanomsg@xxxxxxxxxxxxx>
- Date: Wed, 4 Dec 2013 17:26:20 -0600
I am trying to cross-compile nanomsg using GCC for a Linux
system running on a MIPS architecture.
I've built 5 or 6 other third-party packages with this
cross-compiler. Very few built cleanly out of the box.
It seems most of the problems I've encountered are due to the use of
autotools.
Here's the story on nanomsg:
nanomsg build fails with::
./doltlibtool --tag=CC --mode=link
/opt/bcm/usr/bin/mips-unknown-linux-uclibc-gcc -std=gnu99 -Os -g -ggdb -g3
-pthread -o nanocat tools/nanocat.o tools/options.o libnanomsg.la
libtool: link: /opt/bcm/usr/bin/mips-unknown-linux-uclibc-gcc -std=gnu99
-Os -g -ggdb -g3 -pthread -o .libs/nanocat tools/nanocat.o tools/options.o
./.libs/libnanomsg.so -pthread
./.libs/libnanomsg.so: undefined reference to `atomic_add_32_nv'
collect2: ld returned 1 exit status
This is because NN_HAVE_ATOMIC_SOLARIS is apparently defined during
the configure stage, resulting in NN_ATOMIC_SOLARIS being defined in
src/utils/atomic.h, resulting in a reference to atomic_add_32_nv in
src/utils/atomic.c.
atomic_add_32_nv is apparently specific to Solaris, and what should have
been defined for a Linux system instead of NN_HAVE_ATOMIC_SOLARIS
is NN_HAVE_GCC_ATOMIC_BUILTINS.
Output from build shows both -DNN_HAVE_GCC_ATOMIC_BUILTINS=1 and
-DNN_HAVE_ATOMIC_SOLARIS=1 :
./doltcompile /opt/bcm/usr/bin/mips-unknown-linux-uclibc-gcc -std=gnu99
-DPACKAGE_NAME=\"nanomsg\" -DPACKAGE_TARNAME=\"nanomsg\"
-DPACKAGE_VERSION=\"0.2-alpha\" -DPACKAGE_STRING=\"nanomsg\ 0.2-alpha\"
-DPACKAGE_BUGREPORT=\"nanomsg@xxxxxxxxxxxxx\"
-DPACKAGE_URL=\"http://nanomsg.org/\"; -DPACKAGE=\"nanomsg\"
-DVERSION=\"0.2-alpha\" -DNN_HAVE_GCC=1 -DNN_HAVE_LINUX=1 -DSTDC_HEADERS=1
-DHAVE_SYS_TYPES_H=1 -DHAVE_SYS_STAT_H=1 -DHAVE_STDLIB_H=1 -DHAVE_STRING_H=1
-DHAVE_MEMORY_H=1 -DHAVE_STRINGS_H=1 -DHAVE_INTTYPES_H=1 -DHAVE_STDINT_H=1
-DHAVE_UNISTD_H=1 -DHAVE_NETINET_IN_H=1 -DHAVE_NETDB_H=1 -DHAVE_ARPA_INET_H=1
-DHAVE_UNISTD_H=1 -DHAVE_SYS_SOCKET_H=1 -DHAVE_SYS_IOCTL_H=1 -DHAVE_PIPE=1
-DNN_HAVE_PIPE=1 -DHAVE_PIPE2=1 -DNN_HAVE_PIPE2=1 -DHAVE_CLOCK_GETTIME=1
-DHAVE_POLL=1 -DNN_HAVE_POLL=1 -DHAVE_EPOLL_CREATE=1 -DNN_USE_EPOLL=1
-DNN_USE_LITERAL_IFADDR=1 -DHAVE_ACCEPT4=1 -DNN_HAVE_ACCEPT4=1
-DNN_HAVE_SOCKETPAIR=1 -DNN_HAVE_SEMAPHORE=1 -DNN_HAVE_GCC_ATOMIC_BUILTINS=1
-DNN_HAVE_ATOMIC_SOLARIS=1 -DNN_USE_PIPE=1 -DHAVE_DLFCN_H=1
-DLT_OBJDIR=\".libs/\" -I. -I/home/m/source/nanomsg_0.2_alpha-ipho
-D_GNU_SOURCE -D_GNU_SOURCE -Os -g -ggdb -g3 -pthread -MT src/utils/atomic.lo
-MD -MP -MF $depbase.Tpo -c -o src/utils/atomic.lo
/home/m/source/nanomsg_0.2_alpha-ipho/src/utils/atomic.c
The order of if/else logic in atomic.h causes NN_HAVE_GCC_ATOMIC_BUILTINS
to be ignored and NN_HAVE_ATOMIC_SOLARIS to be used. This is of course giving
incorrect results for a Linux system.
If you look in the 15,000 line configure script, around line
6062 you will find the tests which try to guess whether to use
NN_HAVE_GCC_ATOMIC_BUILTINS or NN_HAVE_ATOMIC_SOLARIS, by compiling
or linking some generated C code. I'm not an autoconf guru, and it is
unclear why these tests fail to guess correctly, and thus unclear how to fix
them.
Any help from autoconf experts in fixing this would be appreciated.
The arguments passed to configure (invoked not from the source
directory but from a separate build directory):
/home/m/source/nanomsg_0.2_alpha-ipho/configure
--srcdir=/home/m/source/nanomsg_0.2_alpha-ipho --prefix=/usr
--cache-file=/dev/null --disable-silent-rules --host=mips-unknown-linux-uclibc
The information contained in this message may be confidential, privileged or
protected from disclosure. If you have received it by mistake, please let us
know by e-mail reply and delete it from your system; you may not copy,
disseminate or disclose the contents of this message to anyone
Other related posts:
