[PATCH][TOOLS] ioemu: linking fix for *BSD

[PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

[-- Attachment #1: Type: text/plain, Size: 642 bytes --]


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

[-- Attachment #2: tools_qemu.diff --]
[-- Type: text/x-diff, Size: 481 bytes --]

diff -r da236d7f59b9 tools/ioemu/Makefile.target
--- a/tools/ioemu/Makefile.target	Wed Aug 13 22:22:21 2008 +0900
+++ b/tools/ioemu/Makefile.target	Thu Aug 14 10:29:22 2008 +0200
@@ -544,7 +544,7 @@ ifdef CONFIG_STUBDOM
 ifdef CONFIG_STUBDOM
 	$(AR) rcs $@ $(VL_OBJS)
 else
-	$(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)
 endif
 
 cocoa.o: cocoa.m

[-- Attachment #3: Type: text/plain, Size: 138 bytes --]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Ian Jackson]

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.

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Ian Jackson]

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.

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Ian Jackson]

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.

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Ian Jackson]

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.

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Daniel P. Berrange]

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

Re: [PATCH][TOOLS] ioemu: linking fix for *BSD

[Christoph Egger]

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