#25 Does not compile on SL7: -lm flag missing in Makefile

[Dirk Hoffmann]

Phantastic tool. Thanks! Runs like a charm on Scientific Linux (SL6, gcc 4.4.5).

However when trying to compile on SL7 (which should be identical to CentOS 7 or RHEL 7, if you need to reproduce the error) with gcc 4.8.3, it stops at

gcc -g -O2 -o packETH src/main.o src/support.o src/interface.o src/callbacks.o src/function.o src/function_send.o src/loadpacket.o src/savepacket.o -pthread -lgtk-x11-2.0 -lgdk-x11-2.0 -latk-1.0 -lgio-2.0 -lpangoft2-1.0 -lpangocairo-1.0 -lgdk_pixbuf-2.0 -lcairo -lpango-1.0 -lfreetype -lfontconfig -lgobject-2.0 -lgmodule-2.0 -lgthread-2.0 -lrt -lglib-2.0
/usr/bin/ld: src/function.o: undefined reference to symbol 'sin@@GLIBC_2.2.5'
/usr/bin/ld: note: 'sin@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it to the linker command line
/lib64/libm.so.6: could not read symbols: Invalid operation
collect2: error: ld returned 1 exit status
make[1]: *** [packETH] Error 1

When I add -lm in Makefile, it compiles and runs as well.

The point is: Why is it not contained in Makefile (which I generated as usual with ./configure). I checked in configure.ac and though t
AC_CHECK_LIB([m], [pow]) should do the job, but it does not.
Also adding AC_CHECK_LIB([m], [sin]) and rerunning autoreconf did not add -lm to DEP_LIBS in Makefile. But I am not familiar at all with autotools.

It seems that the -lm flag is not needed under SL6.

Maybe I am looking totally into the wrong direction, and some setup is wrong. But both SL6 and SL7 are largely used systems of the RHEL series, which I do not expect to have errors in their default setup.

Any idea how to fix this more automatically?

[Miha Jemec]

Hi Dirk,

thanks for pointing this out. I’m aware of this problem, temporary solution is described in FAQ.

Which version of packETH are you using? I think this was solved in 1.8.1, at least I remember that testing on my platform (Centos 6 and Ubunto 13) conformed this. But could be that there is still a problem on some platforms.

Actually adding it to Makefile is just a temporary solution since running configure script overwrites it every time. I think I added it to Makefile.am and it worked, but I’m also not very familiar with autotools.

Could you please try it and confirm it back to me if it works on 1.8.1?

Regards, Miha

[Dirk Hoffmann]

thanks for pointing this out. I?m aware of this problem, temporary solution is
described in FAQ.

Where?

Which version of packETH are you using?

How can I tell?

$ head -1 README
packETH-1.8 (C) 2003-2014 by Miha Jemec

Actually adding it to Makefile is just a temporary solution since running
configure script overwrites it every time. I think I added it to Makefile.am
and it worked, but I?m also not very familiar with autotools.

So the question would be, why I did not download an updated Makefile.am?

Anyway, as it worked on SL6 without even mentioning -lm on the command line,
I am sure on SL7 it should have come along with the autoconf run by itself.

I rather believe that it is a compiler problem than an OS problem though (gcc
4.4.5 vs. 4.8.3). But that is just for reference.

By the way both compilers do not like a missing -lm in a simple test:

$ cat > sin.c <<EoF

include <math.h>

include <stdlib.h>

include <stdio.h>

main(){
float x = 1.0;
printf("%f\n", sin(x));
exit(0);}
EoF
$ make sin.o
cc -c -o sin.o sin.c
$ make sin
cc sin.o -o sin
sin.o: In function main': sin.c:(.text+0x19): undefined reference tosin'
collect2: ld returned 1 exit status
$ LDLIBS=-lm make sin
cc sin.o -lm -o sin

I tracked the difference down to the cairo library:

$ cc sin.o -lcairo -o sin
runs OK on SL6/gcc4.4.5, but yields
$ cc sin.o -lcairo -o sin
/usr/bin/ld: sin.o: undefined reference to symbol 'sin@@GLIBC_2.2.5'
/usr/bin/ld: note: 'sin@@GLIBC_2.2.5' is defined in DSO /lib64/libm.so.6 so try adding it to the linker command line
/lib64/libm.so.6: could not read symbols: Invalid operation collect2: error: ld returned 1 exit status
with SL7/gcc4.8.3.

Now tell me why! ;-)
Dirk

PS: "ldd" doesn't give me a clue either. Both resolve links to -lm:

SL6> ldd /usr/lib64/libcairo.so
linux-vdso.so.1 => (0x00007ffffa5fe000)
libpixman-1.so.0 => /usr/lib64/libpixman-1.so.0 (0x000000349b400000)
libfreetype.so.6 => /usr/lib64/libfreetype.so.6 (0x0000003498800000)
libfontconfig.so.1 => /usr/lib64/libfontconfig.so.1 (0x0000003498c00000)
libpng12.so.0 => /usr/lib64/libpng12.so.0 (0x0000003499000000)
libXrender.so.1 => /usr/lib64/libXrender.so.1 (0x0000003499400000)
libX11.so.6 => /usr/lib64/libX11.so.6 (0x0000003497400000)
libz.so.1 => /lib64/libz.so.1 (0x0000003495400000)
libm.so.6 => /lib64/libm.so.6 (0x0000003494400000)
libc.so.6 => /lib64/libc.so.6 (0x0000003494000000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x0000003494800000)
/lib64/ld-linux-x86-64.so.2 (0x0000003493c00000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x0000003498000000)
libxcb.so.1 => /usr/lib64/libxcb.so.1 (0x0000003496c00000)
libdl.so.2 => /lib64/libdl.so.2 (0x0000003494c00000)
libXau.so.6 => /usr/lib64/libXau.so.6 (0x0000003497000000)

SL7> ldd /usr/lib64/libcairo.so
linux-vdso.so.1 => (0x00007fff65d3e000)
libpthread.so.0 => /lib64/libpthread.so.0 (0x00007f319c948000)
libpixman-1.so.0 => /lib64/libpixman-1.so.0 (0x00007f319c69a000)
libfontconfig.so.1 => /lib64/libfontconfig.so.1 (0x00007f319c45e000)
libfreetype.so.6 => /lib64/libfreetype.so.6 (0x00007f319c1b8000)
libEGL.so.1 => /lib64/libEGL.so.1 (0x00007f319bf98000)
libdl.so.2 => /lib64/libdl.so.2 (0x00007f319bd94000)
libpng15.so.15 => /lib64/libpng15.so.15 (0x00007f319bb69000)
libxcb-shm.so.0 => /lib64/libxcb-shm.so.0 (0x00007f319b965000)
libxcb-render.so.0 => /lib64/libxcb-render.so.0 (0x00007f319b75b000)
libxcb.so.1 => /lib64/libxcb.so.1 (0x00007f319b53a000)
libXrender.so.1 => /lib64/libXrender.so.1 (0x00007f319b32f000)
libX11.so.6 => /lib64/libX11.so.6 (0x00007f319aff1000)
libXext.so.6 => /lib64/libXext.so.6 (0x00007f319addf000)
libz.so.1 => /lib64/libz.so.1 (0x00007f319abc8000)
libGL.so.1 => /lib64/libGL.so.1 (0x00007f319a95d000)
librt.so.1 => /lib64/librt.so.1 (0x00007f319a755000)
libm.so.6 => /lib64/libm.so.6 (0x00007f319a452000)
libc.so.6 => /lib64/libc.so.6 (0x00007f319a091000)
/lib64/ld-linux-x86-64.so.2 (0x00007f319ce9c000)
libexpat.so.1 => /lib64/libexpat.so.1 (0x00007f3199e67000)
libX11-xcb.so.1 => /lib64/libX11-xcb.so.1 (0x00007f3199c64000)
libxcb-dri2.so.0 => /lib64/libxcb-dri2.so.0 (0x00007f3199a5f000)
libxcb-xfixes.so.0 => /lib64/libxcb-xfixes.so.0 (0x00007f3199858000)
libxcb-shape.so.0 => /lib64/libxcb-shape.so.0 (0x00007f3199653000)
libgbm.so.1 => /lib64/libgbm.so.1 (0x00007f319944c000)
libglapi.so.0 => /lib64/libglapi.so.0 (0x00007f3199222000)
libselinux.so.1 => /lib64/libselinux.so.1 (0x00007f3198ffc000)
libdrm.so.2 => /lib64/libdrm.so.2 (0x00007f3198df0000)
libXau.so.6 => /lib64/libXau.so.6 (0x00007f3198beb000)
libXdamage.so.1 => /lib64/libXdamage.so.1 (0x00007f31989e8000)
libXfixes.so.3 => /lib64/libXfixes.so.3 (0x00007f31987e2000)
libxcb-glx.so.0 => /lib64/libxcb-glx.so.0 (0x00007f31985c7000)
libXxf86vm.so.1 => /lib64/libXxf86vm.so.1 (0x00007f31983c1000)
libpcre.so.1 => /lib64/libpcre.so.1 (0x00007f319815f000)
liblzma.so.5 => /lib64/liblzma.so.5 (0x00007f3197f3a000)

[Miha Jemec]

The "-lm" problem and solution is described under the Installation tab and not Faq, sorry about this: http://packeth.sourceforge.net/packeth/Installation.html

Regarding the version, open packETH -> Help -> About and you will get the dialog with version you are using.