Re: [Qemu-devel] configure flag for compilation question..

[Ben Taylor]

---- Martin Bochnig <address@hidden> wrote: 
> Ben Taylor wrote:
> 
> >---- Ishwar Rattan <address@hidden> wrote: 
> >  
> >
> >>Trying to compile qemu on amd64 based Solaris.
> >>
> >>I do not have write permission to /usr/local subtree
> >>
> >>./configure --libdir=other-path --prefix=not-ustlocal
> >>is fine
> >>but make always generates binaries that want to find
> >>/usr/local/lib/libSDL-1.2.so.0 etc. (checked with ldd).
> >>
> >>What is the way out for this sticky point?
> >>    
> >>
> >
> >Manually add "-L/usr/local/lib -R/usr/local/lib" 
> >
> 
> Rather "-L/his/home/sdl_amd64/lib -R/his/home/sdl_amd64/lib"

Yeah, that.  brain fart when I was typing that.

> Because I doubt, an amd64 version of libSDL is currently present in
> /usr/local/lib/amd64
> (and he doesn't have w access).

Right. I knew what I meant, I just didn't type it right.

> This method is btw not really "new" to me, see my posting from a few
> hours ago:
> http://www.opensolaris.org/jive/thread.jspa?threadID=15448&tstart=0
> 
> 
> >to the Makefile for the link
> >phase so it will correctly add those paths to the library lookup.  If I had
> >a code base to look at this instance, I could tell you where.  You could
> >also add those flags to Makefile.target in the SOLARIS specific areas,
> >which would probably make more sense.
> >
> >As Martin indicated, setting LD_LIBRARY_PATH may get you a running
> >binary, but LD_LIBRARY_PATH is the wrong answer for Solaris.
> >
> >Ben
> >  
> >
> 
> > "LD_LIBRARY_PATH is the wrong answer for Solaris"
> ???
> --->>  Weak statement.

LD_LIBRARY_PATH is the wrong answer for Solaris.  It's great for
trying to fix problems like this when the app won't run with a particular
set of libraries, or you're testing with new libraries and you don't
want to recompile  (I've done this before).  Too many people use
it as a panacea for poorly compiled/configured Open source software.
In this case, he might just set the LD_LIBRARY_PATH and never
recompile it, even though it won't work if it uses the default LIB path.
 
> It has its [dis]advantages.
> Namely that the paths to a library are _not_ hardwired.

But then that requires a dependency on knowing where your
libraries are, and could possibly create an imcombaility by
overriding a library path for some other application that is
also leaning on LD_LIBRARY_PATH.  Obviously you can
get around this by encapsulating each application requiring
LD_LIBRARY_PATH, thereby negating the need for a user
or system wide LD_LIBRARY_PATH variable.

> That's the exactly reason, why I did recommend it in this very scenario.

In this case, I can agree for the purposes of a test.  But it also indicates
that some work is required for the Solaris port if other library paths
need to be linked in during the compliation/link phase.

> And I would do it again for Ishwar's current needs.

Works for me.

Ben