Configuring a static tcpdump build fails, with a misleading error, on platforms where libpcap does not support static linking #947
Comments
Is that the output of "make linux" or of "make static-tcpdump"? To quote the configure error message:
Please attach the config.log file in the sniff directory to this bug. |
|
It is the output for |
|
What does |
|
guyharris
changed the title
|
Unfortunately, in the general case, the One reason why those commands are used by configure scripts is to determine what linker flags are necessary in order to link with a given library, such as libpcap. On most UN*X platforms, a shared library can be linked with other shared libraries that it requires, and linking a program using that static library does not need to link with those other libraries. Given that a program linked with, for example, a shared-library version of libpcap should be able to work regardless of whether it's running on a system where the installed version of libpcap is, or isn't, linked with the D-Bus library (the only difference is whether it'll be able to capture D-Bus traffic or not), that program shouldn't be linked with the D-Bus shared library unless it directly uses that library, so that it can run on a system without that shared library; the program should not itself be given a dependency on a library that it does not directly use, merely because, on the system on which it's compiled, a library it does directly use happens to itself directly use some other library. Therefore, when either On most if not all UN*X platforms, however, static libraries don't have a way to record in the library the libraries on which that library depends. Furthermore, linking with a static library requires linking with those dependencies; finding those routines cannot be deferred until run time, as can happen when linking with a shared library. Therefore, there needs to be a way to ask Supporting static linking would thus require that the configure script for a program determine whether the program is being statically linked and, if so, pass Unfortunately, it's a bit of a pain to determine whether the program is being statically linked, as that might be specified by the setting of the So this may require some work to fix. Then you'd have to wait for the fix to show up in a release, as it appears that the ksniff build downloads a tcpdump source tarball and compiles it. (Either that, or you'd have to, as per ksniff's README.md file, use "kubectl debug", once that feature is available.) |
|
I'll look at fixing this as best I can, but there's nothing I can do about the lack of a static version of libsystemd in Debian. Debian have chosen to build libpcap with support for D-Bus sniffing, which means it links with So I'll close this when I've changed tcpdump's configure script - and CMake scripts - to try to determine whether a static link is being done and, if so, pass So the options that I can see are:
Option 2 is probably the one most likely to work in the short term, as it doesn't include the phrase "wait for". It involves some work. Option 1 is probably the one with the shortest "wait for" time, as it involves only one change. Option 3 is involves convincing Debian to provide a static libsystemd, as well as requiring you to wait for several things to happen, both on the part of the tcpdump/libpcap developers (including producing releases of both tcpdump and libpcap) and on the part of Debian once the updated libpcap has been released. |
|
I'm here with the similar motivation but on Fedora . Where I get Offtopic: To somebody googling ksniff problem: static-tcpdump binary provided by ksniff segment faults: |
|
Is this the problem that |
It's a problem that, in some cases, would require that Furthermore, if "static build" means a build that produces a guaranteed-to-be-completely-statically-linked binary, rather than a possibly dynamically-linked binary that's guaranteed to be statically linked with libpcap, it would also require that pkg-config be the first mechanism used to test for the presence of libraries, so that, for a static build,
so that the right flag can be passed to (It would also require that libpcap not include DPDK support unless all of the libraries that |
|
Static builds are clearly complicated enough to deserve a detailed FAQ entry. |
|
|
Running into this issue on openSUSE: |
|
So what was the full command you ran to do the configuration, what is the output of |
|
Thanks for the quick reply. Here are the logs you wanted, if you need anything else speak reach out to me.
Full command was: Part of the config.log: env output: |
UN*X systems have, over time, grown less friendly towards fully-static builds of executables. Linux distributions happen to be less unfriendly, than, say, macOS or Solaris (neither of them support statically linking with the system library at all), but it's still not 100% friendly; see, for example: Fixing the remaining issues (which would be a problem even if you only wanted to link statically with libpcap) would require the configure script to determine that it's being asked to configure a fully-static build and then use That would probably involve looking at CFLAGS to see whether it contains the either If it detects that on macOS, Solaris, or any other "sorry, no fully-static linking" platforms, it should probably just print an error message explaining that and quit. If it detects that on Linux, it should warn of various problems, arrange to use (Fill in other actions for various *BSDs and AIX. Don't do anything for HP-UX, Tru64 UNIX, or IRIX until somebody complains about them.) Note, though, that: there may not be a static libsystemd on your machine; I think the libsystemd developers were asked for static libraries and they responded "sorry, no". If so, you will not have any luck linking with what I presume is your system libpcap, as I think libdbus requires libsystemd, and they configured it to included libdbus (to support D-Bus snooping), so it might be impossible to link a program fully statically with your system's libpcap. Try, for example, compiling this program (after renaming it from "dbtest.c.txt" to "dbtest.c"; the ".txt" is an annoying requirement due to GitHub rules) with and then try linking dbtest.o with If you get a message such as "/bin/ld: cannot find -lsystemd: No such file or directory", you are probably doomed in any attempt to have a fully statically linked tcpdump, unless you build your own libpcap, without D-Bus support, and link with that. That may reduce the problems to just "warning: Using '{routine to do IP address <-> host name translation' in statically linked applications requires at runtime the shared libraries from the glibc version used for linking". (I don't know what that means you need to do if you plan to run this program on another machine; it probably means it'll work on the same machine, or a machine running the same version of the distribution you're using, but I don't know enough to guarantee that.) It might be possible to link statically with your system's libpcap but dynamically with everything else. That would be trickier, as the configure script would need to determine what command-line flags can be used to say "link statically with this library, but link however is the default with all other libraries". The right mix of |
|
Sorry for the late reply, @guyharris |
guyharris
changed the title
|
See also Wireshark issue #19765 - same underlying problem. |
when compiling i recieve the following error:
Things to note
ksniffvia there Makefilecurrent installed versions Debian (bullseye)
more information CFLAGS, etc. in the
Makefilehere:https://github.com/eldadru/ksniff/blob/master/Makefile#L36
Steps to Reproduce
Anyways. I hope this helps. or at least provides some more information to go off. There could be some more information and code in that
ksniffproject that may help pinpoint what the cause is as well.The text was updated successfully, but these errors were encountered: