Re: libpcap detection and linking in tcpdump

[Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org>]

> --- Begin Message ---
>
>
> From: Guy Harris <gharris () sonic net>
>
> Date: Sat, 23 Jan 2021 14:50:20 -0800
>
> On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers <tcpdump-workers () lists tcpdump org> wrote:
>
> > I'll try experimenting with one of my Ubuntu VMs.
>
> Welcome to Shared Library Search Hell.
>
> Most UN*Xes have a notion of RPATH (with, of course, different compiler command-line flags to set it).
>
> pcap-config provides one if the shared library isn't going to be installed in /usr/lib.
>
> The pkg-config file doesn't provide one, however, and some searching indicates that the pkg-config maintainers 
> recommend *against* doing so.  They recommend using libtool when linking, instead.  Part of the problem here may be 
> that setting the RPATH in an executable affects how it searches for *all* libraries, so it could affect which version 
> of an unrelated library is found.
>
> (The existence of libtool is an indication that shared libraries have gotten messy on UN*X.)
>
> Perhaps for this particular case the right thing to do is to set LD_LIBRARY_PATH when running the temporarily-installed 
> tcpdump.
>
> The macOS linker appears to put absolute paths for shared libraries into the executable by default:
>
>         $ otool -L /bin/cat
>         /bin/cat:
>                 /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1281.100.1)
>
> so this may not be an issue there.
>
> (Also, the existence of the term "DLL hell" is an indication that shared libraries have gotten messy on Windows, but I 
> digress.... :-))
>
> --- End Message ---
_______________________________________________
tcpdump-workers mailing list
tcpdump-workers () lists tcpdump org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers