From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 28784 invoked by alias); 22 May 2003 11:44:42 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 28566 invoked from network); 22 May 2003 11:44:36 -0000 Received: from unknown (HELO ultra45.almamedia.fi) (193.209.83.53) by sources.redhat.com with SMTP; 22 May 2003 11:44:36 -0000 Received: from mbnet.fi (a1ea.yhteys.mtv3.fi [62.236.234.161]) by ultra45.almamedia.fi (Postfix) with ESMTP id B2AF01BA410; Thu, 22 May 2003 14:44:32 +0300 (EEST) Message-ID: <3ECCB76D.5060409@luukku.com> Date: Thu, 22 May 2003 12:17:00 -0000 From: Kai Ruottu Reply-To: kai.ruottu@luukku.com User-Agent: Mozilla/5.0 (Windows; U; Windows NT 5.0; en-US; rv:1.3a) Gecko/20021212 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Peter Barada Cc: pbarada@mail.wm.sps.mot.com, randy.rude@gdcanada.com, gcc@gcc.gnu.org, crossgcc@sources.redhat.com Subject: Re: failure building gcc-3.3 (broken libiberty/vsprintf.c or build?) References: <20030520053204.ADDB298982@baradas.org> <3EC9F529.6060106@luukku.com> <20030521034551.108CE98982@baradas.org> <20030521063417.3C30B98982@baradas.org> <1053527958.14557.1.camel@d1d6k111.bowman.gdcanada.com> <200305211509.h4LF98K00400@hyper.wm.sps.mot.com> <20030522030756.AB20298B6D@baradas.org> In-Reply-To: <20030522030756.AB20298B6D@baradas.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-SW-Source: 2003-05/txt/msg01999.txt.bz2 Peter Barada wrote: >>>This looks familiar. Try applying the hashtab.c portion of this patch: >>>http://gcc.gnu.org/ml/gcc-patches/2003-04/msg00726.html >> >>Cool, I'll try it and see what happens. > > > That worked, but I still get the ubiquitous failure rgarding div_t > undeclared. See: > > http://gcc.gnu.org/ml/gcc/2003-04/msg01321.html > http://gcc.gnu.org/ml/gcc/2002-06/msg01602.html > > For more information on this well-observed failure. If I remove > obj/gcc/include/stdlib.h and stat up the build, gcc-3.3 completes. Newlib has the 'stdlib.h'. If this is a broken 'fixed' newlib-header, something went wrong in fixinc. If this is a stub which the GCC-build installed because of not seeing the 'stdlib.h' to exist in the '$prefix/$target/include' (where the newlib-install puts it), checking the '$prefix/$target/sys-include' for it instead, I would call this a serious bug. The GCC-docs sources (gcc/doc/headerdirs.texi) tell: ------------------------------- clip ------------------------------- TOOL_INCLUDE_DIR is used for both native and cross compilers. It is the place for other packages to install header files that GNU CC will use. For a cross-compiler, this is the equivalent of `/usr/include'. When you build a cross-compiler, fixincludes processes any header files in this directory. ------------------------------- clip ------------------------------- Also the description for the GCC_INCLUDE_DIR tells the same things about the $(tooldir)/include. This directory is just the install directory for the target headers, the '$prefix/$target/include'. For me this issue is clear: The GCC-build should check the directory $prefix/$target/include for the cross-GCC's target headers and decide whether to try to fix them or not, the '--with-newlib' could trigger this decision. At least the existence of 'limits.h', 'stdlib.h', 'unistd.h' etc. should be checked from the '$prefix/$target/include'. If the headers are tried to be fixed, the fixing should work ok also in the newlib case. But the 'gcc/doc/install.texi' tells: ------------------------------- clip ------------------------------- Some options which only apply to building cross compilers: --with-headers=dir Specifies a directory which has target include files. This option is required when building a cross compiler, if `prefix/target/sys-include' doesn't pre-exist. These include files will be copied into the `gcc' install directory. fixincludes will be run on these files to make them compatible with GCC. ------------------------------- clip ------------------------------- Ok, let's assume that the '$prefix/$target/sys-include' pre-exists. In the RedHat EDK cross-tools for Linux targets it had the kernel headers ('asm' and 'linux' subdirs), the '.../include' had the usual Linux-glibc headers. I have all the 3rd party headers which describe the I/O-addresses and bits in chips there. In both cases these are 'target include files' and seemingly the GCC-build tries to fix also these for GCC... After reading these two places from the GCC-manuals, one should have some kind of thought what will happen to the target headers during the GCC-build... Or what ? What on earth this explanation for '--with-headers' tries to say? All the experienced cross-GCC builders know that the 'sys-include' definitely isn't the place for the standard target headers for a cross-GCC, but the 'include' is and the text: "For a cross-compiler, this is the equivalent of `/usr/include'", in the GCC-manual agrees with them... The reality in the GCC-build however is that the target headers in the '$prefix/$target/include' are not noticed at all what becomes to the header-fixing and checking the existence of some headers among the target headers. Only the '$prefix/$target/sys-include' will be scanned for these things. BUT as the Peter's logfile told: > Blows up with: > > /home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/gcc/xgcc > -B/home/peter/work/cvs-local/xgcc/obj/m68k-elf/m68k-elf-gcc/gcc/ > -B/tmp/m68k-elf/m68k-elf/bin/ > -B/tmp/m68k-elf/m68k-elf/lib/ > -isystem /tmp/m68k-elf/m68k-elf/include <---- !!! the '$prefix/$target/include' has been taken as the directory where the target headers are expected to exist. What the GCC-build now does, clashes with the GCC-documentation and this I call being a serious bug! > Has anyone else seen this for other cross targets, and does *anyone* > have an idea how to best get past this? Maybe we should bomb the GCC-developers with bug reports about the misuse of the '$prefix/$target/sys-include' now... During the last years I have now and then try to report this, but with no response at all... The current workaround I now use is to symlink all those checked headers: 'stdlib.h', 'unistd.h', 'string.h' and 'limits.h' into '$prefix/$target/sys-include' from '$prefix/$target/include', so that they will not be replaced with stubs during the GCC-build. Cheers, Kai