Re: [Xen-changelog] Break the building/save/restore code out into a separate library libxenguest.

Re: [Xen-changelog] Break the building/save/restore code out into a separate library libxenguest.

[Anthony Liguori]

Xen patchbot -unstable wrote:

>+LDFLAGS  += -L.
>  
>
I considered linking libxenbuild against libxenctrl this way however 
I've found that even if you have -L., often you'll get linked to a 
library in /usr/lib instead.  If you're running in the build tree, this 
can result in very unpredictable results.

Is there a better way to do this?  It seems better to force an app to 
include both libraries.  I can submit a xen-config script that takes a 
--libs option to simplify this.

> 
>
Regards,

Anthony Liguori

Re: Re: [Xen-changelog] Break the building/save/restore code out into a separate library libxenguest.

[Keir Fraser]

On 25 Aug 2005, at 03:11, Anthony Liguori wrote:

> I considered linking libxenbuild against libxenctrl this way however 
> I've found that even if you have -L., often you'll get linked to a 
> library in /usr/lib instead.  If you're running in the build tree, 
> this can result in very unpredictable results.

> Is there a better way to do this?  It seems better to force an app to 
> include both libraries.  I can submit a xen-config script that takes a 
> --libs option to simplify this.

Even if the app links against both libraries don't you have the same 
basic problem. i.e., the library found at link time may not be the same 
one as found at run time?

I don't see any automatic way of getting round this, and I really hate 
those foo-config scripts.

The version suffixes on shared libraries are *supposed* to avoid this 
issue (but don't work while APIs are changing, of course). While things 
are in flux, I think you just have to be careful with LD_LIBRARY_PATH 
if you have libraries in non-standard locations.

  -- Keir