AIX: compilation errors
Closed this issue · 13 comments
see related issues over at the syslog-ng guys:
syslog-ng/syslog-ng#2646
syslog-ng/syslog-ng#2649
/bin/sh ../libtool --tag=CC --mode=compile /usr/bin/gcc -maix32 -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../src/include -I../src/include -D_AIX -Wall -MT iv_fd_epoll.lo -MD -MP -MF .deps/iv_fd_epoll.Tpo -c -o iv_fd_epoll.lo iv_fd_epoll.c
libtool: compile: /usr/bin/gcc -maix32 -DHAVE_CONFIG_H -I. -I.. -D_GNU_SOURCE -I../src/include -I../src/include -D_AIX -Wall -MT iv_fd_epoll.lo -MD -MP -MF .deps/iv_fd_epoll.Tpo -c iv_fd_epoll.c -fPIC -DPIC -o .libs/iv_fd_epoll.o
iv_fd_epoll.c:25:23: fatal error: sys/epoll.h: No such file or directory
#include <sys/epoll.h>
^
compilation terminated.
gmake[2]: *** [Makefile:541: iv_fd_epoll.lo] Error 1
gmake[2]: Leaving directory '/home/packagebuilder/test/ivykis-0.42.3/src'
gmake[1]: *** [Makefile:397: all-recursive] Error 1
gmake[1]: Leaving directory '/home/packagebuilder/test/ivykis-0.42.3'
gmake: *** [Makefile:327: all] Error 2
To get iv_fd_epoll.c pulled into the build, you would need this part of src/Makefile.am to trigger:
if HAVE_EPOLL
SRC += iv_fd_epoll.c
endif
And for HAVE_EPOLL to be set, you would need this bit of configure.ac to trigger:
AM_CONDITIONAL([HAVE_EPOLL], [test x$ac_cv_func_epoll_create = xyes])
Where ac_cv_fun_epoll_create is set by this bit of the same file:
AC_CHECK_FUNCS([epoll_create])
How did you get an AIX machine with a definition of epoll_create? :)
Can you share a full configure + make build log of an unmodified ivykis source tree (say, https://github.com/buytenh/ivykis/archive/v0.42.3.tar.gz ) so that we can find out why your AIX machine appears to be defining Linux-specific APIs?
oh trust me, there is a bunch of idiocy inside aix, and i've seen it all g
i attached the requested logs...
build.log
config.log
Haha. :)
Thank you for the logs! From your config.log it's pretty obvious what is happening:
configure:13454: checking for epoll_create
configure:13454: result: yes
configure:13465: checking for epoll_create1
configure:13465: result: yes
configure:13476: checking for eventfd
configure:13476: result: yes
configure:13487: checking for gettid
configure:13487: result: yes
configure:13498: checking for inotify_init
configure:13498: result: yes
configure:13509: checking for kqueue
configure:13509: result: yes
configure:13520: checking for lwp_gettid
configure:13520: result: yes
configure:13531: checking for pipe2
configure:13531: result: yes
configure:13542: checking for port_create
configure:13542: result: yes
configure:13553: checking for ppoll
configure:13553: result: yes
configure:13564: checking for thr_self
configure:13564: result: yes
configure:13575: checking for timerfd_create
configure:13575: result: yes
It appears that AC_CHECK_FUNCS() is broken on your platform, and always succeeds. In other words, this seems to be an issue with autoconf (and not with ivykis).
Some googling finds this similar issue:
https://lists.gnu.org/archive/html/autoconf/2002-11/msg00067.html
Either way, could you please take this up with the autoconf people?
Thanks again for the report!
hmm..the autoconf package comes from the ibm rpm distribution, will bug the guys over there with this issue. i am sure this will get "interesting" :-)
Does it help if you run autoconf by hand after unpacking the ivykis tarball? (Your config.log says that it was "created by ivykis configure 0.42.3", so it might help to run your distro's autoconf on top of that, and then do the ./configure dance again etc.)
running autconf was of no help, even autoreconf --install was useless. will wake up the ibm monkeys and report back .
Without digging much, just arriving at a conclusion is very bad. Some words here are uncalled for.
AC_CHECK_FUNCS routine depends on C linkage to test whether the functionality is there or not. Basically the conftest compilation will fail with undefined symbol if the function doesn't exist.
But this ldflag option "-berok" ignores this failure and makes compilation successful.
I see this is getting passed in LDFLAGS which is bad. If this is passed by the user, i would say this is a improper compilation method by user.
This would seem to be an issue with libtool, then, rather than with autoconf -- lines 5508 - 5559 in libtool.m4 here in particular:
http://git.savannah.gnu.org/cgit/libtool.git/tree/m4/libtool.m4
Does AIX come with a version of libtool that fixes this?
No.
That part comes into account only when libtool comes in picture. We are discussing a plain conftest.c compilation where libtool won't interfere.
ac_link='$CC -o conftest$ac_exeext $CFLAGS $CPPFLAGS $LDFLAGS conftest.$ac_ext $LIBS
This is how it is done by the configure.
Wrongly exporting the linker options created the problem here.
It's a clear mistake on the part of the user to have used the wrong compilation option.
Right, @flynn1973 's config log contains this, which explains the issue, then:
configure:16539: running /bin/sh ./configure --disable-option-checking '--prefix=/home/packagebuilder/test/inst' '--exec-prefix=/home/packagebuilder/test/inst' 'CC=/usr/bin/gcc -maix32' 'CFLAGS=-D_AIX' 'LDFLAGS=-L/opt/freeware/lib -L/opt/freeware/lib64 -Wl,-blibpath:/opt/freeware/lib:/opt/freeware/lib64:/usr/lib:/lib -Wl,-bnoquiet -Wl,-berok' --cache-file=/dev/null --srcdir=.
@flynn1973 Does it work if you build without -Wl,-berok in LDFLAGS? What is passing in this option in your environment, and why?
I'm inclined to close this as not being an ivykis bug, but let's see if we can get it working first.
Thanks to everyone so far for the help on this one.
the berok option was a leftover from the debugging nightmare on the syslog-ng code.
without it the build goes throug successfully. however, this is not the case with syslog-ng.