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
c
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/
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/Sun
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 DESTD
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 yo
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 sy
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
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,.
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
> > t
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 $FAK
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 c
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 t
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
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 a
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
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 ab
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
* 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 t
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
>
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 i
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 librar
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.
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 nex
24 matches
Mail list logo
