Closed mathiasxx closed 2 years ago
Thats wierd. Works fine for me.
Based on the output you've provided, it seems like all the c->0 compilations work fine (indicating the headers define prototypes for all of the missing functions), but they can't be located during the final link. That suggests to me that you have object files without any symbols in them.
It would be odd, but you noted that you installed all the requisite -dev packages on your system, but didn't mention anything about the library packages themselves. Does ubuntu have a dependency issue in which the underlying library package isn't auto installed as a depedency? I would start by trying to run: apt-get install libnl-3
to see if you're missing the actual libraries.
I'll poke around, here's a tidbit:
➜ dropwatch git:(master) ✗ dpkg -L libnl-3-200
/.
/etc
/etc/libnl-3
/etc/libnl-3/classid
/etc/libnl-3/pktloc
/lib
/lib/x86_64-linux-gnu
/lib/x86_64-linux-gnu/libnl-3.so.200.26.0
/usr
/usr/share
/usr/share/doc
/usr/share/doc/libnl-3-200
/usr/share/doc/libnl-3-200/README.Debian
/usr/share/doc/libnl-3-200/changelog.Debian.gz
/usr/share/doc/libnl-3-200/copyright
/lib/x86_64-linux-gnu/libnl-3.so.200
ok, thats a good start, you at least have the libraries available. Try these commands: ls -l /lib/x86_64-linux-gnu/libnl-3.so.200.26.0 objdump -t /lib/x86_64-linux-gnu/libnl-3.so.200.26.0 | grep nlmsg_free
The first command should just tell us that the library is actually there, and not a symlink to some other non-existant file (suggesting that you need another package to resolve the dependency)
The second command should produce some output like this (assuming the first command shows that we have a real file): [nhorman@hmsvengance linux]$ objdump -t /usr/lib64/libnl-3.so.200 | grep nlmsg_free 000000000000ec52 l .text 0000000000000000 .hidden .annobin_nlmsg_free.start 000000000000edd0 l .text 0000000000000000 .hidden .annobin_nlmsg_free.end 000000000000ec60 g F .text 0000000000000170 nlmsg_free
My expectation is that the objdump output will show some output that amounts to something like "no symbols", which suggests ubuntu has done something to mess up the building of the libnl-3 library, preventing it from linking.
Ah ha. yes, I get "no symbols" when running objdump.
Though the so file is there, all 138072 bytes of it.
Thanks for your help. I'll keep poking around.
you need to open an issue with ubuntu. They've apparently messed up their environment in such a way that you can't link to the libnl library, and thats broken.
Hello, I'm seeing the same issue on Debian 11. This is not a shared library issue - the symbols are present, but in dynamic table:
% objdump --dynamic-syms /lib/x86_64-linux-gnu/libnl-3.so.200 | grep nl_send
0000000000011830 g DF .text 00000000000000e0 Base nl_sendto
0000000000011910 g DF .text 0000000000000182 Base nl_sendmsg
0000000000012ad0 g DF .text 000000000000003c Base nl_send_sync
0000000000011aa0 g DF .text 00000000000000da Base nl_send_iovec
0000000000012c10 g DF .text 0000000000000005 Base nl_send_auto_complete
0000000000011b80 g DF .text 0000000000000084 Base nl_send
0000000000011c80 g DF .text 0000000000000022 Base nl_send_auto
0000000000011cb0 g DF .text 0000000000000070 Base nl_send_simple
The linkage error is rather caused by gcc
params order, as suggested/explained here: https://stackoverflow.com/questions/42113237/undefined-reference-when-linking-dynamic-library-in-ubuntu-system
This indeed works (libraries being listed after the object files):
gcc -g -Wall -Werror -I/usr/include/libnl3 -D_DEFAULT_SOURCE -D_XOPEN_SOURCE=600 -g -O2 -o dropwatch main.o lookup.o lookup_kas.o lookup_bfd.o -lnl-3 -lnl-genl-3 -lreadline -lpcap -lbfd
Ok, so what that article is saying is that ubuntu compiled their library with a linker script to only export symbols in the dynamic table, and built their compiler to only link symbols as needed, which necessitates a specific link order. That still doesn't change the fact that this is ubuntus problem to fix. If you want to work around it modify the src/Makefile.am script such that the AM_LDFLAGS adds a -Wl,--no-as-needed option to override their default compilation (which is likely what they did when they built the package
Probably user error, but figure I'll report this just in case. My system
After doing the follow dependency related installs:
autogen and configure run fine, but make fails with: