LIBUSB -legacy only- Poll

[Michael Dickens]

Does any project beyond GNU Radio's USRP actually -require- the
"libusb-legacy" (0.1.12) port / library?

The reason I'm asking is that I want to rename the installed
"libusb-legacy" libraries from "libusb.dylib" (etc) to
"libusb-legacy.dylib" (etc) in order to avoid the (as I'm calling
it) "same name different directory" library linking issue
described below [*].  I've verified that this renaming is
relatively simple to implement via REINPLACE patches to the
"libusb-legacy" code, and that it does indeed resolve the "same
name different directory" issue (because, well, the libraries no
longer have the same name :).

NOTES
---
1) There is a "libusb-compat" version that is API compatible (not
ABI compatible, which is why USRP requires the legacy version),
which almost all of the MacPorts ports have been moved to
using.  In a search of all current MacPorts Portfiles, I find
that libmtp (and, Amarok via that) has this library
requirement, but those ports can use libusb-compat -- so, I'm
updating the Portfiles to reflect this change.  Hence, after the
change, and inside MacPorts only, the USRP port will be the only
port to -require- the libusb-legacy port.

2) All versions of LIBUSB (1.0, compat, legacy) install a
PKGCONFIG file that describes the necessary LDFLAGS, CFLAGS, and
so forth for compiling and linking -- in my experience, all
modern MAKE variants (qmake, cmake, autotools) either directly
check for PKGCONFIG files or easily allow for their use & hence
I'd like to think that nobody hard-wires these external libraries
any longer.  My proposed change will be reflected in the
installed PKGCONFIG file for libusb-legacy, so relinking your
external-to-MacPorts project should be just a matter of
re-configuring and re-building.

[*] "same name different directory" library link issue
---
Suppose we have the libraries:

1) "libfoo" is installed with FOO_LDFLAGS="-L${prefix}/lib
-lfoo";

2) "libusb-compat" is installed with
LIBUSB_COMPAT_LDFLAGS="-L${prefix}/lib -lusb";

3) "libusb-legacy" is installed with
LIBUSB_LEGACY_LDFLAGS="-L${prefix}/lib/libusb-legacy -lusb";

then what is the linking result from:

gcc -o foo foo.o ${FOO_LDFLAGS} ${LIBUSB_LEGACY_LDFLAGS}

(assuming that the commands and files exist and are otherwise
valid)?  Expanding this command out I get:

gcc -o foo foo.o -L${prefix}/lib
-lfoo -L${prefix}/lib/libusb-legacy -lusb

and since GCC works by searching the -L paths in the order
presented, "-lusb" will be found in ${prefix}/lib, not in my
desired ${prefix}/lib/libusb-legacy.  Hence, I need to do one of:

(a) rearrange the -L ordering so that specific installs (e.g.,
${prefix}/lib/libusb-legacy, which holds just the libraries for
libusb-legacy) come first and then work my way down to generic
paths (e.g., ${prefix}/lib, which holds lots of libraries).  This
may or not be simple depending on how many libraries are being
linked to and how the Makefile was constructed for each specific
project that has this issue.  In this specific case, USRP's
Makefile can be easily changed to fix this issue.

(b) rename the "libusb-legacy" library to some other name --
which is relatively simple in this case, since autotools uses a
specific naming that's easily manipulated by SED commands. or:

(c) specify the full library path and name for all libraries
(e.g., "${prefix}/lib/libusb-legacy/libusb.dylib", assuming it
exists) -- which is not a simple task.

My preference is to do (b) since it's the easiest and IMHO the
most robust.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macosforge.org/pipermail/macports-dev/attachments/20100831/2ab7c7b3/attachment.html>