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
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
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:
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
* 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
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
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
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
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
25 matches
Mail list logo
