LIBUSB -legacy only- Poll

Bradley Giesbrecht brad at
Tue Aug 31 08:00:28 PDT 2010

On Aug 31, 2010, at 7:37 AM, Michael Dickens wrote:

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

Wouldn't adding your desired flags to the front of configure.env,  
configure.pre_args or where ever else needed work?

// Brad
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the macports-users mailing list