headers
Thomas Koeller | 4 Nov 2007 13:48
Picon

cross-build problem

Hi,

I am encountering problems using libtool-1.5.24 in a cross-build
environment (build system x86_64-pc-linux-gnu, target mips-linux-gnu).
I am trying to build the Linux-PAM-0.99.8.1 package. Building works
fine, but --mode=install fails.

Because I am cross-building, my CFLAGS and LDFLAGS variables contain
the --sysroot switch. When 'libtool --mode=install' is invoked, the
following happens:

libtool: install: warning: relinking `libpam_misc.la'
(cd /home/thomas/excite-userland/build/Linux-PAM-0.99.8.1/libpam_misc; /bin/sh ../libtool 
--tag=CC --mode=relink /opt/cross-gcc/mips-linux-gnu/4.2.1/bin/mips-linux-gnu-gcc
-I/home/thomas/excite-userland/src/Linux-PAM-0.99.8.1/libpam/include
-I/home/thomas/excite-userland/src/Linux-PAM-0.99.8.1/libpamc/include
-I/home/thomas/excite-userland/src/Linux-PAM-0.99.8.1/libpam_misc/include -march=rm9000 -Os
-fomit-frame-pointer --sysroot=/home/thomas/excite-userland/sys-root -W -Wall
-Wbad-function-cast -Wcast-align -Wcast-qual -Wmissing-declarations -Wmissing-prototypes
-Wpointer-arith -Wreturn-type -Wstrict-prototypes -Wwrite-strings -Winline -Wshadow
--sysroot=/home/thomas/excite-userland/sys-root -Wl,--as-needed -Wl,-O1 -o libpam_misc.la
-rpath /usr/lib -no-undefined -version-info 81:2:81
-Wl,--version-script=/home/thomas/excite-userland/src/Linux-PAM-0.99.8.1/libpam_misc/libpam_misc.map
help_env.lo misc_conv.lo ../libpam/libpam.la -inst-prefix-dir /home/thomas/excite-userland/sys-root)
/opt/cross-gcc/mips-linux-gnu/4.2.1/bin/mips-linux-gnu-gcc -shared  .libs/help_env.o
.libs/misc_conv.o  -L/home/thomas/excite-userland/sys-root/usr/lib -L/usr/lib -lpam 
-march=rm9000 -Wl,--as-needed -Wl,-O1
-Wl,--version-script=/home/thomas/excite-userland/src/Linux-PAM-0.99.8.1/libpam_misc/libpam_misc.map
-Wl,-soname -Wl,libpam_misc.so.0 -o
.libs/libpam_misc.so.0.81.2
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ralf Wildenhues | 4 Nov 2007 14:04
Picon
Picon

Re: cross-build problem

Hello Thomas,

* Thomas Koeller wrote on Sun, Nov 04, 2007 at 01:48:43PM CET:
> 
> I am encountering problems using libtool-1.5.24 in a cross-build
> environment (build system x86_64-pc-linux-gnu, target mips-linux-gnu).
> I am trying to build the Linux-PAM-0.99.8.1 package. Building works
> fine, but --mode=install fails.
> 
> Because I am cross-building, my CFLAGS and LDFLAGS variables contain
> the --sysroot switch. When 'libtool --mode=install' is invoked, the
> following happens:

Instead of passing --sysroot, you can try passing -Wc,--sysroot=... to
get the flag through libtool.  It may work for you, but it will not
solve the more fundamental underlying issue:  Libtool does not recognize
that you are using a sysroot, and it will either search for dependent
installed libraries in the wrong locations or put the wrong (sysroot-
prefixed) deplib paths into the .la file that you are creating.

This is a limitation in libtool that has not been solved yet.  One way
to work around it is to use -Wc, as above, and afterwards rewrite
dependency_libs in the .la file you just created.

Note that this does not address the issue of indirect deplibs of
installed libraries below the sysroot: if they contain run paths
that will only be valid once the libs are in their final place,
things can still fail because the link editor won't find them.
(Shouldn't happen in your case as /usr/lib libraries typically
don't get run paths added.)
(Continue reading)

Permalink | Reply | 2 comments |
headers
Thomas Koeller | 4 Nov 2007 20:28
Picon

Re: cross-build problem

On Sonntag, 4. November 2007, Ralf Wildenhues wrote:
> Hello Thomas,

Hi Ralf,

thanks for your quick response. However, the explanation you gave does
not quite satisfy me.

>
> * Thomas Koeller wrote on Sun, Nov 04, 2007 at 01:48:43PM CET:
> > I am encountering problems using libtool-1.5.24 in a cross-build
> > environment (build system x86_64-pc-linux-gnu, target mips-linux-gnu).
> > I am trying to build the Linux-PAM-0.99.8.1 package. Building works
> > fine, but --mode=install fails.
> >
> > Because I am cross-building, my CFLAGS and LDFLAGS variables contain
> > the --sysroot switch. When 'libtool --mode=install' is invoked, the
> > following happens:
>
> Instead of passing --sysroot, you can try passing -Wc,--sysroot=... to
> get the flag through libtool.  It may work for you, but it will not
> solve the more fundamental underlying issue:  Libtool does not recognize
> that you are using a sysroot, and it will either search for dependent
> installed libraries in the wrong locations or put the wrong (sysroot-
> prefixed) deplib paths into the .la file that you are creating.

Why would libtool need to be aware of a sysroot being used? The linker
takes care of that. All that libtool is supposed to do is to pass my
LDFLAGS to the linker unmodified. It does so for all the 'libtool --mode=link'
commands executed during the build, and all these commands succeed. If
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ralf Wildenhues | 4 Nov 2007 22:16
Picon
Picon

Re: cross-build problem

* Thomas Koeller wrote on Sun, Nov 04, 2007 at 08:28:41PM CET:
> On Sonntag, 4. November 2007, Ralf Wildenhues wrote:
> > * Thomas Koeller wrote on Sun, Nov 04, 2007 at 01:48:43PM CET:
> > >
> > > Because I am cross-building, my CFLAGS and LDFLAGS variables contain
> > > the --sysroot switch. When 'libtool --mode=install' is invoked, the
> > > following happens:
> >
> > Instead of passing --sysroot, you can try passing -Wc,--sysroot=... to
> > get the flag through libtool.  It may work for you, but it will not
> > solve the more fundamental underlying issue:  Libtool does not recognize
> > that you are using a sysroot, and it will either search for dependent
> > installed libraries in the wrong locations or put the wrong (sysroot-
> > prefixed) deplib paths into the .la file that you are creating.
> 
> Why would libtool need to be aware of a sysroot being used?

Because it actually searches the search paths for dependent libraries.
It adds run path entried for deplibs that happen to be libtool libraries
but live in locations the runtime linker will not search by default.

Simply knowing whether /foo/usr/lib is such a location, or whether it is
a sysroot prefix of /foo plus a default-searched location /usr/lib,
cannot be known otherwise.  And with /foo/nonstandard/lib, it certainly
should not add a run path entry for /foo/nonstandard/lib instead of
/nonstandard/lib, because that path will not be valid once all libraries
live in their final location.

> The linker takes care of that.
(Continue reading)

Permalink | Reply | 0 comments |
headers
amit pansuria | 5 Nov 2007 11:49
Picon

got the libtool error when compiling application

Helo,
i m using RHEL 4 with kdevelope 3.1.1 and when i run aclocal i got the
following error

d '/root/cti' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f
Makefile.cvs
aclocal
aclocal:configure.in:8: warning: macro `AM_PROG_LIBTOOL' not found in library
autoheader
automake
autoconf
configure.in:8: error: possibly undefined macro: AM_PROG_LIBTOOL If
this token and others are legitimate, please use m4_pattern_allow. See
the Autoconf documentation.
gmake: *** [all] Error 1
*** Exited with status: 2 ***
Thanks and Regards,
Amit
Permalink | Reply | 1 comment |
headers
Ralf Wildenhues | 5 Nov 2007 18:09
Picon
Picon

Re: got the libtool error when compiling application

Hello Amit,

* amit pansuria wrote on Mon, Nov 05, 2007 at 11:49:24AM CET:
> i m using RHEL 4 with kdevelope 3.1.1 and when i run aclocal i got the
> following error
> 
> d '/root/cti' && WANT_AUTOCONF_2_5="1" WANT_AUTOMAKE_1_6="1" gmake -f
> Makefile.cvs
> aclocal
> aclocal:configure.in:8: warning: macro `AM_PROG_LIBTOOL' not found in library
[...]
> configure.in:8: error: possibly undefined macro: AM_PROG_LIBTOOL If
> this token and others are legitimate, please use m4_pattern_allow. See
> the Autoconf documentation.

You need both:
- run `libtoolize --copy' once, to get ltmain.sh.
- ensure aclocal finds the libtool macros.  They are in libtool.m4 and
  if needed ltdl.m4.  These files should either be part of your package,
  or installed in a location aclocal searches; typically, the latter is
  $prefix/share/aclocal, if $prefix is the --prefix where Automake was
  installed.  Most likely /usr/share/aclocal/.

Cheers,
Ralf
Permalink | Reply | 0 comments |
headers
Sergey Pribilskiy | 5 Nov 2007 21:51
Picon

bug-report

## --------- ##
## Platform. ##
## --------- ##

hostname = asp-serv
uname -m = i386
uname -r = 6.2-RELEASE
uname -s = FreeBSD
uname -v = FreeBSD 6.2-RELEASE #0: Fri Jan 12 10:40:27 UTC 2007     root <at> dessler
.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC

/usr/bin/uname -p = i386
/bin/uname -X     = unknown

/bin/arch              = unknown
/usr/bin/arch -k       = unknown
/usr/convex/getsysinfo = unknown
/usr/bin/hostinfo      = unknown
/bin/machine           = unknown
/usr/bin/oslevel       = unknown
/bin/universe          = unknown

PATH: /sbin
PATH: /bin
PATH: /usr/sbin
PATH: /usr/bin
PATH: /usr/games
PATH: /usr/local/sbin
PATH: /usr/local/bin
PATH: /usr/X11R6/bin
(Continue reading)

Permalink | Reply | 1 comment |
headers
Ralf Wildenhues | 5 Nov 2007 22:02
Picon
Picon

Re: bug-report

Hello Sergey,

* Sergey Pribilskiy wrote on Mon, Nov 05, 2007 at 09:51:33PM CET:
> 
[...]
> configure:2033: checking for a BSD-compatible install
> configure:2089: result: /usr/bin/install -c -o root -g wheel
> configure:2100: checking whether build environment is sane
> configure:2137: error: newly created file is older than distributed files!
> Check your system clock

You should do just that and set your system clock.
Then this error should disappear.

Cheers,
Ralf
Permalink | Reply | 0 comments |
headers
Ralf Wildenhues | 8 Nov 2007 21:05
Picon
Picon

New substitution: top_build_prefix

Hello Autoconf patchers,

We have hit another bug in HEAD Libtool, for which we could use help
from Autoconf.

This is the setting: a third-party package (GraphicsMagick) that uses
libltdl in nonrecursive mode in a nonrecursive Makefile[1].  In this
Makefile, the library is given as
  noinst_LTLIBRARIES = ltdl/libltdlc.la

however the dependency is given upon
  LIBLTDL = ${top_builddir}/ltdl/libltdl.la

and in this case, top_builddir is `.'.  LIBLTDL is computed as a
substitution of  <at> LIBLTDL <at>  at configure time.

Now, AIX make (and others) fail to identify `./file' with `file' so the
build fails.  It would be nice if Autoconf also substituted a variable
top_build_prefix that contained of zero or more runs of `../' and
otherwise behaved like top_builddir.  The naming is not coincidental:
config.status already computes this value, it just doesn't make it
available.

This would make writing these kinds of things much easier also in
Automake, which has lots of special-cases of the kind
  if ($directory ne '')
    {
      $object = $directory . '/' . $object;
    }
(Continue reading)

Permalink | Reply | 22 comments |
headers
Ralf Wildenhues | 8 Nov 2007 22:18
Picon
Picon

Re: New substitution: top_build_prefix

* Ralf Wildenhues wrote on Thu, Nov 08, 2007 at 09:05:24PM CET:
> 
>     New config files output variable `top_build_prefix'.
>     
>     * lib/autoconf/status.m4 (_AC_OUTPUT_FILE): Substitute
>     `top_build_prefix'.
>     * doc/autoconf.texi (Preset Output Variables): Document it.
>     * NEWS: Update.
>     Report by Bob Friesenhahn.

BTW, this was meant as "OK to apply?".

Cheers,
Ralf
Permalink | Reply | 2 comments |

Gmane