Bug 50229 - [7/8/9/10 Regression] Can't cross compile for i686-apple-darwin10 from x86_64-redhat_linux
Summary: [7/8/9/10 Regression] Can't cross compile for i686-apple-darwin10 from x86_64...
Status: NEW
Alias: None
Product: gcc
Classification: Unclassified
Component: bootstrap (show other bugs)
Version: 4.7.0
: P4 normal
Target Milestone: 7.5
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2011-08-29 18:19 UTC by Ruben Van Boxem
Modified: 2019-03-29 12:21 UTC (History)
10 users (show)

See Also:
Host: x86_64-linux
Target: i686-apple-darwin10
Build:
Known to work:
Known to fail:
Last reconfirmed: 2014-11-08 00:00:00


Attachments
toplevel config.log (24.97 KB, text/x-log)
2011-08-29 18:19 UTC, Ruben Van Boxem
Details
toplevel config.log (6.37 KB, text/plain)
2011-08-29 18:22 UTC, Ruben Van Boxem
Details
gcc/config.log (24.97 KB, text/plain)
2011-08-29 18:23 UTC, Ruben Van Boxem
Details
Compressed build log detailing failure (59.37 KB, text/plain)
2011-08-29 18:26 UTC, Ruben Van Boxem
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Ruben Van Boxem 2011-08-29 18:19:41 UTC
Created attachment 25130 [details]
toplevel config.log

I am cross-compiling a 
HOST=i686-apple-darwin10
BUILD=x86_64-redhat-linux
TARGET=i686-w64_mingw32
cross-compiler.

GCC 4.6 (and most probably 4.5) work fine, GCC 4.7 misconfigures and results in a build failure.

Attached is top-level toplevel config.log, more to follow.
Comment 1 Ruben Van Boxem 2011-08-29 18:22:32 UTC
Created attachment 25131 [details]
toplevel config.log

Add proper toplevel config.log
Comment 2 Ruben Van Boxem 2011-08-29 18:23:12 UTC
Created attachment 25132 [details]
gcc/config.log

Attached gcc/config.log
Comment 3 Ruben Van Boxem 2011-08-29 18:26:10 UTC
Created attachment 25133 [details]
Compressed build log detailing failure

Attached build log. ("make all-gcc" output)
Comment 4 Ruben Van Boxem 2011-08-29 18:30:29 UTC
For those wondering how on Earth I am cross-compiling for Mac, see
http://build1.openftd.org/fedora-cross-darwinx/

This is a cross toolchain for Fedora, which works quite well.
The version used in the build is:
Using built-in specs.
Target: i686-apple-darwin10
Configured with: ../configure --prefix=/usr --bindir=/usr/bin --includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man --infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu --host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10 --enable-languages=c,objc,c++,obj-c++ --with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk --with-as=/usr/bin/darwinx-as --with-ld=/usr/bin/darwinx-ld --enable-static --enable-shared --disable-nls --enable-multilib --enable-libssp
Thread model: posix
gcc version 4.2.1 (Apple Inc. build 5664)
Comment 5 Iain Sandoe 2011-09-08 07:38:33 UTC
Not necessarily related to your specific problem - but a "heads up":

I've just committed a change to the Darwin port that will make the compiler (better) use the target system headers.

However, it will also accentuate the issue that you are targeting Darwin10 using a Darwin9 system framework and toolset.  

You will need to fake a darwin10 "ld" that can handle the "-no_compact_unwind" unwind flag (or comment that section out of config/darwin10.h).

Until someone has time to update odcctools or toolwhip to a Darwin10 version, I wonder if it is not simply easier to build an i686-Darwin9 executable? (which should run fine on Darwin10)
Comment 6 Iain Sandoe 2011-09-08 07:43:03 UTC
(In reply to comment #5)
> Not necessarily related to your specific problem - but a "heads up":
> 
> I've just committed a change to the Darwin port that will make the compiler
> (better) use the target system headers.
> 
> However, it will also accentuate the issue that you are targeting Darwin10
> using a Darwin9 system framework and toolset.  
> 
> You will need to fake a darwin10 "ld" that can handle the "-no_compact_unwind"
> unwind flag (or comment that section out of config/darwin10.h).
> 
> Until someone has time to update odcctools or toolwhip to a Darwin10 version, I
> wonder if it is not simply easier to build an i686-Darwin9 executable? (which
> should run fine on Darwin10)

(this relates to the host libs and tools of course - not the mingw_32 stuff).
Comment 7 Ruben Van Boxem 2011-09-19 19:28:48 UTC
I'm still experiencing the same behavior.

I don't think the darwinx toolchain has the problems you say? Why do you think it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac OS X 10.5 SDK, which are all pretty Darwin10 as far as I can see.

Something changed in 4.6 vs 4.7. I have sys/malloc.h , objc/malloc.h, and malloc/malloc.h. Somehow, HAVE_MALLOC_H is being wrongfully defined to 1 when it should be 0.

auto-host.h has the define commented out.
auto-build.h has it defined.

These are the same for GCC 4.6. So the problem must lie elsewhere...

I noticed the gengtype-lex.o object file is build with i686-apple-darwin10-gcc for GCC 4.7, and (Linux) gcc for GCC 4.6. This cannot be intended behavior.
Comment 8 Iain Sandoe 2011-09-19 19:45:38 UTC
(In reply to comment #7)
> I'm still experiencing the same behavior.

yes, I would guess so unless you re-build the cross tools (and that would probably not solve your config problems - given the other comments you made) ...

>  I don't think the darwinx toolchain has the problems you say? Why do you think
> it uses a Darwin9 system framework and headers? It has GCC 4.2.1 and the Mac OS
> X 10.5 SDK, which are all pretty Darwin10 as far as I can see.

OSX 10.5 is darwin 9 (and gcc 4.2.1 is perfectly usable under OSX10.5/darwin9 - it's just not the default).

Target: i686-apple-darwin10
Configured with: ../configure --prefix=/usr --bindir=/usr/bin
--includedir=/usr/include --libdir=/usr/lib64 --mandir=/usr/share/man
--infodir=/usr/share/info --datadir=/usr/share --build=x86_64-unknown-linux-gnu
--host=x86_64-unknown-linux-gnu --target=i686-apple-darwin10
--enable-languages=c,objc,c++,obj-c++
--with-sysroot=/usr/darwinx/SDKs/MacOSX10.5.sdk 
 .........................................................^^^^^^^^^^^^

I'm not aware of a genuine darwin10 (OSX 10.6) cross-toolchain - but if there is I'd love to see it (I'm only aware of toolwhip and odcctools which are both on the darwin9  ld64 AFAIK).
Comment 9 Ruben Van Boxem 2011-10-26 12:49:43 UTC
I received a build of a darwinx-ld binary from the darwinx toolchain maintainer that accepts the -no_compact_unwind option, and the problem has not gone away. Configure is either using the wrong headers for the build or configure is messing up.
Comment 10 Richard Biener 2012-01-19 12:42:40 UTC
i686-apple-darwin10 isn't a cross-only target but also a host platform.
Comment 11 Richard Biener 2012-03-22 08:25:57 UTC
GCC 4.7.0 is being released, adjusting target milestone.
Comment 12 Richard Biener 2012-06-14 08:09:31 UTC
GCC 4.7.1 is being released, adjusting target milestone.
Comment 13 Jakub Jelinek 2012-09-20 10:12:40 UTC
GCC 4.7.2 has been released.
Comment 14 Ray Donnelly 2013-01-15 15:56:00 UTC
> Until someone has time to update odcctools or toolwhip to a Darwin10 version, I wonder if it is not simply easier to build an i686-Darwin9 executable? (which should run fine on Darwin10)

I've done this. I started from javacom's toolchain4 which uses odcctools. I heavily patched odcctools to bring them more up to date. Eventually, the hope is to merge these cross compilers with the crosstool-ng project.

For now though, you can find the source code here:
https://github.com/mingwandroid/toolchain4 (master branch should build ok with ./build-all.sh apple provided you've got MacOSX10.7.sdk)

..and binaries here (again to use these you need MacOSX10.7.sdk):
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Linux-120724.tar.xz
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Windows-120614.7z
http://mingw-and-ndk.googlecode.com/files/multiarch-darwin11-cctools127.2-gcc42-5666.3-llvmgcc42-2336.1-Darwin-120615.7z

(the Darwin native build is provided too for testing/QA purposes).
Comment 15 Ray Donnelly 2013-01-15 16:07:45 UTC
What brought me here was a desire to add some information about this bug, when I saw the odcctools comment from Iain I thought I may as well mention my compilers.

Further Information:

I'm also getting this when trying to build some Android cross compilers in the Canadian way, with failures when host is either Darwin or Windows. The bug only happens if --enable-plugins is specified to configure (as that's what triggers building a gengtype executable for the host machine).

Darwin:
build system type... x86_64-pc-linux-gnu
host system type... i686-apple-darwin
target system type... arm-unknown-linux-androideabi
i686-apple-darwin-gcc -c -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE   -DGENERATOR_FILE -I. -Ibuild -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/build -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../include -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libcpp/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-apple-darwin/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-apple-darwin/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-apple-darwin/temp-prereqs/include  -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber/dpd -I../libdecnumber -o build/genconstants.o /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c
In file included from /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c:29:
/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/system.h:459:20: error: malloc.h: No such file or directory

Windows:
build system type... x86_64-pc-linux-gnu
host system type... i686-w64-mingw32msvc
target system type... arm-unknown-linux-androideabi
i686-w64-mingw32msvc-gcc -c   -Os -fomit-frame-pointer -s -D__USE_MINGW_ACCESS -DIN_GCC -DCROSS_DIRECTORY_STRUCTURE  -W -Wall -Wno-narrowing -Wwrite-strings -Wcast-qual -Wstrict-prototypes -Wmissing-prototypes -Wmissing-format-attribute -pedantic -Wno-long-long -Wno-variadic-macros -Wno-overlength-strings -Wold-style-definition -Wc++-compat   -DHAVE_CONFIG_H -I. -I. -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/. -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../include -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libcpp/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-w64-mingw32msvc/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-w64-mingw32msvc/temp-prereqs/include -I/tmp/necessitas/ndk-build/build/host-gcc/i686-w64-mingw32msvc/temp-prereqs/include  -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber -I/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/../libdecnumber/dpd -I../libdecnumber    /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c -o genconstants.o
In file included from /tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/genconstants.c:29:0:
/tmp/necessitas/android-qt-ndk/toolchain-source/gcc/gcc-4.7/gcc/system.h:351:22: fatal error: sys/wait.h: No such file or directory

...so as Ruben said, it seems that there's config confusion going on.
Comment 16 Ray Donnelly 2013-01-16 07:59:48 UTC
Of course, when I wrote '--enable-plugins' I really mean't *not* passing --disable-plugin (without the 's').
Comment 17 Richard Biener 2013-04-11 07:58:41 UTC
GCC 4.7.3 is being released, adjusting target milestone.
Comment 18 Jackie Rosen 2014-02-16 13:14:20 UTC Comment hidden (spam)
Comment 19 Richard Biener 2014-06-12 13:44:34 UTC
The 4.7 branch is being closed, moving target milestone to 4.8.4.
Comment 20 Francois-Xavier Coudert 2014-11-08 17:53:29 UTC
This PR appears to report two different issues:
  1. cross-compiler targeting Darwin
  2. cross-compiler hosted on Darwin

The first one, as far as I know, simply doesn't work for recent darwin versions, due to lack of compiler tools (cross assembler and linker). Is that correct?

For the second, could someone post a clear and up-to-date example of when it doesn't work?
Comment 21 Iain Sandoe 2014-11-08 18:11:17 UTC
(In reply to Francois-Xavier Coudert from comment #20)
> This PR appears to report two different issues:
>   1. cross-compiler targeting Darwin

cross-compilers targeting Darwin <= 9 are possible using odcctools.

For "the future"
I am working on a set of GCC patches and a GAS port that solves part of the problem for newer cases.  I intend to post these before stage#1 ends (but time is short - esp. with trunk trashed on darwin at the moment).

However the static linker remains an issue (I have a build of ld64-127.2 which supports Darwin10, and ppc*) … however, this needs to be forward-ported to the latest published sources for ld64 before it will support "current" Darwin.  

In any event, it would be the User's responsibility to obtain a suitable SDK for the target - by downloading the appropriate Xcode and extracting the SDK as needed.

in short: "can't be expected to work until there's a set of Darwin 'binutils' supporting > darwin 9". (working on providing that).

>   2. cross-compiler hosted on Darwin

I do this all the time - it's possible to cross from x86_64-darwin12 -> powerpc-darwin9, for example (assuming one has the relevant cctools and ld64, and enough patience).

I have also built native-crosses [x86-64-darwin12=build powerpc-darwin8 host/target] for the record.

Darwin works just fine as a host for cross-compilers to Linux.

(building your own sysroot - in particular GLIBC can be a trial, but if you make a sysroot from a standard distro, it's not hard).

in short (2) is very definitely "works for me"
Comment 22 Francois-Xavier Coudert 2014-11-08 18:17:33 UTC
(In reply to Iain Sandoe from comment #21)
> in short (2) is very definitely "works for me"

For me too: I regularly build darwin-to-mingw-w64 cross compilers, with no problem at all. But there were, apparently, problems with Canadian crosses (comments by Ray Donnelly).
Comment 23 Jakub Jelinek 2014-12-19 13:34:24 UTC
GCC 4.8.4 has been released.
Comment 24 Richard Biener 2015-06-23 08:17:04 UTC
The gcc-4_8-branch is being closed, re-targeting regressions to 4.9.3.
Comment 25 Jakub Jelinek 2015-06-26 19:58:11 UTC
GCC 4.9.3 has been released.
Comment 26 Richard Biener 2016-08-03 10:53:42 UTC
GCC 4.9 branch is being closed
Comment 27 Eric Gallager 2017-07-23 22:06:32 UTC
(In reply to Iain Sandoe from comment #21)
> (In reply to Francois-Xavier Coudert from comment #20)
> > This PR appears to report two different issues:
> >   1. cross-compiler targeting Darwin
> 
> cross-compilers targeting Darwin <= 9 are possible using odcctools.
> 
> For "the future"
> I am working on a set of GCC patches and a GAS port that solves part of the
> problem for newer cases.  I intend to post these before stage#1 ends (but
> time is short - esp. with trunk trashed on darwin at the moment).
> 
> However the static linker remains an issue (I have a build of ld64-127.2
> which supports Darwin10, and ppc*) … however, this needs to be
> forward-ported to the latest published sources for ld64 before it will
> support "current" Darwin.  
> 
> In any event, it would be the User's responsibility to obtain a suitable SDK
> for the target - by downloading the appropriate Xcode and extracting the SDK
> as needed.
> 
> in short: "can't be expected to work until there's a set of Darwin
> 'binutils' supporting > darwin 9". (working on providing that).
> 
> >   2. cross-compiler hosted on Darwin
> 
> I do this all the time - it's possible to cross from x86_64-darwin12 ->
> powerpc-darwin9, for example (assuming one has the relevant cctools and
> ld64, and enough patience).
> 
> I have also built native-crosses [x86-64-darwin12=build powerpc-darwin8
> host/target] for the record.
> 
> Darwin works just fine as a host for cross-compilers to Linux.
> 
> (building your own sysroot - in particular GLIBC can be a trial, but if you
> make a sysroot from a standard distro, it's not hard).
> 
> in short (2) is very definitely "works for me"

So does this bug need to stay open then?
Comment 28 Ruben Van Boxem 2017-07-24 14:58:17 UTC
(In reply to Eric Gallager from comment #27)
> (In reply to Iain Sandoe from comment #21)
> > (In reply to Francois-Xavier Coudert from comment #20)
> > > This PR appears to report two different issues:
> > >   1. cross-compiler targeting Darwin
> > >   2. cross-compiler hosted on Darwin
> > in short (2) is very definitely "works for me"
> So does this bug need to stay open then?

I reported the original issue using Fedora's Mac OS X cross compiler toolchains that were available at the time. They are still described here, but the repo has become unavailable:
https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework

I cannot seem to locate an active repository providing these now.

So it is really your number one. If the problem lies outside of GCC sources, perhaps it's best to close this issue, but as it used to work in GCC 4.6, it seems something changed that made this setup nonfunctional.
Comment 29 Eric Gallager 2017-07-24 15:48:03 UTC
(In reply to Ruben Van Boxem from comment #28)
> (In reply to Eric Gallager from comment #27)
> > (In reply to Iain Sandoe from comment #21)
> > > (In reply to Francois-Xavier Coudert from comment #20)
> > > > This PR appears to report two different issues:
> > > >   1. cross-compiler targeting Darwin
> > > >   2. cross-compiler hosted on Darwin
> > > in short (2) is very definitely "works for me"
> > So does this bug need to stay open then?
> 
> I reported the original issue using Fedora's Mac OS X cross compiler
> toolchains that were available at the time. They are still described here,
> but the repo has become unavailable:
> https://fedoraproject.org/wiki/MinGW/CrossCompilerFramework
> 
> I cannot seem to locate an active repository providing these now.
> 
> So it is really your number one. If the problem lies outside of GCC sources,
> perhaps it's best to close this issue, but as it used to work in GCC 4.6, it
> seems something changed that made this setup nonfunctional.

Well looking back at comment #21 Iain did say some of his patches were for GCC so at least some of the problem is in GCC sources, even if most of it is in the rest of the toolchain... I'll change the status to NEW since it's not you we're WAITING on.
Comment 30 Eric Gallager 2017-10-10 15:24:19 UTC
Changing milestone since gcc-5-branch has been closed.
Comment 31 Eric Gallager 2019-01-10 03:50:09 UTC
(In reply to Eric Gallager from comment #30)
> Changing milestone since gcc-5-branch has been closed.

...and again now that gcc-6-branch has been closed.