On 10/1/2010 4:22 PM, Alon Bar-Lev wrote:
> On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson
> <please-don't-feed-the-spammers> wrote:
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>> Please, over the past three months there were hundreds of messages
>> discussing sysroot and how it shoold be handled. While libtool's
>> support is not yet complete, what IS there is the result of those
>> discussions. Please read them; I have a suspicion you don't quite grok
>> what sysroot is really FOR, so your assumptions about how it
>> should/shouldn't/does/doesn't work are somewhat flawed.
>
> You assume wrong.
> I use cross compilers as much as I use native ones.
Then why was your example, demonstrating how "sysroot should work",
shown as using native tools? I don't know of a single distributor that
enables sysroot support in their native toolchain.
And...sysroot support, per se, is still very very new even in GCC. But,
gcc cross compilers with sysroot support is the primary milieu for which
libtool's own sysroot stuff was implemented.
> This why I waited and followed for long libtool's lacking support in
> these environments.
> I guess you know better and sure that all OK, this ends the discussion
> before it started.
No. It's just that your statements, and your *example*, lead one to
believe that you were approaching the sysroot issue from a perspective
OTHER than the one for which libtool's implementation was designed.
IF you have an issue with that design, AND you were "following for long"
libtool's development of it...why didn't you chime in three months ago?
> Anyway, sysroot and cross compile sysroot can be the same, however,
> making the cross compiler sysroot dirty, may cause undesirable
> results, especially in build machines.
See, this is exactly what I'm talking about. The whole POINT of
libtool's sysroot is so that you CAN install the built libs into the
compiler's sysroot, so that they can be automatically used there when
building OTHER libs and apps that depend on them. It's not making it
"dirty"...
> Here comes the DESTDIR to the
> rescue.
And you can STILL use DESTDIR if you like. However, if you are trying
to create *multiple* sysroots that can be used by the same compiler (at
different times, obviously)...then you can do this:
set CFLAGS+="--sysroot=/my/sysroot1"
(similar for CPPFLAGS, CXXFLAGS, LDFLAGS, etc)
That way, your compiler will use the "correct sysroot". Then, you can
also ensure that *libtool* knows to "turn on" sysroot support for
linking .la files, by configuring whatever it is you are building with
libtool's --with-sysroot=/my/sysroot1 option.
(I'm not sure if you can get away with just --with-sysroot; it OUGHT to
work, since `$(CC) $(CFLAGS) -print-sysroot` (that is, `gcc
--sysroot=/a/b/c -print-sysroot` should return '/a/b/c', but I'm not
sure about that.)
> But you know better...
Possibly. Possibly not. I do know that I've been participating in this
discussion for months now, and testing multiple libtool patchsets
related to sysroot in dozens of configurations with a handful of cross
compilers on a couple of $build platforms...and you have been silent.
So I have no idea what you do or do not know. All I can go by is what
you've said in this thread.
Which didn't start off well:
"Also, why not take the value of the sysroot from the DESTDIR automake
variable?"
DESTDIR != sysroot. It is similar, but *different*, and behaves in a
different way. (And I'm talking here about how gcc/binutils use the
term; regardless of how libtool addresses the issue). With DESTDIR, you
still have to ensure that your CFLAGS includes
"-I$DESTDIR/$prefix/include" and LDFLAGS includes
"-L$DESTDIR/$prefix/lib". Worse, those paths "leak" into your compiled
results. With sysroot, IF it is done correctly, you shouldn't need to
specify EITHER of those things, since $sysroot/$prefix/{include,lib} is
already IN the (cross)compiler's default search path. So, no leakage;
all you need is to tell the compiler that it ought to use $DESTDIR for
the sysroot. (And, of course, if you use the default sysroot, you don't
need to tell it anything; it'll Just Work(tm)).
What if I wanted to build an SDK for linux->mingw, that a client
(developer) could install in THEIR compiler's (default) sysroot on
linux? I'd need a DESTDIR in /tmp/ where I could "package it up", but
underneath that DESTDIR I'd still need to see both the sysroot and the
prefix:
/tmp/my-build/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
^^^^^^^^^ ^^^^^^^^^^^^^^^^^^^^^^^^^^^^ ^^^
DESTDIR sysroot prefix (on $host)
Then, I'd create my RPM/deb from /tmp/my-build, so that Sally can
install on her linux box, and it would all end up in
/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
just like it's supposed to. Then, when she uses her i686-pc-mingw32-gcc
to build the bar.exe client of libfoo (for the mingw $host), the new
libs and headers will be found. Now, the libfoo.la file in
/usr/i686-pc-mingw32/sys-root/mingw/lib
might contain something like:
libdir='=/mingw/lib'
because, IF libfoo.dll and associated files were to be installed on
$host (mingw), then they'd go in /mingw/{lib,include,...} on THAT
system. So, at runtime (and for "native" development on mingw),
/mingw/lib IS the correct library dir. We use the '=' so that when
cross building a client of libfoo on the non-native build system, the
machinery can know that '=' ought to be replaced by whatever $sysroot is
on $build, at that time. Hopefully, when Sally configured the project
'bar' build, she did it in such a way that gcc (and libtool) both agree
that $sysroot (on $build) is (still)
/usr/i686-pc-mingw32/sys-root
and it all works.
The thinking is, cross compile support in the toolchain for sysroots is
specifically FOR creating these SDK type installations. If you want to
THEN re-package stuff up for NATIVE deployment on $host, you need to use
some other tool to "pick" the necessary elements out of the sysroot.
Alternatively, of course, you can 'make install' with DESTDIR as you say
-- but because DESTDIR and sysroot are othogonal concepts, you'd need to
explicitly set
CFLAGS="--sysroot=$my_destdir"
to (artificially) join these two orthogonal concepts together, if you
wanted to actually compile and link against something you've
(temporarily) installed into a DESTDIR.
We're giving you the knobs; it's up to you to set them as needed to
support your desired workflow. And...also to support OTHER workflows
wherein sysroot and DESTDIR need to be *different*.
Alternatively, of course, you can just ignore all this sysroot
gobbledygook, and use DESTDIR like people have been doing for years
before sysroot was added to gcc/binutils (and live with the problems
that "real" sysroot is intended to fix).
This would all make a lot more sense if we had better (any?)
documentation...
--
Chuck
_______________________________________________
http://lists.gnu.org/mailman/listinfo/libtool
