libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Compiling into chroot


From: Alon Bar-Lev
Subject: Re: Compiling into chroot
Date: Sat, 14 Jun 2008 10:59:06 +0300

Thank you for your response.

As long as it is in the future TODO list it is good I am waiting for
this for a long time. If it was difficult to you guys, imagine how it
is for someone external...

Building packages into chroot is more and more common, live-cd,
live-usb, initramfs, embedded, vservers etc...

A lot of packages use libtool, so using the standard gnu build for
chroot environment, in order to build packages without change in the
package is important.
./configure --prefix=/
make install DESTDIR=/tmp/myroot

As far as I know libtool is the only tool that needs fixups or
workaround. If there is any formal workaround for this I will be happy
to know, my sample implementation is available at [1]. I will be happy
to modify it if there is a better way. But still I get real paths in
libraries:

 $ i586-pc-linux-uclibc-readelf --dynamic root1/lib/libopensc.so

 Dynamic section at offset 0x7be90 contains 27 entries:
  Tag        Type                         Name/Value
 <snip>
  0x0000000f (RPATH)                      Library rpath:
 [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib]
  0x0000001d (RUNPATH)                    Library runpath:
 [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib]
  0x0000000c (INIT)                       0x6610
 <snip>

Thank you,
Alon Bar-Lev.

[1] http://www.opensc-project.org/windows/browser/trunk/build

On 6/14/08, Ralf Wildenhues <address@hidden> wrote:
> Hello Alon, Bob, all,
>
>  * Bob Friesenhahn wrote on Thu, Jun 12, 2008 at 10:07:39PM CEST:
>
> >
>  > The best path forward is that if you feel strongly enough about this,
>  > then prepare a patch for libtool which works for you.
>
>
> That's necessary, but typically not sufficient, unfortunately.  ;-)
>
>
>  > The patched
>  > libtool needs to be tested on various host environments to make sure
>  > that it still passes all of its tests.  It needs to work for C, C++, and
>  > other languages that libtool supports.  If the patched libtool only works
>  > properly for one host environment, then it is not worth accepting into
>  > libtool.
>
>
> Sigh.  Fixing DESTDIR support is a lot of work.  I think I threw a
>  month's worth of weekends at it once, and then decided to postpone it
>  for a long time.  Except for systems using GNU binutils, it'd hardly
>  work anywhere anyway (in order for to have libtool still behave vaguely
>  similar to how it does now, you'd have to have -rpath-link, which most
>  other linkers don't).
>
>  If there is some volunteer wanting to work on this (with lots of time on
>  their hands), please speak up, and I can try to dig out stuff and go
>  into detail.  Actually, if you're a student, and have free time next
>  summer, starting on this could be a good summer-of-code project.
>
>  Cheers,
>
> Ralf
>




reply via email to

[Prev in Thread] Current Thread [Next in Thread]