Found a problem that gpspacket.so forgot to link against libm.so It was found by adding "-Wl,--no-add-needed and -Wl,--no-undefined" to LDFLAGS x86_64-pc-linux-gnu-gcc -pthread -shared -Wl,-O1 -Wl,-O1 -Wl,--no-add-needed -Wl,--no-undefined -Wl,--as-needed -O2 -pipe -march=athlon64 -Wall -Wcast-align -Wmissing-declarations -Wmissing-prototypes -Wstrict-prototypes -Wpointer-arith -Wreturn-type -D_GNU_SOURCE /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/gpspacket.o /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/packet.o /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/isgps.o /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/rtcm.o /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/strl.o /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/hex.o -L/usr/lib64 -lpython2.6 -o /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/gpspacket.so /var/tmp/portage/sci-geosciences/gpsd-2.37/work/gpsd-2.37/build/rtcm.o: In function `rtcm_repack': rtcm.c:(.text+0x1307): undefined reference to `rint' rtcm.c:(.text+0x1556): undefined reference to `rint' rtcm.c:(.text+0x15a7): undefined reference to `rint' rtcm.c:(.text+0x168d): undefined reference to `rint' rtcm.c:(.text+0x16e4): undefined reference to `rint' Reproducible: Always Steps to Reproduce:
Using append_ldflags -lm links libgps against libm: # ldd -r /usr/lib64/libgps.so linux-vdso.so.1 => (0x00007fff46dfd000) libgcc_s.so.1 => /lib/libgcc_s.so.1 (0x00007f2d3e8fa000) libc.so.6 => /lib/libc.so.6 (0x00007f2d3e5a5000) libm.so.6 => /lib/libm.so.6 (0x00007f2d3e321000) libstdc++.so.6 => /usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/libstdc++.so.6 (0x00007f2d3e016000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f2d3ddfa000) libnsl.so.1 => /lib/libnsl.so.1 (0x00007f2d3dbe1000) /lib64/ld-linux-x86-64.so.2 (0x00007f2d3ed6d000) Are you saying it needs more than that?
Yes, it only links indirectly over another library instead of specifying it directly when it needs it. See my ldflags to get an easy failure case.
You'll have to explain this one more, as it seems rather pathological to me (if you're saying that by adding some obscure LDFLAGS it breaks the package build setup). What's your proposed fix?
Created attachment 176006 [details, diff] Link against libm.so Oh, this one is hard... please let me some time to think about that question.... I really know it. Just give me more time... I really, really know it... Link against libm.so and send the patch to upstream?
Sorry, wrong paste: ldd -r /usr/lib64/python2.5/site-packages/gpspacket.so linux-vdso.so.1 => (0x00007fff6e9fd000) libpython2.5.so.1.0 => /usr/lib/libpython2.5.so.1.0 (0x00007f546640e000) libpthread.so.0 => /lib/libpthread.so.0 (0x00007f54661f2000) libc.so.6 => /lib/libc.so.6 (0x00007f5465e9c000) libdl.so.2 => /lib/libdl.so.2 (0x00007f5465c98000) libutil.so.1 => /lib/libutil.so.1 (0x00007f5465a95000) libm.so.6 => /lib/libm.so.6 (0x00007f5465811000) /lib64/ld-linux-x86-64.so.2 (0x00007f54669b1000) As you can see, the append_ldfags passes -lm to the python build as well, but we'll go ahead and patch setup.py if that'll make you happy...
Needed that for both extensions (in 2.38) but that's pretty much what I came up with too. The upstream setup.py changed, but the current ~arch version is now updated.
