that you never
test proper DESTDIR support though.
I don't think that compiling into chroot is the right subject.
As I understand host system is accessible in build system under a prefix
path_to_host_system. I don't think that only libtool is affected.
During configure time autoconf macros has
On Sat, Jun 14, 2008 at 9:59 AM, Alon Bar-Lev [EMAIL PROTECTED] wrote:
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
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
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,
* Alon Bar-Lev wrote on Sat, Jun 14, 2008 at 09:59:06AM CEST:
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
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
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
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
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.
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
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
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
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
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
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
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
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
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
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
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
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
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
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
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
24 matches
Mail list logo
