Opened 10 years ago

Closed 10 years ago

#26247 closed enhancement (fixed)

Various libusb libraries have same base name; please make each unique

Reported by: michaelld (Michael Dickens) Owned by: macports-tickets@…
Priority: Normal Milestone:
Component: ports Version: 1.9.1
Keywords: Cc: nerdling (Jeremy Lavergne), tobypeterson, brett@…, rwilcox (Ryan Wilcox)
Port: libusb, libusb-compat, libusb-legacy

Description

When linking with -lusb, the actual selected library will be one of 'libusb-1.0', 'libusb-0.1.4', or 'libusb-0.1.4.4.4" depending on which directory I pick for linking (via -L). Given that all versions of LIBUSB install a PKGCONFIG file as well as a 'config' executable for determining where install files are located and how to do linking, I think it makes sense to rename the legacy and compat versions with that info -- so, libusb-0.1.4.dylib becomes libusb-compat-0.1.4.dylib; libusb-0.1.4.4.4.dylib becomes libusb-legacy-0.1.4.4.4.dylib, and so forth. This way, there is no confusion between -lusb (libusb version 1), -lusb-compat (libusb compat), and -lusb-legacy (libusb legacy). I have a patch for libusb-compat that works; I'm working on one for libusb-legacy tonight & will attach the diffs once they work.

Attachments (1)

libusb-legacy_Portfile.diff (2.9 KB) - added by michaelld (Michael Dickens) 10 years ago.
Diff to libusb-legacy Portfile to rename library and related files to be 'libusb-legacy'

Download all attachments as: .zip

Change History (10)

comment:1 Changed 10 years ago by tobypeterson

Resolution: invalid
Status: newclosed

Not a bug.

-L${prefix}/lib -lusb-1.0 = libusb -L${prefix/lib -lusb = libusb-compat -L${prefix}/lib/libusb-legacy -lusb = libusb-legacy

comment:2 Changed 10 years ago by tobypeterson

Bad formatting...

[[[ -L${prefix}/lib -lusb-1.0 = libusb -L${prefix/lib -lusb = libusb-compat -L${prefix}/lib/libusb-legacy -lusb = libusb-legacy ]]]

comment:3 Changed 10 years ago by tobypeterson

Let's try that one more time...

-L${prefix}/lib -lusb-1.0 = libusb
-L${prefix/lib -lusb = libusb-compat
-L${prefix}/lib/libusb-legacy -lusb = libusb-legacy

comment:4 Changed 10 years ago by michaelld (Michael Dickens)

Resolution: invalid
Status: closedreopened

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.

comment:5 Changed 10 years ago by tobypeterson

Well nobody should be using libusb-legacy, other than gnuradio (afaik). If you stick to libusb and libusb-compat there shouldn't be a problem.

comment:6 Changed 10 years ago by michaelld (Michael Dickens)

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.

comment:7 Changed 10 years ago by michaelld (Michael Dickens)

I'm attaching a diff to the current Portfile that tweaks libusb-legacy's install name to be libusb-legacy all around (libraries, .pc file, config file). I've also created on for libusb-compat, but I think changing just the legacy version would be sufficient and best. This tweak fixes my GNU Radio issue, too.

Changed 10 years ago by michaelld (Michael Dickens)

Attachment: libusb-legacy_Portfile.diff added

Diff to libusb-legacy Portfile to rename library and related files to be 'libusb-legacy'

comment:8 Changed 10 years ago by michaelld (Michael Dickens)

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).

comment:9 Changed 10 years ago by michaelld (Michael Dickens)

Resolution: fixed
Status: reopenedclosed

Addressed in r71110 and r71111.

Note: See TracTickets for help on using tickets.