Joseph, Right, I read that in the docs and I understand. As well, this is probably unusual enough, that no default is needed?
Do you agree, at least, that fixincludes has a bug here? For now I am working around by using -with-build-sysroot=/usr/local//sys-root. which is redundant but ok for compiling and linking, since the build=>target toolset in use was already configured with -with-sysroot. I expect it will fix fixincludes though. After all, fixincludes worked when building the buld=>target tools. The diff had at least one error, an extraneous ";;". I *really* think there's a bug here. But I agree the diff I sent is not necessarily the fix. 1) -with-build-sysroot should complain clearly and early if not given a parameter That is, if the parameter is "yes". (Autoconf should probably have a way to indicate a parameter is required, if it doesn't already.) 2) More importantly, fixincludes doesn't get the right headers in this scenario (Canadian cross? "crossing to native"? I think Canadian cross is not "there are three platforms", but that build != host, and there /might/ be three platforms. I think three platforms implies Canadian cross, but two can also? I understand the general picture, of build/host/target, just not what to call things "for short".) There is already a build=>target toolset that knows where to get files. Maybe fixincludes should be part of that? Well, actually, it is, but that isn't sufficient. It is the Makefile that is driving it that is "confused". A possible fix would be to "configure" fixinc.sh with defaults?? No, that seems wrong. At least to include it in fixinc.sh directly. However an easy way to ferry this aspect of the build=>target configuration to the Canadian cross might be good. Some small file that gets "installed". I think -enable-bootstrap + -with-build-sysroot might also fix this, but I'd rather manually build/save/install the build=>target compiler. And I'm not sure, -enable-bootstrap for Canadian cross builds build=>target and build=>host compilers? (in my case target==host). You rather want gcc -print-sysroot I think. That should be a good fix. - Jay > Date: Fri, 25 Jul 2008 10:52:33 +0000 > From: [EMAIL PROTECTED] > To: [EMAIL PROTECTED] > CC: gcc@gcc.gnu.org > Subject: RE: --sysroot=yes > > On Fri, 25 Jul 2008, Jay wrote: > >> It allows -with-build-sysroot to default like -with-sysroot. > > The purpose of --with-build-sysroot is if you have installed your sysroot > in a different location from the configured --prefix. For example, you > have configured with --prefix=/opt/somewhere, the final location the > toolchain will be configured for, but have installed the sysroot under > /scratch/somewhere, a staging location used in the build, and will be > installing with "make install prefix=/scratch/somewhere". > > There should be no need for or use of --with-build-sysroot except in > configurations like this. > > -- > Joseph S. Myers > [EMAIL PROTECTED]
