This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug bootstrap/14316] collect2 doesnt build on windows hosts
- From: "zack at codesourcery dot com" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 17 Mar 2004 20:56:53 -0000
- Subject: [Bug bootstrap/14316] collect2 doesnt build on windows hosts
- References: <20040227020715.14316.droopycom@yahoo.com>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From zack at codesourcery dot com 2004-03-17 20:56 -------
Subject: Re: collect2 doesnt build on windows hosts
Ian Lance Taylor <ian@wasabisystems.com> writes:
> "zack at codesourcery dot com" <gcc-bugzilla@gcc.gnu.org> writes:
>
>> Cross compilers aren't supposed to build fixincl in the first place.
>> There's the real problem.
>
> I see code to disable building fixincl if build != host (unless
> --with-sysroot is specified). But I don't see any code to disable
> building fixincl if build == host and host != target. So it seems to
> me that building a cross-compiler from mingw32 to something else, and
> doing the build on mingw32, will cause this problem.
Huh. This has changed since last I looked at it; fixincl used to be
built only if build == host == target.
> To me it seems reasonable to build fixincl whenever we have header
> files to fix. And that does include the case of host != target.
> There have been times when I've needed it, such as when building for
> the VxWorks target--I put a bunch of VxWorks fixes into fixincludes
> back when I maintained it.
The original logic for not doing it when host != target was that the
header files might not be conveniently available and probably didn't
need fixing anyway -- consider newlib, which (used to) construct its
headers during the target library build, well after fixincludes runs.
I'm not trying to stop you making fixincl build and run on mingw, I'm
just pointing out that we didn't used to bother.
zw
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14316