Compiling into chroot
Hello, I looked at recent libtool-2 versions and could still not find a solution to compile into chroot. I want to create an image to embedded device using a cross compiler. So I do: mkdir /tmp/device-root cd /package1 ./configure --host=<> --prefix=/usr make install DESTDIR=/tmp/device-root cd /package2 ./configure --host=<> --prefix=/usr make install DESTDIR=/tmp/device-root But package2 cannot find libraries as the .la files constains pathes to /usr/lib and not /tmp/device-root/usr/lib. Is there any way to make libtool search the /tmp/device-root prefix, and behave correctly? I am thinking like an environment variable so that packages will not be effected. Thanks, Alon Bar-Lev. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
Hello Alon, Maybe setting LDFLAGS something like one of the following might help (I am not sure which one you really want): export LDFLAGS="-L/tmp/device-root/usr/lib -L/usr/lib" export LDFLAGS="-L/tmp/device-root/usr/lib" export LDFLAGS="-L/tmp/device-root/usr/lib -L/usr/lib -R/tmp/device-root/usr/lib -R/usr/lib" export LDFLAGS="-L/tmp/device-root/usr/lib -R/tmp/device-root/usr/lib" With gnu ld -rpath is used instead of -R , if you need to set the runpath as well. Regards, Mark On Thu, 12 Jun 2008 16:53:43 +0300 Alon Bar-Lev <[EMAIL PROTECTED]> wrote: > > Hello, > > I looked at recent libtool-2 versions and could still not find a > solution to compile into chroot. > > I want to create an image to embedded device using a cross compiler. > > So I do: > mkdir /tmp/device-root > cd /package1 > ./configure --host=<> --prefix=/usr > make install DESTDIR=/tmp/device-root > cd /package2 > ./configure --host=<> --prefix=/usr > make install DESTDIR=/tmp/device-root > > But package2 cannot find libraries as the .la files constains pathes > to /usr/lib and not /tmp/device-root/usr/lib. > > Is there any way to make libtool search the /tmp/device-root prefix, > and behave correctly? I am thinking like an environment variable so > that packages will not be effected. > > Thanks, > Alon Bar-Lev. > > > ___ > http://lists.gnu.org/mailman/listinfo/libtool -- ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: should libtool --relink expand lib*.la files before -L options?
Hello Ralf, Yes that helps, thanks. Since it seemed hard to explain and understand with the large program, I wrote a test case, which I have attached, which reproduces the problem when run on Solaris with an environment setup to use Sun Studio C++, with enviroment variables like: CXXCPP=/opt/SunStudio12/SUNWspro/bin/CC -E -Xs CPP=/opt/SunStudio12/SUNWspro/bin/cc -E -Xs CXX=/opt/SunStudio12/SUNWspro/bin/CC CC=/opt/SunStudio12/SUNWspro/bin/cc to tell autotools to use the Sun Studio C++ compiler. Unfortunately the testcase does not reproduce the problem when I try it with gcc 4.2.3 using the GNU linker. One reason why it was a little difficult to reproduce is the default behaviour when linking a shared library against another shared library is to allow Unresolved symbols. The problem of linking against the wrong library is only seen in the testcase when the linker issues errors for Unresolved symbols while linking the libtag_c.so shared library, to get that behaviour, I set: libtag_c_la_LDFLAGS = -no-undefined in current/bindings/c/Makefile.am To unpack the testcase in the current directory: bzip2 -d libtool_pkg_sys.tar.bz2 tar xf libtool_pkg_sys.tar to run it: ksh -kx test_libtool_pkg_sys.ksh So what it tries to show is: (1) A old library is compiled and installed in $PWD/usr/lib. (2) A new library is compiled and installed in a package staging directory $PWD/pkgbuild/opt/foss/lib. During the compile of the new library, LDFLAGS is set to include libraries in: $PWD/opt/foss/lib, which is like the /opt/foss/lib directory where the KDE4 packages would be installed in the real system, but in the test, this directory is empty. $PWD/usr/lib, which is the test case analog of /usr/lib. So the problem I am trying to show, if it occurs, is that since LDFLAGS needs to include: -L$PWD/opt/foss/lib -L$PWD/usr/lib and an old version of the library was installed in step (1) in -L$PWD/usr/lib, then when the new version of the library is linked, the linker first finds the old library in L$PWD/usr/lib because: (a) Its in LDFLAGS, it needs to be. Or in any case, in the real system the old library is in /usr/lib and the linker looks in there anyway. *AND* (2) libtool 2.2.4 placed the -L$PWD/pkgbuild/opt/foss/lib after the LDFLAGS directories during the relink, here is the output when I run the testcase on my Solaris 10 box with Sun Studio 12: ... libtool: install: warning: relinking `libtag_c.la' libtool: install: (cd /h/goanna/2/eng/dev/autotools/t/current/bindings/c; /bin/bash /h/goanna/2/eng/dev/autotools/t/current/libtool --tag CXX --mode=relink /opt/SunStudio12/SUNWspro/bin/CC -g -no-undefined -L/h/goanna/2/eng/dev/autotools/t/opt/foss/lib -L/h/goanna/2/eng/dev/autotools/t/usr/lib -R/h/goanna/2/eng/dev/autotools/t/opt/foss/lib -R/h/goanna/2/eng/dev/autotools/t/usr/lib -o libtag_c.la -rpath /h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib call_a.lo call_b.lo ../../taglib/libtag.la ) libtool: relink: /opt/SunStudio12/SUNWspro/bin/CC -G -zdefs -hlibtag_c.so.0 -o .libs/libtag_c.so.0.0.0 .libs/call_a.o .libs/call_b.o -R/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib -R/h/goanna/2/eng/dev/autotools/t/opt/foss/lib -R/h/goanna/2/eng/dev/autotools/t/usr/lib -L/h/goanna/2/eng/dev/autotools/t/opt/foss/lib -L/h/goanna/2/eng/dev/autotools/t/usr/lib -L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib -ltag -library=Cstd -library=Crun -lc Undefined first referenced symbol in file int B::func_b() .libs/call_b.o ld: fatal: Symbol referencing errors. No output written to .libs/libtag_c.so.0.0.0 libtool: install: error: relink `libtag_c.la' with the above command before installing it make[3]: *** [install-libLTLIBRARIES] Error 1 make[3]: Leaving directory `/h/goanna/2/eng/dev/autotools/t/current/bindings/c' make[2]: *** [install-am] Error 2 make[2]: Leaving directory `/h/goanna/2/eng/dev/autotools/t/current/bindings/c' make[1]: *** [install-recursive] Error 1 make[1]: Leaving directory `/h/goanna/2/eng/dev/autotools/t/current/bindings' make: *** [install-recursive] Error 1 + cd .. goanna% On Thu, 12 Jun 2008 08:07:16 +0200 Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > Hello Mark, > > * Mark Wright wrote on Wed, Jun 11, 2008 at 04:17:11PM CEST: > > > > In the libtool 2.2.4 relink command below, > > the ../../taglib/libtag.la refers to a libtag.so library in the > > build directory. I'm, sorry about the zillion compiler options, > > however I think only the -L options, the ../../taglib/libtag.la and > > its corresponding > > -L/var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib > > -ltag options are relevant. > > > > My hopefully simple question is: is there some way to persuade > > libtool/autotools to look for the libtag.so shared library first in > > /var/tmp/pkgbuild-mwright/FOSStaglib-1.5.0-build/opt/foss/lib/libtag.so.1.5.0? > > I'm not sure I've understood this bug report completely, so I will > give a couple
Re: Compiling into chroot
Alon Bar-Lev wrote: Hello, I looked at recent libtool-2 versions and could still not find a solution to compile into chroot. I want to create an image to embedded device using a cross compiler. So I do: mkdir /tmp/device-root cd /package1 ./configure --host=<> --prefix=/usr make install DESTDIR=/tmp/device-root cd /package2 ./configure --host=<> --prefix=/usr make install DESTDIR=/tmp/device-root But package2 cannot find libraries as the .la files constains pathes to /usr/lib and not /tmp/device-root/usr/lib. Is there any way to make libtool search the /tmp/device-root prefix, and behave correctly? I am thinking like an environment variable so that packages will not be effected. Thanks, Alon Bar-Lev. Hmm. What is related to chroot ? Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: > Hmm. What is related to chroot ? After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Thu, 12 Jun 2008, Alon Bar-Lev wrote: After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Why not just add a /tmp/device-root symbolic link to '/' in your chrooted space? Then everything will be happy. The alternative is to use a script to update all of the installed .la files to use the new paths. This is not libtool's problem. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
Bob Friesenhahn wrote: On Thu, 12 Jun 2008, Alon Bar-Lev wrote: After installing I want to perform: chroot /tmp/device-root /bin/whatever And continue from there. So all elements (linkage, .la) should be related to the chroot and not to host filesystem. Why not just add a /tmp/device-root symbolic link to '/' in your chrooted space? Then everything will be happy. The alternative is to use a script to update all of the installed .la files to use the new paths. This is not libtool's problem. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ It look like an enhancement request. libtool to obey as example FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1 , ... and $FAKEROOT/pathN and later in /path1,... and /pathN . Roumen ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: > It look like an enhancement request. libtool to obey as example > FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1 > , ... and $FAKEROOT/pathN and later in /path1,... and /pathN . This what I had in mind. It also should append the FAKEROOT to pathes read from .la files. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Thu, 2008-06-12 at 22:03 +0300, Alon Bar-Lev wrote: > On 6/12/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: > > It look like an enhancement request. libtool to obey as example > > FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1 > > , ... and $FAKEROOT/pathN and later in /path1,... and /pathN . > > This what I had in mind. > It also should append the FAKEROOT to pathes read from .la files. You mean prepend :) This is the same issue as the sysroot one I've previously mentioned. OpenEmbedded currently hacks the .la files in its staging area to include the sysroot prefix but this means you can't use staging as a chroot. I've not had time to look into doing anything about this feature but I would love to see it! Cheers, Richard ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Thu, 12 Jun 2008, Alon Bar-Lev wrote: > > > > > After installing I want to perform: > > chroot /tmp/device-root /bin/whatever > > > > And continue from there. > > So all elements (linkage, .la) should be related to the chroot and not > > to host filesystem. > > > > Why not just add a /tmp/device-root symbolic link to '/' in your chrooted > space? Then everything will be happy. > > The alternative is to use a script to update all of the installed .la files > to use the new paths. > > This is not libtool's problem. Sure it is libtool's problem! Changing the .la after each package is not enough. If there is embedded configure within configure, or if it is part of package management, it cannot be simply done. Also I am getting: ~/my/Development/opensc/windows/trunk/image $ i586-pc-linux-uclibc-readelf --dynamic root1/lib/libopensc.so Dynamic section at offset 0x7be90 contains 27 entries: TagType Name/Value 0x000f (RPATH) Library rpath: [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x001d (RUNPATH)Library runpath: [/home/alonbl/my/Development/opensc/windows/trunk/image/opensc/lib://lib] 0x000c (INIT) 0x6610 Notice the two pathes. Maybe I am doing something wrong, you can review the script at [1]. It should build all OpenSC packages for initramfs and Windows. Currently libtool is the only tool making the problems, I need to keep modifying the .la files over and over, and then restore them. And I still get the full path of the host system within the libraries and executables, this is unexpected side result of clean chroot. Alon. [1] http://www.opensc-project.org/windows/browser/trunk/build ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Thu, 12 Jun 2008, Richard Purdie wrote: On Thu, 2008-06-12 at 22:03 +0300, Alon Bar-Lev wrote: On 6/12/08, Roumen Petrov <[EMAIL PROTECTED]> wrote: It look like an enhancement request. libtool to obey as example FAKEROOT=/tmp/device-root and to look first in $FAKEROOT/path1 , ... and $FAKEROOT/pathN and later in /path1,... and /pathN . This what I had in mind. It also should append the FAKEROOT to pathes read from .la files. You mean prepend :) This is the same issue as the sysroot one I've previously mentioned. OpenEmbedded currently hacks the .la files in its staging area to include the sysroot prefix but this means you can't use staging as a chroot. I've not had time to look into doing anything about this feature but I would love to see it! There are three ways of looking at this issue. One is to prepare the files differently so that they "just work" in the chroot environment (requires the FAKEROOT when files are prepared). The second way is to do something special so that already prepared files "still work" in the chroot environment (requires the FAKEROOT when files are used under chroot). The third way is to edit/update the .la files so that they work in the new root. The first and second ways seem to cause runtime overhead for all libtool users and are not completely portable since build tools may embed paths to source files, object files, or libraries in the built objects and libraries. There is quite a bit to keep track of so new bugs may be added. The third way is similar to the first way except that it requires an extra step from the user. As it turns out, libtool already supports a "last step" (--mode=finish) which could be used to fix up any paths as well as do any platform-specific actions. Libtool would have to know that paths need to be corrected. This would need to be executed from within the chroot environment. The path correction could be computed based on the difference between the current path and the path in the .la file. It may be that some existing platform-specific actions (e.g. ranlib, ldconfig) might fail in the chroot environment since the user has not made it complete enough. Since the libtool project is a volunteer project, it does not "take requests" unless a maintainer volunteers to do the work. The best path forward is for a interested volunteer to perform the necessary edits, prove that they work, and submit a patch. There is the risk that it will be decided that the changes are too invasive or too risky and the patch might not be accepted. The FAKEROOT proposal sounds similar to DESTDIR (implemented in Automake) except that it may require many changes in libtool vs very little required change for DESTDIR. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Thu, 12 Jun 2008, Alon Bar-Lev wrote: Currently libtool is the only tool making the problems, I need to keep modifying the .la files over and over, and then restore them. And I still get the full path of the host system within the libraries and executables, this is unexpected side result of clean chroot. Libtool is only causing problems because you dramatically altered the build environment. Once libtool is adjusted you may find that some other build tool is to blame for the next problem. Other build tools often insert full paths into built objects and libraries (without being directed to by libtool). The best path forward is that if you feel strongly enough about this, then prepare a patch for libtool which works for you. 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. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > There are three ways of looking at this issue. One is to prepare the files > differently so that they "just work" in the chroot environment (requires the > FAKEROOT when files are prepared). The second way is to do something > special so that already prepared files "still work" in the chroot > environment (requires the FAKEROOT when files are used under chroot). The > third way is to edit/update the .la files so that they work in the new root. > > The first and second ways seem to cause runtime overhead for all libtool > users and are not completely portable since build tools may embed paths to > source files, object files, or libraries in the built objects and libraries. > There is quite a bit to keep track of so new bugs may be added. Because of this configure --prefix=/ is used, so embedded paths will be relative to root and not directory in host system. So the only issue is with libtool. > The third way is similar to the first way except that it requires an extra > step from the user. As it turns out, libtool already supports a "last step" > (--mode=finish) which could be used to fix up any paths as well as do any > platform-specific actions. Libtool would have to know that paths need to be > corrected. This would need to be executed from within the chroot > environment. The path correction could be computed based on the difference > between the current path and the path in the .la file. It may be that some > existing platform-specific actions (e.g. ranlib, ldconfig) might fail in the > chroot environment since the user has not made it complete enough. > > Since the libtool project is a volunteer project, it does not "take > requests" unless a maintainer volunteers to do the work. The best path > forward is for a interested volunteer to perform the necessary edits, prove > that they work, and submit a patch. There is the risk that it will be > decided that the changes are too invasive or too risky and the patch might > not be accepted. We all volunteers... and before we do work for a project, we need to know that it is not for nothing. But usually project maintainers can do these stuff in less effort and better quality. > The FAKEROOT proposal sounds similar to DESTDIR (implemented in Automake) > except that it may require many changes in libtool vs very little required > change for DESTDIR. This is the simplest, as execution of commands within the chroot is impossible. As it may be cross compile and target is not operational. As far as I understand, you can add FAKEROOT into each path variable read from .la files, and removed before writing the .la files. Also removed from all operations during the finish stage. But as libtool script is so complex it is very difficult to provide a solution to outsiders. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Thu, 12 Jun 2008, Alon Bar-Lev wrote: Because of this configure --prefix=/ is used, so embedded paths will be relative to root and not directory in host system. So the only issue is with libtool. Libtool is not aware of --prefix! It only knows the paths given to it and what it learns from its environment. This is the simplest, as execution of commands within the chroot is impossible. As it may be cross compile and target is not operational. Commands may be executed if the chroot environment is sufficiently updated to make it possible. As far as I understand, you can add FAKEROOT into each path variable read from .la files, and removed before writing the .la files. Also removed from all operations during the finish stage. How does this mesh with libltdl (which also reads .la files) and test suites? It seems that libltdl would also need to know about FAKEROOT, which results in every application using libltdl responding to FAKEROOT. There may be additional security issues here similar to LD_LIBRARY_PATH, but worse since the compromised application could setenv FAKEROOT before a module is loaded and cause a compromised module/library to be loaded. But as libtool script is so complex it is very difficult to provide a solution to outsiders. A well kept secret is that the libtool maintainers also consider the libtool script to be quite complex. :-) Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > On Thu, 12 Jun 2008, Alon Bar-Lev wrote: > > > > > Because of this configure --prefix=/ is used, so embedded paths will > > be relative to root and not directory in host system. > > So the only issue is with libtool. > > > > Libtool is not aware of --prefix! It only knows the paths given to it and > what it learns from its environment. Because of this we recommend an environment variable. So that it can substract it from the path to determine the path on the chroot. > > This is the simplest, as execution of commands within the chroot is > > impossible. As it may be cross compile and target is not operational. > > > > Commands may be executed if the chroot environment is sufficiently updated > to make it possible. How? If this is for different CPU? I have the same issue with cross compile to mips, I compile initramfs. Do you mean that you need a libtool something to run on my embedded initramfs to fix up the mess at runtime? > > As far as I understand, you can add FAKEROOT into each path variable > > read from .la files, and removed before writing the .la files. Also > > removed from all operations during the finish stage. > > > > How does this mesh with libltdl (which also reads .la files) and test > suites? It seems that libltdl would also need to know about FAKEROOT, which > results in every application using libltdl responding to FAKEROOT. There > may be additional security issues here similar to LD_LIBRARY_PATH, but worse > since the compromised application could setenv FAKEROOT before a module is > loaded and cause a compromised module/library to be loaded. I don't understand! If all pathes within the .la files are relative to the FAKEROOT, the libltdl which runs within the chroot environment will find the files exactly where .la files reference to. All the work should be done so that within the chroot environment all files will be as if they were compiled within it. > > But as libtool script is so complex it is very difficult to provide a > > solution to outsiders. > > > > A well kept secret is that the libtool maintainers also consider the > libtool script to be quite complex. :-) > I figured this out... Even libtool-2 with all its cleanups is very complex. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Thu, 12 Jun 2008, Alon Bar-Lev wrote: This is the simplest, as execution of commands within the chroot is impossible. As it may be cross compile and target is not operational. Commands may be executed if the chroot environment is sufficiently updated to make it possible. How? If this is for different CPU? I have the same issue with cross compile to mips, I compile initramfs. Do you mean that you need a libtool something to run on my embedded initramfs to fix up the mess at runtime? Cross-compile is a special case. I can see that you would need to run libtool's fix-up script using the native OS and CPU. That means my suggestion to compute the fixed paths automatically would not work for cross-compile. How does this mesh with libltdl (which also reads .la files) and test suites? It seems that libltdl would also need to know about FAKEROOT, which results in every application using libltdl responding to FAKEROOT. There may be additional security issues here similar to LD_LIBRARY_PATH, but worse since the compromised application could setenv FAKEROOT before a module is loaded and cause a compromised module/library to be loaded. I don't understand! If all pathes within the .la files are relative to the FAKEROOT, the libltdl which runs within the chroot environment will find the files exactly where .la files reference to. All the work should be done so that within the chroot environment all files will be as if they were compiled within it. The libltdl code doesn't know if it is executed in a chrooted environment. The FAKEROOT option can be used for purposes other than cross-compile so it can be expected that if the build is not a cross-compile then libltdl needs to be able to work (to support testing), and therefore needs to respect FAKEROOT. Besides cross compile, a use of a chrooted environment is to detect use of files which are not currently resident in that environment. It is a poor-man's way to decide if the build is likely to work on someone else's machine without testing on another machine. DESTDIR users may also have a desire to "fix up" the .la files but without desire for the FAKEROOT features. It seems that there are many descriptions of this elephant. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/12/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > The libltdl code doesn't know if it is executed in a chrooted environment. > The FAKEROOT option can be used for purposes other than cross-compile so it > can be expected that if the build is not a cross-compile then libltdl needs > to be able to work (to support testing), and therefore needs to respect > FAKEROOT. If you prepare chroot environment, you don't expect it to work without chroot into it first! You cannot eliminate a cross-compile solution only because you cannot test it on build machine. All tools work great in doing cross compile (including libtool), the only missing functionality is for libtool to create valid chroot environment. > Besides cross compile, a use of a chrooted environment is to detect use of > files which are not currently resident in that environment. It is a > poor-man's way to decide if the build is likely to work on someone else's > machine without testing on another machine. Which file is missing? I don't follow you. > DESTDIR users may also have a desire to "fix up" the .la files but without > desire for the FAKEROOT features. No... DESTDIR just tells to install into other location, without any change or fixup. > It seems that there are many descriptions of this elephant. I think you going to differnet place than creating a valid environment for chroot. Thanks, Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Fri, 13 Jun 2008, Alon Bar-Lev wrote: Besides cross compile, a use of a chrooted environment is to detect use of files which are not currently resident in that environment. It is a poor-man's way to decide if the build is likely to work on someone else's machine without testing on another machine. Which file is missing? I don't follow you. Any file. :-) Another common use of chroot installs is to create a small OS-root environment with all of the libraries and files that the package is expected to need (could be a base Linux install). Then the package is installed under the chrooted environment and tested. The package should be able to run without saying that it can't find libYYY.so or fileXXX. It seems that there are many descriptions of this elephant. I think you going to differnet place than creating a valid environment for chroot. That is true, but if more valid uses are identified for the feature then perhaps there will be more incentive to develop it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: should libtool --relink expand lib*.la files before -L options?
* Mark Wright wrote on Thu, Jun 12, 2008 at 06:06:58PM CEST: > Ralf Wildenhues <[EMAIL PROTECTED]> wrote: > > While link mode will try to use the uninstalled libraries throughout > > (so you don't pick up an old, previously installed one), relink mode > > will try to use the installed versions of the other just-built > > libraries. > > Yes it does, however it finds an old library in LDFLAGS before the > installed one in: > > -L/h/goanna/2/eng/dev/autotools/t/pkgbuild/opt/foss/lib That's the sort of conflict that is just impossible to resolve. For your specific case, the path to the newly installed library should go early, for other users it shouldn't (because they have other, unrelated libraries in both the newly installed path and some other path listed early). Sorry, you can't have that sort of flexibility portably. If you need other libraries from that path where the old, unwanted one lives, make symlinks to them in some new directory. Generally, if you want to have several versions of some library at the same time, put them in distinct $prefix'es, apart from other libraries. That helps to minimize such conflicts. Cheers, Ralf ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On 6/13/08, Bob Friesenhahn <[EMAIL PROTECTED]> wrote: > Any file. :-) > > Another common use of chroot installs is to create a small OS-root > environment with all of the libraries and files that the package is expected > to need (could be a base Linux install). Then the package is installed > under the chrooted environment and tested. The package should be able to > run without saying that it can't find libYYY.so or fileXXX. You compile the libc and also install it to the same place. I don't think that it is libtool job to find dependencies and place them within. I use a simple script that examine dependencies within the chroot and copy libraries from cross compile environment into the chroot location. So I don't think this is the feature that is missing. The major issue is to make sure that files installed by libtool into the chroot will be valid after chroot given all dependencies are available. > > > It seems that there are many descriptions of this elephant. > > > > > > > I think you going to differnet place than creating a valid environment > > for chroot. > > > > That is true, but if more valid uses are identified for the feature then > perhaps there will be more incentive to develop it. Oh... OK. As long as we understand this use case, I am happy. Alon. ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: Compiling into chroot
On Fri, 13 Jun 2008, Alon Bar-Lev wrote: So I don't think this is the feature that is missing. The major issue is to make sure that files installed by libtool into the chroot will be valid after chroot given all dependencies are available. So DESTDIR is already sufficient for this case. Got it. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
shared libraries on darwin using Intel compiler
In libtool 2.2.2, building shared libraries using Intel fortran compilers seem to be disabled (although the icc compiler appears to say yes). Thus, mixed language shared libraries or purely fortran shared libraries can't be built. I have the intel 10.1 compilers. As a quick way to get shared libraries working, I hacked the _LT_LINKER_SHLIBS function for the darwin case to what's below, but I'm sure there's a better way of doing this. What would be the more preferable way of adding support for shared libraries using Intel fortran compiler? I'm not sure why it works for icc but not ifort. Using the hack below I can successfully link with the fortran linker and build the shared library. Chris darwin* | rhapsody*) - _LT_DARWIN_LINKER_FEATURES($1) + case $cc_basename in +icc* | ifort*) + GCC_save=$GCC + GCC=yes + _LT_DARWIN_LINKER_FEATURES($1) + GCC=$GCC_save + ;; +*) + _LT_DARWIN_LINKER_FEATURES($1) + ;; + esac ;; ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared libraries on darwin using Intel compiler
Christopher Hulbert wrote: > In libtool 2.2.2, building shared libraries using Intel fortran > compilers seem to be disabled (although the icc compiler appears to > say yes). Thus, mixed language shared libraries or purely fortran > shared libraries can't be built. I have the intel 10.1 compilers. As a > quick way to get shared libraries working, I hacked the > _LT_LINKER_SHLIBS function for the darwin case to what's below, but > I'm sure there's a better way of doing this. What would be the more > preferable way of adding support for shared libraries using Intel > fortran compiler? I'm not sure why it works for icc but not ifort. > Using the hack below I can successfully link with the fortran linker > and build the shared library. Hi Chris, I will look at this, but to answer your question about why icc works - it defines __GNUC__ and behaves almost exactly the same as gcc (I believe it calls gcc to do its linking), so the existing commands for gcc work fine with icc. I am unsure why they do not work with ifort, I would have thought that would similarly define __GNUC__. Could you please send me a config.log from a libtool using package (or from libtool itself) without this patch applied. Thanks, Peter -- Peter O'Gorman http://pogma.com ___ http://lists.gnu.org/mailman/listinfo/libtool
Re: shared libraries on darwin using Intel compiler
On Thu, 12 Jun 2008, Christopher Hulbert wrote: In libtool 2.2.2, building shared libraries using Intel fortran compilers seem to be disabled (although the icc compiler appears to say yes). Thus, mixed language shared libraries or purely fortran I suspect that this is already fixed for the next release (fix already in GIT): 2008-05-25 Ralf Wildenhues <[EMAIL PROTECTED]> Fix ifort settings again. * libltdl/m4/libtool.m4 (_LT_COMPILER_PIC) [linux] : Unlike icc and ecc, not all ifort versions understand `-KPIC', e.g. version 10.1, so use `-fPIC' instead. Report by Jeff Squyres. Bob == Bob Friesenhahn [EMAIL PROTECTED], http://www.simplesystems.org/users/bfriesen/ GraphicsMagick Maintainer,http://www.GraphicsMagick.org/ ___ http://lists.gnu.org/mailman/listinfo/libtool
