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 <[EMAIL PROTECTED]> 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 > _______________________________________________ http://lists.gnu.org/mailman/listinfo/libtool
