--- Begin Message ---
Guy Harris via tcpdump-workers wrote:
> (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
--- Begin Message ---
On Jan 22, 2021, at 7:11 PM, Guy Harris via tcpdump-workers
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).
--- Begin Message ---
Guy Harris via tcpdump-workers wrote:
>> $ /tmp/libpcap/bin/pcap-config --libs -L/tmp/libpcap/lib
>> -Wl,-rpath,/tmp/libpcap/lib -lpcap
> So that *should* cause /tmp/libpcap/lib to be added to the executable's
> path, which *should* cause it to look in
--- Begin Message ---
On Jan 22, 2021, at 2:54 PM, Denis Ovsienko via tcpdump-workers
wrote:
> I have tested it again with the current master branches of libpcap and
> tcpdump. Both builds (with and without libpcap0.8-dev) now complete
> without errors.
>
> However, in both cases the installed
--- Begin Message ---
On Wed, 9 Sep 2020 17:07:25 +0100
Denis Ovsienko via tcpdump-workers
wrote:
> Here are my steps to reproduce:
>
> libpcap$ ./configure --enable-remote --prefix=/tmp/libpcap
> libpcap$ make
> libpcap$ make install
> tcpdumpbuild$ cmake -DWITH_CRYPTO="yes"
>
--- Begin Message ---
On Jan 7, 2021, at 5:41 PM, Denis Ovsienko via tcpdump-workers
wrote:
> 5 years of backward compatibility might be OK'ish, although from time
> to time I run into such "long-term support" systems that in practice
> mean someone keeps paying good money for "support" for
--- Begin Message ---
On Thu, 7 Jan 2021 16:46:41 -0800
Guy Harris wrote:
> 3.1 dates back to 2015. That might be sufficient to treat as a
> minimum.
5 years of backward compatibility might be OK'ish, although from time
to time I run into such "long-term support" systems that in practice
mean
--- Begin Message ---
On Jan 7, 2021, at 3:21 PM, Guy Harris via tcpdump-workers
wrote:
> So we should either 1) require CMake 3.1 or later or 2) forcibly set
> PKG_CONFIG_USE_CMAKE_PREFIX_PATH to YES. For now, my inclination is to do
> the latter.
That won't work -
--- Begin Message ---
On Sep 9, 2020, at 9:07 AM, Denis Ovsienko via tcpdump-workers
wrote:
> The "Found pcap-config" message means that FindPCAP.cmake has not found
> libpcap by means of pkg-config, and the lack of the message means the
> pkg-config method worked. A few weeks ago Ubuntu 18.04
--- Begin Message ---
On Jan 7, 2021, at 9:35 AM, Bill Fenner via tcpdump-workers
wrote:
> These jobs are still failing, but now for a different reason.
Part of the problem is that pkg-config wasn't finding the locally-installed
libpcap under /tmp, because PKG_CONFIG_PATH wasn't set to point
--- Begin Message ---
On 07/01/2021 18:35, Bill Fenner via tcpdump-workers wrote:
> These jobs are still failing, but now for a different reason. The build
> succeeds, but the tests fail - the tests that require the new libpcap.
> However, if you augment TESTrun to print the version, it says
>
--- Begin Message ---
On Wed, Sep 9, 2020 at 12:08 PM Denis Ovsienko via tcpdump-workers <
tcpdump-workers@lists.tcpdump.org> wrote:
> Travis CI tcpdump builds have been failing for a while and I went to
> see why. It is easy to see that only the jobs that have
> "BUILD_LIBPCAP=yes CMAKE=yes"
--- Begin Message ---
Hello list.
Travis CI tcpdump builds have been failing for a while and I went to
see why. It is easy to see that only the jobs that have
"BUILD_LIBPCAP=yes CMAKE=yes" fail, for example [1], and the same jobs
built well before, for example [2].
The tcpdump build process
13 matches
Mail list logo
