ANNOUNCEMENT: Live Wireshark University & Allegro Packets online APAC Wireshark Training Session
April 17th, 2024 | 14:30-16:00 SGT (UTC+8) | Online

Wireshark-bugs: [Wireshark-bugs] [Bug 6011] Upgrading to 1.6.0 can lead to a library mismatch.

Date: Mon, 20 Aug 2012 13:22:37 -0700 (PDT)
https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6011

--- Comment #7 from Guy Harris <guy@xxxxxxxxxxxx> 2012-08-20 13:22:36 PDT ---
(In reply to comment #6)
> Yes, "where some or all of the third-party packages used by Wireshark are
> installed" and "where Wireshark will be installed" aren't necessarily the same
> place.

On the other hand, a "third-party stuff, including what I'm building and a lot
of the stuff it uses, goes here" option would be useful in cases where they
*are* the same place.

I'm assuming the underlying problems are, as given in the Gentoo bug:

> For some reason, configure.in does a check "whether to use $prefix for headers
> and libraries" and then assumes that $prefix/lib is the place to go. However,
> this ignores the possibility we might rather use $prefix/lib64 or other nice
> goodies. Not only that, it goes on to add -L/usr/lib to LDFLAGS, which neatly
> plants it between our LDFLAGS and any linker arguments directing users to better
> places, so that even in src_install(), libtool relinks against the installed library.

At least part of the second issue could be handled by checking whether $prefix
is /usr or, perhaps, /usr/local (at least on systems where the default
toolchain looks in /usr/local; I'm not sure all do), and not adding it to the
search path for includes or libraries if it is.

The first problem doesn't necessarily have a straightforward fix, given that
there are, I think, at least two competing "support 32-bit and 64-bit code on
the same machine" schemes for Linux, and others might show up in other Linux
distributions or other UN*Xes in the future.

Then again, that problem also exists for the --with-XXX=DIR options, as they
add DIR/lib to the library search path.

The *right* fix is arguably to have a whole bunch of places in the system
understand the notion of "places to look", with those "places" assumed to have
a similar directory structure to / and /usr, so you could add a "place" to your
search path and have its bin subdirectory (or whatever) added to $PATH, its lib
or lib64 or whatever directory added to the places ld and the run-time linker
search for libraries, its include directory added to the places the compiler
searches for header files, its share/autowhatever and share/aclocal directories
added to the places the autotools search for macros, its lib/pkgconfig
directory added to the places pkg-config searches for .pc files, etc..

-- 
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.
You are watching all bug changes.