cross-compile and pkgconfig

[Enrico Weigelt]

* JLM aka cityhunter <jlm_devel at laposte.net> schrieb:

<snip>
> >yeah, the common problem with autoshit + libfool.
> >That's why I had to write my own libtool ...
> >
> pkg-config could be enough... if well designed to handle this case
> for libfool I solved the issue by seding the .la replacing the sysroot 
> by ${SYSROOT}

hmm. interesting idea. so your (installed) .la files contain 
pathes like "${SYSROOT}/usr/lib" instead of "/usr/lib". 
Does this the trick because libtool is a (uncarefully written) 
shell script ? 
(with my java implementation you would bite on stone with that).

BTW: we do not really need to mention the sysroot in (installed) 
.la files, since we can expect *all* pathes to be within sysroot.
This information is probably redundant and could make some folks 
a little bit nervous ...

<snip>
> and it's fun because if works perfectly..... but of course .la are a 
> mess (like .pc were a mess some time ago)

both are still.
we shouldn't expect a common syntax for CFLAGS and LDFLAGS if we
wanna be platform independent.

.pc files should better have a form like this:

    library-name:		Xaw
    library-path:		/usr/X11/lib
    runtime-library-path:	/usr/X11/lib	## probably redundant ?
    version:			1.2.3.4
    platform:			i686-unkwown-linux
    include-path:		/usr/X11/include

This is really platform independent, strict an easily parsable - 
even by a shell script.

> normaly if you remove all .la it still works..... (I remember that I 
> tested this some time ago..... but I don't rememeber clearly the result)

.la files are used at compile time, not at runtime.
The content is almost the same as in .pc, just with the difference, 
that an .la file represents *one* library with some additional information
like libversion, static libname, etc, while a .pc file represents
a whole package. 

I personally separate libraries, instead of mammut packages (ie gtk).

> >I'm using cross-toolchains also to build for the same platform/arch,
> >but different libc version. If there are some strange symbols 
> >(ie. coming from libc) missing, then someone (normally autoconf)
> >messed up pathes.
> > 
> hum funny! because you don't need a crosstoolchains among arch but only 
> a sysroot and the correct CFLAGS, CPPFLAGS, LDFLAGS, CXXFLAGS and so on....

Its better if you have completely different libc versions and probably
varying cputypes.

Having *one* crosscompiler per target seem more clean and stable to me.
(Of course many files could be shared between several similar toolchains)

> >BTW the story gets even funnier, if your package uses libtool to
> >link against other fooled libs and looks for the .la files in the 
> >wrong place. Or just if you're happy that you could supply your own
> >library path within the sysroot, it writes *this sysroot'ed* path
> >down in the .la files.
> > 
> you should not configure them to install in sysroot (ie ./configure 
> --prefix=$SYSROOT/usr) but ./configure --prefix=/usr  and do a DESTDIR 
> install normaly this will solve some .la issues

Of course! The problem doesn't come from there, instead it are things
like --with-foo-includes=$SYSROOT/... 

<snip>
> but of course this won't change your issue since you have 2 times the 
> same arch....
> or are you saying that doing an export LD_LIBRARY_PATH will messup the .la?
No, I don't touch LD_LIBRARY_PATH. 
I pass the pathes to the package's buildsystem, which then has to do
proper -L's and -I's.

<snip>
> anyway there is another trouble maker (recent) it's the glibc! : it 
> recrated pkg-config like stuff
> jlm at xyz:~$ file /usr/lib/libc.so
> /usr/lib/libc.so: ASCII C program text
> 
> I removed it and compile still works!
Yeah, it seems that this is just a dummy or probably a hint for 
the linker. The static-linked ld.so part seems to have ld.so.6 
hardcoded now.


cu
-- 
---------------------------------------------------------------------
 Enrico Weigelt    ==   metux IT service

  phone:     +49 36207 519931         www:       http://www.metux.de/
  fax:       +49 36207 519932         email:     contact at metux.de
  cellphone: +49 174 7066481
---------------------------------------------------------------------
 -- DSL ab 0 Euro. -- statische IP -- UUCP -- Hosting -- Webshops --
---------------------------------------------------------------------