#26247: Various libusb libraries have same base name; please make each unique ---------------------------------------------------+------------------------ Reporter: michaelld@… | Owner: macports-tickets@… Type: enhancement | Status: closed Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Resolution: invalid | Keywords: Port: libusb, libusb-compat, libusb-legacy | ---------------------------------------------------+------------------------ Comment(by toby@…): Bad formatting... [[[ -L${prefix}/lib -lusb-1.0 = libusb -L${prefix/lib -lusb = libusb-compat -L${prefix}/lib/libusb-legacy -lusb = libusb-legacy ]]] -- Ticket URL: <http://trac.macports.org/ticket/26247#comment:2> MacPorts <http://www.macports.org/> Ports system for Mac OS

#26247: Various libusb libraries have same base name; please make each unique ---------------------------------------------------+------------------------ Reporter: michaelld@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Resolution: | Keywords: Port: libusb, libusb-compat, libusb-legacy | ---------------------------------------------------+------------------------ Changes (by michaelld@…): * status: closed => reopened * resolution: invalid => Comment: This is an enhancement request more than a bug report; maybe a little bit of each. I'm reopening this ticket for your re-consideration given the below. Let me give you another scenario, which BTW is what is happening that prompted this issue. I'm linking to both 'libfoo' and 'libusb' legacy (but, I have the other libusb's installed as well since they are used by other ports). libfoo comes back with: {{{ FOO_LDFLAGS="-L${prefix}/lib -lfoo" }}} and libusb comes back with: {{{ LIBUSB_LDFLAGS="-L${prefix}/lib/libusb-legacy -lusb" }}} Now when I link, I see: {{{ gcc -o bar bar.o ${FOO_LDFLAGS} ${LIBUSB_LDFLAGS} }}} so, which version of -lusb is used, the one in ${prefix}/lib or the one in ${prefix}/lib/libusb-legacy? I can tell you from testing it that it's the former because GCC will search for undetermined libraries in the order in which -L is places on the command line. I would have to go into the Makefile and change the link command to read: {{{ gcc -o foo foo.c ${LIBUSB_LDFLAGS} ${FOO_LDFLAGS} }}} in order to find the correct version of -lusb, which I really don't want to do because, among other reasons, it's not guaranteed to work with the next version of BAR. Now, OTOH, if the library names are unique (i.e., "-lusb-legacy" is used), then that's not an issue no matter where they are located. And, given that BAR retrieves the LIBUSB info via PKGCONFIG, renaming the library is already handled robustly. -- Ticket URL: <http://trac.macports.org/ticket/26247#comment:4> MacPorts <http://www.macports.org/> Ports system for Mac OS

#26247: Various libusb libraries have same base name; please make each unique ---------------------------------------------------+------------------------ Reporter: michaelld@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Resolution: | Keywords: Port: libusb, libusb-compat, libusb-legacy | ---------------------------------------------------+------------------------ Comment(by michaelld@…): GNU Radio is what I was working on when I hit this issue; there are a few other ports that use the libusb-legacy library but I don't know if anyone has tried them with the 'compat' version. In GNU Radio there is a configure option to use libusb-1.0, but the 'compat' version won't work because we (those of who wrote the USB interfaces; our bad) used LIBUSB internals that are in the 'legacy' library but are not part of the 'compat' library. So, I try to use the 'libusb-legacy' version, but another library is located in ${prefix}/lib and hence Autotools is linking the 'compat' library instead. Thus IMHO the need to rename -some- library -- I guess I'd propose the legacy one since it's already in a different location than expected. It's really not difficult to patch the code to do this. -- Ticket URL: <http://trac.macports.org/ticket/26247#comment:6> MacPorts <http://www.macports.org/> Ports system for Mac OS

#26247: Various libusb libraries have same base name; please make each unique ---------------------------------------------------+------------------------ Reporter: michaelld@… | Owner: macports-tickets@… Type: enhancement | Status: reopened Priority: Normal | Milestone: Component: ports | Version: 1.9.1 Resolution: | Keywords: Port: libusb, libusb-compat, libusb-legacy | ---------------------------------------------------+------------------------ Comment(by michaelld@…): So, I did a 'grep' on Portfiles, and it looks like the others that use libusb-legacy are libmtp and amarok (indirectly via libmtp). Both of these can be made to work using libusb-compat, so it's really just GNU Radio that needs libusb-legacy at this point. I'm updating GNU Radio from 3.2.2 to 3.3.0, testing the changes over the weekend, and checking everything in early next week. I'd really like to have the usrp port working at the same time as these checkins, and thus to have libusb-legacy using a different library name so-as to not use the compat library (as per my prior example). Given the no other port even uses libusb-legacy, and it's completely out of the way from other port's installs, and is "openmaintainer", I see changing the library name as a non-issue. If I haven't heard otherwise by early next week when I'm checking in GR 3.3.0, I'm going to go ahead with this augmentation -- along with a "notes" about this change for anyone outside MacPorts who's using it (if any). -- Ticket URL: <http://trac.macports.org/ticket/26247#comment:8> MacPorts <http://www.macports.org/> Ports system for Mac OS