Re: [Libusb-devel] Programmatically Loading libusb Library

[<Phi...@mi...>]

Peter,

Excellent insight and advice.

Thanks again.

-- Phil


-----Original Message-----
From: Peter Stuge [mailto:pe...@st...] 
Sent: Monday, March 29, 2010 2:01 PM
To: Philip Joslin - C10554
Subject: Re: [Libusb-devel] Programmatically Loading libusb Library

Hi again Philip,

I'd prefer to move this discussion back to the mailing list. I think
it's perfectly on topic, since we are discussing use of libusb in real
world applications. Would that be OK with you?


Phi...@mi... wrote:
> >Could you please clarify a little?
> 
> From what you said, a build of libusb-1.0.0 or say libusb-1.0.3 would 
> produce the same names for so and link files in either case, correct?

Right.


> Now, for example, if we were building against libusb-1.0.3, and our 
> user was currently at libusb-1.0.0 (and using it for another app), we 
> could not use the user's links or .so file names generated by his 
> building of libusb (usually put in the /usr/local/lib dir on Linux) 
> because they would point to the wrong version for us (say again that 
> 1.0.3 provides some functionality we need that 1.0.0 does not 
> provide). We could not update his links to point to our installed 
> build of libusb-1.0.3 because that might break something of his 
> (albeit in a perfect world, the 1.0.3 should handle anything thrown at
it from an app using 1.0.0).
> 
> I hope I made this a little clearer.

Thanks - yes! The email subject threw me off a bit.

An app linked with 1.0.0 should indeed run just as well, if not better,
with a 1.0.3 library.

The only thing that could cause a problem is if the user's existing app
built with 1.0.0 relies on some bug which has been fixed in
1.0.3 - but off the top of my head I don't know of any typical such
cases, so I would suggest asking the user to test 1.0.3 (better yet,
1.0.6) with their app and then simply go with that.

As you say, the user's existing program *will* start if 1.0.3 is the
only available version, even if it was built against 1.0.0 - the only
problem would be bug compatibility.


> In our app, to initialize the libusb, we link to the libusb library of

> our libusb-1.0.3 build during compile/link time and during runtime 
> call libusb_init(). We would like it to use libusb-1.0.3 in the above 
> example. If the internal libusb calls in our code (via the libusb_init
> call) are using the system to find the libusb links (in 
> /usr/local/lib), then they will find the libusb-1.0.0 links that the 
> user had on his system. What I was wondering was how to redirect the 
> libusb_init() (and all libusb calls) to a specific libusb so file.

Individual function calls can not be redirected, but what you can do is
use some of the features in the loader, when your program is executed.
This is generally frowned upon however, the good way is to simply
upgrade the dependencies.


> I guess the main question is how do the libusb calls made in our code 
> (which was linked to a specific lib build of libusb) find the correct 
> libusb lib on the user's system (unless placing them in the same 
> subdir resolves that).

This is answered in excellent detail in the document I linked to:

http://people.redhat.com/drepper/dsohowto.pdf

The author is a long time developer of glibc, and has extended knowledge
on libaries, linkers and loaders. :)

For a much briefer overview, I can also recommend the ld-linux man
page:

http://linux.die.net/man/8/ld-linux


> (We normally put the one app of ours in a different directory as the 
> built libusb files.)

You can certainly restrict your app into a single directory, and specify
that directory as a custom LD_LIBRARY_PATH at run time, but that
requires knowledge about how the program was installed every time the
program should be started - which is not the most elegant solution, and
more importantly that mode of operation can be extremely difficult if
not impossible to integrate into the packaging system of various Linux
distributions that you would like to support.


//Peter