bug-libtool
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: libtool 2.4 sysroot problem


From: Lionel Landwerlin
Subject: Re: libtool 2.4 sysroot problem
Date: Tue, 28 Sep 2010 01:43:05 +0200

Le lundi 27 septembre 2010 à 19:28 +0200, Ralf Wildenhues a écrit :
> Hello Lionel,
> 
> * Lionel Landwerlin wrote on Sun, Sep 26, 2010 at 11:49:12PM CEST:
> > I'm trying to integrate libtool 2.4 in buildroot. Before libtool
> > supports systsroot, I use to patch it with the following patch :
> > 
> > http://xms/cgi-bin/cgit.cgi/buildroot/tree/package/libtool/libtool-2.2.6b_cross-environment-support.patch?h=new-libtool-at-work

Oh... My mistake, here is the right url :

http://git.potipota.net/cgi-bin/cgit.cgi/buildroot/tree/package/libtool/libtool-2.2.6b_cross-environment-support.patch?h=new-libtool-at-work

> 
> This link does not work, xms isn't a valid host.  It would be good to be
> able to see what the patch did.
> 
> > It used to work fine, and I wanted to give a try on libtool 2.4 to get
> > rid of this patch. Unfortunately it seems there is a problem with
> > libtool 2.4.
> > 
> > First of all, I want to precise that I'm not patching libtool 2.4 in any
> > way. I'm running autoreconf on all packages I compile, and I'm also
> > adding the --with-sysroot option to run the configure script.
> > 
> > This is my setup :
> >         - uclibc 0.31
> >         - libiconv 0.13.1
> >         - gettext 0.18.1.1
> >         - glib 2.24.1
> > 
> > I'm successfully compiling the first 3 packages, but at the end of the
> > gettext's installation step, the content of the libintl.la file (from
> > $(STAGING_DIR)/usr/lib/libintl.la is as follow :
> 
> Please show exactly how you are configuring, building, and installing
> each of these packages.

Please find here :

http://potipota.net/~djdeath/buildroot/

the logs of the builds, you will see the
autoreconf/configure/build/install steps of gettext and then libglib.

There is 2 run of build, one with --with-sysroot= option passed to the
configure scripts, the other one without.

Also, if you want to reproduce by yourself, you might want to clone the
new-libtool-2.4 branch from git://git.potipota.net/buildroot . The
config file to run buildroot is attached.

$ git clone git://git.potipota.net/buildroot
$ cd buildroot
$ mkdir output
$ cp config_file_attached output/.config
$ make

And wait :)

> 
> > The '=/usr/lib/libiconv.la' is unusual to me, even if I know understand
> > that = might be interpreted by the gcc compiler as the path to sysroot.
> 
> Almost: it should be interpreted by the libtool script.

Ok, Thanks.

> 
> > Then, when glib gets compiled, it fails with the following error :
> > 
> > libtool: link: 
> > /home/djdeath/src/buildroot/buildroot_rebase/int-pc/staging/usr/bin/i686-unknown-linux-uclibc-ar
> >  cru .libs/libglib-2.0.a  garray.o gasyncqueue.o gatomic-gcc.o gbacktrace.o 
> > gbase64.o gbitlock.o gbookmarkfile.o gbuffer.o gcache.o gchecksum.o 
> > gcompletion.o gconvert.o gdataset.o gdate.o gdir.o gerror.o gfileutils.o 
> > ghash.o ghook.o ghostutils.o giochannel.o gkeyfile.o glist.o gmain.o 
> > gmappedfile.o gmarkup.o gmem.o gmessages.o gnode.o goption.o gpattern.o 
> > gpoll.o gprimes.o gqsort.o gqueue.o grel.o grand.o gregex.o gscanner.o 
> > gsequence.o gshell.o gslice.o gslist.o gstdio.o gstrfuncs.o gstring.o 
> > gtestutils.o gthread.o gthreadpool.o gtimer.o gtree.o guniprop.o gutf8.o 
> > gunibreak.o gunicollate.o gunidecomp.o gurifuncs.o gutils.o gvariant.o 
> > gvariant-core.o gvariant-parser.o gvariant-serialiser.o gvarianttypeinfo.o 
> > gvarianttype.o gprintf.o giounix.o gspawn.o  
> > .libs/libglib-2.0.lax/libcharset.a/localcharset.o  
> > .libs/libglib-2.0.lax/libgnulib.a/asnprintf.o 
> > .libs/libglib-2.0.lax/libgnulib.a/printf-args.o 
> > .libs/libglib-2.0.lax/libgnulib.a/printf-parse.o 
> > .libs/libglib-2.0.lax/libgnulib.a/printf.o 
> > .libs/libglib-2.0.lax/libgnulib.a/vasnprintf.o  
> > .libs/libglib-2.0.lax/libpcre.a/pcre_chartables.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_compile.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_config.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_dfa_exec.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_exec.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_fullinfo.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_get.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_globals.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_info.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_maketables.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_newline.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_ord2utf8.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_refcount.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_study.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_tables.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_try_flipped.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_ucp_searchfuncs.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_valid_utf8.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_version.o 
> > .libs/libglib-2.0.lax/libpcre.a/pcre_xclass.o 
> > libtool: link: 
> > /home/djdeath/src/buildroot/buildroot_rebase/int-pc/staging/usr/bin/i686-unknown-linux-uclibc-ranlib
> >  .libs/libglib-2.0.a
> > libtool: link: rm -fr .libs/libglib-2.0.lax
> > /bin/sed: can't read =/usr/lib/libiconv.la: No such file or directory
> > libtool: link: `=/usr/lib/libiconv.la' is not a valid libtool archive
> > make[5]: *** [libglib-2.0.la] Erreur 1
> > make[5]: quittant le répertoire « 
> > /home/djdeath/src/buildroot/buildroot_rebase/int-pc/build/libglib2-2.24.1/glib
> >  »
> 
> You cut off the log a bit too much.  I'd like to see a handful of lines
> before the first one you quote.  Thanks.
> 
> > I might have done something wrong in my setup, but otherwise, it looks
> > like a libtool problem to me. It seems to be located in the
> > func_mode_install function. The following script line does seems good to
> > me :
> > 
> > " ${lt_sysroot:+=}$libdir/$name"
> > 
> > I tried to replace it with :
> > 
> > " $libdir/$name"
> > 
> > to generate a "correct" (to me) libintl.la file, but then the
> > compilation fails by trying to read with /usr/lib/libintl.la (which does
> > not exist on my system). It would have succeeded if the path had been
> > $(STAGING_DIR)/usr/lib/libintl.la.
> > 
> > Let me know if you have an idea on how to fix that problem. I can give
> > more information about the problem, and/or an environment to reproduce
> > the problem (based on buildroot).
> 
> Might be able to say more with the logs and commands to reproduce it.
> 
> Thanks,
> Ralf

Thanks for your help.

--
Lionel Landwerlin

Attachment: config_libtool_2.4
Description: Text document


reply via email to

[Prev in Thread] Current Thread [Next in Thread]