public inbox for crossgcc@sourceware.org
 help / color / mirror / Atom feed
From: "Soloff, Steven M          Belcan Engineering Group, Cincinnati, Ohio" <Steven.Soloff@pw.utc.com>
To: <crossgcc@sourceware.org>
Subject: RE: crosstool-ng 1.19.0 fails to build i686-unknown-mingw32
Date: Thu, 30 Jan 2014 14:22:00 -0000	[thread overview]
Message-ID: <4F66624F960F3746BB0263581CC9CE83040B7E11@PUSMNEI1.pwemail.us> (raw)
In-Reply-To: <081118858EAEC94C9E4EE628510B31CD13227DF1@exchange10.valvesoftware.com>

This apparently broke beginning with GCC 4.6.0.  I didn't track down the
root cause of the change in the GCC build process that required the
sysroot files to be accessible during the pass-1 compiler build.
However, the existence of the sysroot/mingw directory is not sufficient
-- the headers need to be there, as well.

Taking a cue from the patch referenced by Drew, I instead modified
scripts/build/libc/mingw.sh by moving the contents of
do_libc_start_files() to the end of do_libc_extract() [1], which should
only affect MinGW targets.  I verified I could build a MinGW target
using GCC 4.5.3 (i686) and 4.8.1 (i686 and x86_64) using a patched
crosstool-ng 1.19.0.

However, I doubt this is the optimal solution.  Seeing the "Installing C
library headers" step during the "Extracting and patching toolchain
components" step just smells bad.  I'd appreciate any suggestions from
the devs for a better fix that I could submit.

Thanks,
Steve

[1]
--- a/scripts/build/libc/mingw.sh
+++ b/scripts/build/libc/mingw.sh
@@ -11,13 +11,7 @@ do_libc_extract() {
     CT_Pushd "${CT_SRC_DIR}/mingw-w64-v${CT_WINAPI_VERSION}/"
     CT_Patch nochdir mingw-w64 "${CT_WINAPI_VERSION}"
     CT_Popd
-}
 
-do_libc_check_config() {
-    :
-}
-
-do_libc_start_files() {
     local -a sdk_opts
 
     CT_DoStep INFO "Installing C library headers"
@@ -56,6 +50,14 @@ do_libc_start_files() {
     CT_EndStep
 }
 
+do_libc_check_config() {
+    :
+}
+
+do_libc_start_files() {
+    :
+}
+
 do_libc() {
     CT_DoStep INFO "Building mingw-w64 files"


-----Original Message-----
From: Drew Bliss [mailto:drewb@valvesoftware.com] 
Sent: Monday, January 20, 2014 7:32 PM
To: 'crossgcc@sourceware.org'
Subject: RE: crosstool-ng 1.19.0 fails to build i686-unknown-mingw32

The x-tools directory appears to be cleaned up and recreated when
running ct-ng build, so any manually created directory is gone by the
time it gets to the point of needing it.

Back in Aug 2012 the same issue was reported with 1.16 and a user said
that this patch reordering steps fixed the problem.  It doesn't appear
to fix it with 1.19, plus the patch was considered undesirable since it
breaks non-mingw builds.

--- a/lib/ct-ng.1.16.0/steps.mk	2012-08-06 14:55:00.848409671 +0200 
+++ b/lib/ct-ng.1.16.0/steps.mk	2012-08-06 14:39:24.736900247 +0200 
@@ -36,9 +36,9 @@ 
             binutils_for_host   \ 
             elf2flt_for_host    \ 
             sstrip_for_host     \ 
+            libc_start_files    \ 
             cc_core_pass_1      \ 
             kernel_headers      \ 
-            libc_start_files    \ 
             cc_core_pass_2      \ 
             libc                \ 
             cc_for_build        \

-----Original Message-----
From: Ray Donnelly [mailto:mingw.android@gmail.com]
Sent: Monday, January 20, 2014 4:19 PM
To: Drew Bliss
Cc: crossgcc@sourceware.org
Subject: Re: crosstool-ng 1.19.0 fails to build i686-unknown-mingw32

mkdir -p .. of course!

On Tue, Jan 21, 2014 at 12:18 AM, Ray Donnelly <mingw.android@gmail.com>
wrote:
> As a workaround you can make the parent directory before commencing
the build:
>
> mkdir
> /home/user/x-tools/i686-unknown-mingw32/i686-unknown-mingw32/sysroot/m
> ingw
>
>
> On Mon, Jan 20, 2014 at 11:50 PM, Drew Bliss <drewb@valvesoftware.com>
wrote:
>> This is the same issue that Daniel Pauli mailed about in Mar 2013 but
there didn't seem to be a reply.  Does anybody know what the problem is
here?
>>
>> From: Daniel Pauli <dapaulid at gmail dot com>
>> To: crossgcc at sourceware dot org
>> Date: Wed, 6 Mar 2013 19:47:25 +0100
>> Subject: crosstool-ng 1.18.0 fails to build i686-unknown-mingw32 for 
>> gcc 4.7.2 Hey there
>>
>> I'm trying to build the i686-unknown-mingw32 sample for gcc 4.7.2 but

>> it fails at the following step:
>>
>> [ALL  ]    The directory that should contain system headers does not
exist:
>> [ALL  ]
/home/user/x-tools/i686-unknown-mingw32/i686-unknown-mingw32/sysroot/min
gw/include
>> [ERROR]    make[2]: *** [stmp-fixinc] Error 1
>> [ALL  ]    rm gcc.pod
>> [ALL  ]    make[2]: Leaving directory
>>
`/home/user/crosstool-ng-1.18.0/test/.build/i686-unknown-mingw32/build/b
uild-cc-core-pass-1/gcc'
>> [ERROR]    make[1]: *** [all-gcc] Error 2
>> [ALL  ]    make[1]: Leaving directory
>>
`/home/user/crosstool-ng-1.18.0/test/.build/i686-unknown-mingw32/build/b
uild-cc-core-pass-1'
>> [ERROR]
>> [ERROR]  >>
>> [ERROR]  >>  Build failed in step 'Installing pass-1 core C compiler'
>> [ERROR]  >>        called in step '(top-level)'
>> [ERROR]  >>
>> [ERROR]  >>  Error happened in: CT_DoExecLog[scripts/functions@257]
>> [ERROR]  >>        called from:
do_cc_core_backend[scripts/build/cc/gcc.sh@448]
>> [ERROR]  >>        called from:
do_cc_core_pass_1[scripts/build/cc/gcc.sh@101]
>> [ERROR]  >>        called from: main[scripts/crosstool-NG.sh@632]
>>
>>
>> --
>> For unsubscribe information see http://sourceware.org/lists.html#faq
>>

--
For unsubscribe information see http://sourceware.org/lists.html#faq

  reply	other threads:[~2014-01-30 14:22 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-01-20 23:50 Drew Bliss
2014-01-21  0:18 ` Ray Donnelly
2014-01-21  0:18   ` Ray Donnelly
2014-01-21  0:32     ` Drew Bliss
2014-01-30 14:22       ` Soloff, Steven M          Belcan Engineering Group, Cincinnati, Ohio [this message]
2014-01-30 14:43         ` Ray Donnelly
2014-01-30 18:15           ` [External] " Soloff, Steven M          Belcan Engineering Group, Cincinnati, Ohio

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=4F66624F960F3746BB0263581CC9CE83040B7E11@PUSMNEI1.pwemail.us \
    --to=steven.soloff@pw.utc.com \
    --cc=crossgcc@sourceware.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).