Re: should libtool --relink expand lib*.la files before -L options?

2008-06-12 Thread Ralf Wildenhues
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 of general remarks.

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.  That is done in order not to pick up paths to the build
tree (which would, on some systems, end up hardcoded in the resulting
binary).  Consequently, it needs to be ensured that make install
installs uninstalled libraries in the order of lowest-level first,
ones depending on those later.

Now, if the order in which those links are done on your command line
matters, then it looks to me like
- either that install order is not right,
- or there is some other library that links to libtag indirectly,
  IOW, some library dependency is not specified correctly in the link,
- or there is some completely independent library in that -L path
  that you'd like to appear early, that is needed but wasn't properly
  taken care of.

Does this help?

Cheers,
Ralf


___
http://lists.gnu.org/mailman/listinfo/libtool


Compiling into chroot

2008-06-12 Thread Alon Bar-Lev

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

2008-06-12 Thread Mark Wright
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?

2008-06-12 Thread Mark Wright
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 of general remarks.
 
 While 

Re: Compiling into chroot

2008-06-12 Thread Roumen Petrov

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

2008-06-12 Thread Alon Bar-Lev
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

2008-06-12 Thread Bob Friesenhahn

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

2008-06-12 Thread Roumen Petrov

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

2008-06-12 Thread Alon Bar-Lev
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

2008-06-12 Thread Richard Purdie

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

2008-06-12 Thread Alon Bar-Lev
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
snip
 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

2008-06-12 Thread Bob Friesenhahn

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

2008-06-12 Thread Bob Friesenhahn

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

2008-06-12 Thread Alon Bar-Lev
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

2008-06-12 Thread Bob Friesenhahn

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

2008-06-12 Thread Alon Bar-Lev
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

2008-06-12 Thread Bob Friesenhahn

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

2008-06-12 Thread Alon Bar-Lev
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

2008-06-12 Thread Bob Friesenhahn

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?

2008-06-12 Thread Ralf Wildenhues
* 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

2008-06-12 Thread Alon Bar-Lev
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

2008-06-12 Thread Bob Friesenhahn

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

2008-06-12 Thread Christopher Hulbert
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

2008-06-12 Thread Peter O'Gorman
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

2008-06-12 Thread Bob Friesenhahn

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] ifort:
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