Xen devel - Aug 2008 - [PATCH][TOOLS] ioemu: linking fix for *BSD

Hi,

Attached patch tells the linker where to find

        libxenctrl.so.3.2, libxenguest.so.3.2 and libxenstore.so.3.0

when launching qemu-dm.

Signed-off-by: Christoph Egger <Christoph.Egger@amd.com>


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christoph Egger writes ("[Xen-devel] [PATCH][TOOLS] ioemu: linking fix for
*BSD"):
> Attached patch tells the linker where to find
>         libxenctrl.so.3.2, libxenguest.so.3.2 and libxenstore.so.3.0
> when launching qemu-dm.
I''m confused as to why this is necessary.
> -	$(CC) $(VL_LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(VL_LIBS)
> +	$(CC) $(VL_LDFLAGS) -Wl,-rpath,$(LIBDIR_x86_64) -o $@ $^ $(LIBS)
$(SDL_LIBS) $(COCOA_LIBS) $(VL_LIBS)
Surely LIBDIR_x86_64, ie /usr/lib64, should be on the linker path
already ?  Also I think this is wrong on all 32-bit builds, surely.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 14 August 2008 11:21:54 Ian Jackson wrote:
> Christoph Egger writes ("[Xen-devel] [PATCH][TOOLS] ioemu: linking fix
for
*BSD"):
> > Attached patch tells the linker where to find
> >         libxenctrl.so.3.2, libxenguest.so.3.2 and libxenstore.so.3.0
> > when launching qemu-dm.
>
> I''m confused as to why this is necessary.
ldd qemu-dm  shows this:

        libxenctrl.so.3.2 => not found
        libxenguest.so.3.2 => not found
        libxenstore.so.3.0 => not found

and launching qemu-dm fails with not finding these three libs.
> > -	$(CC) $(VL_LDFLAGS) -o $@ $^ $(LIBS) $(SDL_LIBS) $(COCOA_LIBS)
> > $(VL_LIBS) +	$(CC) $(VL_LDFLAGS) -Wl,-rpath,$(LIBDIR_x86_64) -o $@ $^
> > $(LIBS) $(SDL_LIBS) $(COCOA_LIBS) $(VL_LIBS)
>
> Surely LIBDIR_x86_64, ie /usr/lib64, should be on the linker path
> already ?  Also I think this is wrong on all 32-bit builds, surely.
And $(LIBDIR) is wrong for 64-bit builds on Linux.  On *BSD, it doesn''t
matter
if LIBDIR or LIBDIR_x86_64 is used.


-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thu, Aug 14, 2008 at 10:59:20AM +0200, Christoph Egger
wrote:
> 
> Hi,
> 
> Attached patch tells the linker where to find
> 
>         libxenctrl.so.3.2, libxenguest.so.3.2 and libxenstore.so.3.0
> 
> when launching qemu-dm.
This is bogus - the linker can find libraries just fine without
requiring -rpath. If it doesn''t, then you need to fix your ld.so.conf
to point to the non-standard location that you''re installing libraries
into.

Fedora forbids any use of -rpath, and Debian strongly discourages its
use

http://wiki.debian.org/RpathIssue
http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath


Daniel
-- 
|: Red Hat, Engineering, London   -o-   http://people.redhat.com/berrange/ :|
|: http://libvirt.org  -o-  http://virt-manager.org  -o-  http://ovirt.org :|
|: http://autobuild.org       -o-         http://search.cpan.org/~danberr/ :|
|: GnuPG: 7D3B9505  -o-  F3C9 553F A1DA 4AC2 5648 23C1 B3DF F742 7D3B 9505 :|

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu: linking fix
for *BSD"):
> On Thursday 14 August 2008 11:21:54 Ian Jackson wrote:
> > I''m confused as to why this is necessary.
> 
> ldd qemu-dm  shows this:
>         libxenctrl.so.3.2 => not found
>         libxenguest.so.3.2 => not found
>         libxenstore.so.3.0 => not found
> and launching qemu-dm fails with not finding these three libs.
Are they in /usr/lib64 ?  If they are, why isn''t your dynamic linker
finding and using them ?  There must be something else going on here,
surely.  Where _is_ it looking ?  (Use ktrace perhaps.)

Perhaps something is being built as the wrong bitness (or at least, an
unexpected bitness).  Are those libraries really the same bitness as
qemu-dm and is everything in the right places ?

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 14 August 2008 11:34:27 Ian Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu: linking
fix
for *BSD"):
> > On Thursday 14 August 2008 11:21:54 Ian Jackson wrote:
> > > I''m confused as to why this is necessary.
> >
> > ldd qemu-dm  shows this:
> >         libxenctrl.so.3.2 => not found
> >         libxenguest.so.3.2 => not found
> >         libxenstore.so.3.0 => not found
> > and launching qemu-dm fails with not finding these three libs.
>
> Are they in /usr/lib64 ?  If they are, why isn''t your dynamic
linker
> finding and using them ?  There must be something else going on here,
> surely.  Where _is_ it looking ?  (Use ktrace perhaps.)
>
> Perhaps something is being built as the wrong bitness (or at least, an
> unexpected bitness).  Are those libraries really the same bitness as
> qemu-dm and is everything in the right places ?
The libraries are not in system libraries but in a separate directory
where all the 3rd party applicatios'' libraries are kept.

The patch does the right thing for netbsd.

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu: linking fix
for *BSD"):
> The libraries are not in system libraries but in a separate directory
> where all the 3rd party applicatios'' libraries are kept.
Well, if you do that then you should put that directory in your
dynamic linker configuration so that they get picked up.  Or you can
add the rpath locally by setting some appropriate variable.

If providing an extra linker flag for the build system to use is
excessively difficult then perhaps we should add a bit of plumbing to
make it easier.  I haven''t checked to see how one would do this.

But really, I don''t think we would recommend this configuration.
> The patch does the right thing for netbsd.
There doesn''t seem to be anything BSD specific here.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 14 August 2008 11:31:46 Daniel P. Berrange
wrote:
> On Thu, Aug 14, 2008 at 10:59:20AM +0200, Christoph Egger wrote:
> > Hi,
> >
> > Attached patch tells the linker where to find
> >
> >         libxenctrl.so.3.2, libxenguest.so.3.2 and libxenstore.so.3.0
> >
> > when launching qemu-dm.
>
> This is bogus - the linker can find libraries just fine without
> requiring -rpath. If it doesn''t, then you need to fix your
ld.so.conf
> to point to the non-standard location that you''re installing
libraries
> into.
>
> Fedora forbids any use of -rpath, and Debian strongly discourages its
> use
>
> http://wiki.debian.org/RpathIssue
> http://fedoraproject.org/wiki/Packaging/Guidelines#Beware_of_Rpath
>
>
> Daniel
ld.so.conf (for rpaths) is largely a hack to help people who can''t
relink
binaries and don''t want to / can''t pollute system dirs.
rpath is the "elf way".  ld.so.conf is additional hack some ELF
systems
provide.  solaris doesn''t, for instance.

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 14 August 2008 11:58:38 Ian Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu: linking
fix
for *BSD"):
> > The libraries are not in system libraries but in a separate directory
> > where all the 3rd party applicatios'' libraries are kept.
>
> Well, if you do that then you should put that directory in your
> dynamic linker configuration so that they get picked up.  Or you can
> add the rpath locally by setting some appropriate variable.
>
> If providing an extra linker flag for the build system to use is
> excessively difficult then perhaps we should add a bit of plumbing to
> make it easier.  I haven''t checked to see how one would do this.
>
> But really, I don''t think we would recommend this configuration.
>
> > The patch does the right thing for netbsd.
>
> There doesn''t seem to be anything BSD specific here.
Right. It''s the "ELF way". See my other mail. Sounds like you
got a sort
of "culture shock". :)

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu: linking fix
for *BSD"):
> On Thursday 14 August 2008 11:58:38 Ian Jackson wrote:
> > There doesn''t seem to be anything BSD specific here.
> 
> Right. It''s the "ELF way". See my other mail. Sounds
like you got a sort
> of "culture shock". :)
Err.  I''m from a Debian and Linux background, which has been doing ELF
for approximately forever.  Did you read the two links Daniel Berrange
posted ?

Your proposed patch would cause, on most ordinary builds, an -rpath to
be supplied pointing at the system directories /usr/lib{,64}.  This
would be wrong.

When you supply options or variable settings to override the
installation directory to one which isn''t on the default search path,
you must also supply the the rpath yourself at that point.  If this is
too hard we whould make it easier but aside from that I think no
change should be made.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Thursday 14 August 2008 12:12:12 Ian Jackson wrote:
> Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu: linking
fix
for *BSD"):
> > On Thursday 14 August 2008 11:58:38 Ian Jackson wrote:
> > > There doesn''t seem to be anything BSD specific here.
> >
> > Right. It''s the "ELF way". See my other mail.
Sounds like you got a sort
> > of "culture shock". :)
>
> Err.  I''m from a Debian and Linux background, which has been doing
ELF
> for approximately forever.  Did you read the two links Daniel Berrange
> posted ?
Yes. It is about finding different libc in different places. They claim
there''s a potential problem w/o clearly stating it.
rpath allows you to explicitely specify which libc you want to use
at runtime.
> Your proposed patch would cause, on most ordinary builds, an -rpath to
> be supplied pointing at the system directories /usr/lib{,64}.  This
> would be wrong.
hmm... right. It should do anything in system dirs.
The patch needs to be redone. Maybe using a variable which is
empty on Linux ?

Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel

On Friday 15 August 2008 13:54:47 Christoph Egger wrote:
> On Thursday 14 August 2008 12:12:12 Ian Jackson wrote:
> > Christoph Egger writes ("Re: [Xen-devel] [PATCH][TOOLS] ioemu:
linking
> > fix
>
> for *BSD"):
> > > On Thursday 14 August 2008 11:58:38 Ian Jackson wrote:
> > > > There doesn''t seem to be anything BSD specific
here.
> > >
> > > Right. It''s the "ELF way". See my other mail.
Sounds like you got a
> > > sort of "culture shock". :)
> >
> > Err.  I''m from a Debian and Linux background, which has been
doing ELF
> > for approximately forever.  Did you read the two links Daniel Berrange
> > posted ?
>
> Yes. It is about finding different libc in different places. They claim
> there''s a potential problem w/o clearly stating it.
> rpath allows you to explicitely specify which libc you want to use
> at runtime.
>
> > Your proposed patch would cause, on most ordinary builds, an -rpath to
> > be supplied pointing at the system directories /usr/lib{,64}.  This
> > would be wrong.
>
> hmm... right. It should do anything in system dirs.
err. I meant "It should NOT do anything in system dirs".
When I think faster than I type, whole words get "lost". :)
> The patch needs to be redone. Maybe using a variable which is
> empty on Linux ?
>
> Christoph

-- 
AMD Saxony, Dresden, Germany
Operating System Research Center

Legal Information:
AMD Saxony Limited Liability Company & Co. KG
Sitz (Geschäftsanschrift):
   Wilschdorfer Landstr. 101, 01109 Dresden, Deutschland
Registergericht Dresden: HRA 4896
vertretungsberechtigter Komplementär:
   AMD Saxony LLC (Sitz Wilmington, Delaware, USA)
Geschäftsführer der AMD Saxony LLC:
   Dr. Hans-R. Deppe, Thomas McCoy


_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xensource.com
http://lists.xensource.com/xen-devel