Re: Relocatable libraries with libtool--can I do it?
On Wed, Nov 24, 2004 at 07:18:48PM -0500, Paul Smith wrote: But I need to be able to copy that entire image to another location, set ROOT to that location, and cross-compile code using that image in that new location. export ROOT=/tmp/ppc-image ./configure --prefix=/usr CC=ppc-gcc CXX=ppc-g++ make make install DESTDIR=$ROOT Here's an idea. To make existing libtool work with your arrangement, you could instead build every libtool-using package like this: ./configure --prefix=$ROOT other-args make make install Then, for each $ROOT you used, make at $ROOT _within the image_ a symlink pointing to top of the image. For ROOT=/roots/ppc-image, cd $ROOT ; mkdir roots ; cd roots ; ln -s .. ppc-image (Your image will not be FHS-compliant.) ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Relocatable libraries with libtool--can I do it?
On Wed, Nov 24, 2004 at 07:18:48PM -0500, Paul Smith wrote: My environment involves running in an x86 host running Linux, and cross-compiling everything for a different target. A few extra things about this are (a) that we do not use chroot or any similar technology, and (b) the entire thing needs to be completely relocatable at any time. Several individuals have communicated similar requirements here. Some had partial workarounds you may find useful; check the archives. It seems like the right answer would be for the .la files to have knowledge of ROOT or DESTDIR, or some other variable like LIBTOOL_ROOT or something, and automatically prepend that value to the appropriate pathnames for finding libraries _AT BUILD TIME_, without impacting the paths set to find libraries _AT RUNTIME_. Does this seem correct? Or am I missing something else? Roughly. The .la does not need to encode the $ROOT, but libtool needs to know it when interpreting each .la on the build system. I have a draft patch to do that. If I find some free time, I will finish it and post to libtool-patches. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Relocatable libraries with libtool--can I do it?
* Paul Smith wrote on Thu, Nov 25, 2004 at 01:18:48AM CET: Hi all. I'm having a severe problem with libtool-ized packages, of which there are more and more these days, in my environment. I'm wondering if anyone here can suggest how I should proceed; whether there's something in libtool that will help me, or whether libtool needs enhancements, or what. Libtool probably needs a little enhancement and some bugfixing. My environment involves running in an x86 host running Linux, and cross-compiling everything for a different target. A few extra things about this are (a) that we do not use chroot or any similar technology, and (b) the entire thing needs to be completely relocatable at any time. Only one question for now (I don't know enough about the problem space yet), concerning notation: _Relocatable_ IMHO is a package which can be installed (literally copied to) in /usr or /usr/local without any difference. You do not really need *relocatable* libraries, right? You only do staged installs (by using DESTDIR), and all you ever move around is the staging area. The place where the library will find itself at the time it is used by ld.so is fixed from the very beginning, right? This is a significant simplification and required from libtool's point of view. Can we agree on this notion of relocation and staging? It corresponds to what the Autotools manuals use. Regards, Ralf ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Relocatable libraries with libtool--can I do it?
%% Ralf Wildenhues [EMAIL PROTECTED] writes: rw Only one question for now (I don't know enough about the problem space rw yet), concerning notation: rw _Relocatable_ IMHO is a package which can be installed (literally rw copied to) in /usr or /usr/local without any difference. rw You do not really need *relocatable* libraries, right? You only rw do staged installs (by using DESTDIR), and all you ever move rw around is the staging area. The place where the library will find rw itself at the time it is used by ld.so is fixed from the very rw beginning, right? This is a significant simplification and rw required from libtool's point of view. rw Can we agree on this notion of relocation and staging? It corresponds rw to what the Autotools manuals use. I guess I'm talking about build-time relocatability, not runtime relocatability. The one thing that makes me wary of the term staged installs is that it implies to me (but maybe it's just me) that the install, while being made to a staging area, could be static. That is, you can stage it to a different place than the runtime location during the install, say with make install prefix=..., but once it's there it can't be moved. As long as it's understood that the requirement is that the staging area itself is fully independent and can be relocated (relocatable staging?) then I'm happy with the term staging. Cheers! -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Re: Relocatable libraries with libtool--can I do it?
%% Noah Misch [EMAIL PROTECTED] writes: nm Several individuals have communicated similar requirements here. nm Some had partial workarounds you may find useful; check the nm archives. OK, I'll see what I can find. nm Roughly. The .la does not need to encode the $ROOT, but libtool nm needs to know it when interpreting each .la on the build system. Interesting. nm I have a draft patch to do that. If I find some free time, I will nm finish it and post to libtool-patches. OK. I'll try to keep an eye out for it. Thanks! -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT--HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
Relocatable libraries with libtool--can I do it?
Hi all. I'm having a severe problem with libtool-ized packages, of which there are more and more these days, in my environment. I'm wondering if anyone here can suggest how I should proceed; whether there's something in libtool that will help me, or whether libtool needs enhancements, or what. My environment involves running in an x86 host running Linux, and cross-compiling everything for a different target. A few extra things about this are (a) that we do not use chroot or any similar technology, and (b) the entire thing needs to be completely relocatable at any time. You can probably already see where I'm going to have problems with libtool. One saving grace (for me) is that the target environment is also always running Linux (on PPC, or MIPS, or whatever) and I'm always using GCC. So, I know that I will always have a fully-featured compiler/linker/dynamic loader/etc. environment. My environment basically works like this: each environment is called an image. Each image consists of a complete filesystem hierarchy for a standard (stripped down) distribution for a given target. The physical root of this hierarchy (at build time) is no / of course; it's defined in the environment variable ROOT. So, I might have ROOT=/tmp/ppc-image, then I would have /tmp/ppc-image/bin, /tmp/ppc-image/usr/bin, /tmp/ppc-image/usr/include, /tmp/ppc-image/lib, etc. etc. But I need to be able to copy that entire image to another location, set ROOT to that location, and cross-compile code using that image in that new location. A final note is that while I need to move these images around at build time, at _RUNTIME_ they will always be installed where the root of the image is at /. So, runtime linker paths like /lib are correct and acceptable. For basic compilation we use a wrapper for the cross-compiler; the wrapper takes the options passed in and adds to the end other -L, -isystem, or whatever flags are needed for GCC to do the right thing based on the value of $ROOT. That works fine for normal, non-libtool configure packages; I can just use things like: export ROOT=/tmp/ppc-image ./configure --prefix=/usr CC=ppc-gcc CXX=ppc-g++ make make install DESTDIR=$ROOT This almost always works, these days. The problem is that libtool-generated libraries are not relocatable: for example the .la files have hardcoded paths in them and no way to reset them. That means that after I relocate the image, any package I compile that tries to use those .la files to get the proper environment will fail miserably. It seems like the right answer would be for the .la files to have knowledge of ROOT or DESTDIR, or some other variable like LIBTOOL_ROOT or something, and automatically prepend that value to the appropriate pathnames for finding libraries _AT BUILD TIME_, without impacting the paths set to find libraries _AT RUNTIME_. Does this seem correct? Or am I missing something else? -- --- Paul D. Smith [EMAIL PROTECTED] HASMAT: HA Software Mthds Tools Please remain calm...I may be mad, but I am a professional. --Mad Scientist --- These are my opinions---Nortel Networks takes no responsibility for them. ___ Libtool mailing list [EMAIL PROTECTED] http://lists.gnu.org/mailman/listinfo/libtool
