[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #1 from Andrew Pinski pinskia at gcc dot gnu.org --- As far as I know a Canadian cross requires the cross toolchain to that target at least the same languages as the Canadian cross. This check is the same check in libstdc++ also.
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2014-11-24 Ever confirmed|0 |1 --- Comment #2 from Andrew Pinski pinskia at gcc dot gnu.org --- How are you configuring the compilers you are using? Both the cross and the Canadian cross one.
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #3 from Pierre Ossman ossman at cendio dot se --- libstdc++ compiles fine though, but the previous stage did indeed include a C++ compiler. But even with that requirement, it still seems a bit dangerous. What if the previous compiler uses a different exception model? Or changes some other of all the myriad of options that affect compiler behaviour? First compiler (from RHEL 7): $ gcc -v Using built-in specs. COLLECT_GCC=gcc COLLECT_LTO_WRAPPER=/usr/libexec/gcc/x86_64-redhat-linux/4.8.2/lto-wrapper Target: x86_64-redhat-linux Configured with: ../configure --prefix=/usr --mandir=/usr/share/man --infodir=/usr/share/info --with-bugurl=http://bugzilla.redhat.com/bugzilla --enable-bootstrap --enable-shared --enable-threads=posix --enable-checking=release --with-system-zlib --enable-__cxa_atexit --disable-libunwind-exceptions --enable-gnu-unique-object --enable-linker-build-id --with-linker-hash-style=gnu --enable-languages=c,c++,objc,obj-c++,java,fortran,ada,go,lto --enable-plugin --enable-initfini-array --disable-libgcj --with-isl=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/isl-install --with-cloog=/builddir/build/BUILD/gcc-4.8.2-20140120/obj-x86_64-redhat-linux/cloog-install --enable-gnu-indirect-function --with-tune=generic --with-arch_32=x86-64 --build=x86_64-redhat-linux Thread model: posix gcc version 4.8.2 20140120 (Red Hat 4.8.2-16) (GCC) Second compiler: $ i686-pc-linux-gnu-gcc -v Using built-in specs. COLLECT_GCC=/opt/cendio-build/arch/armhf/usr/bootstrap/bin/i686-pc-linux-gnu-gcc COLLECT_LTO_WRAPPER=/opt/cendio-build/arch/armhf/usr/bootstrap/libexec/gcc/i686-pc-linux-gnu/4.5.4/lto-wrapper Target: i686-pc-linux-gnu Configured with: ../configure --prefix=/opt/cendio-build/arch/armhf/usr/bootstrap --with-gmp=/opt/cendio-build/arch/armhf/usr/bootstrap --with-mpfr=/opt/cendio-build/arch/armhf/usr/bootstrap --with-mpc=/opt/cendio-build/arch/armhf/usr/bootstrap --target=i686-pc-linux-gnu --with-sysroot=/opt/cendio-build/arch/armhf --with-system-zlib --with-gnu-as --with-gnu-ld --disable-nls --disable-multilib --disable-libmudflap --enable-shared --enable-threads=posix --enable-languages=c,c++ Thread model: posix gcc version 4.5.4 (GCC) Third compiler: ../configure --host=i686-pc-linux-gnu --prefix=/usr --bindir=/usr/bin --sbindir=/usr/sbin --sysconfdir=/etc --datadir=/usr/share --includedir=/usr/include --libdir=/usr/lib --libexecdir=/usr/libexec --localstatedir=/var --sharedstatedir=/var/lib --mandir=/usr/share/man --infodir=/usr/share/info --build=cross-unknown-linux-gnu --with-build-sysroot=/opt/cendio-build/arch/osx32 --target=i686-pc-linux-gnu --with-sysroot=/ --with-system-zlib --with-gnu-as --with-gnu-ld --disable-nls --disable-multilib --disable-libmudflap --enable-shared --enable-threads=posix --enable-languages=c,c++,objc
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #4 from Pierre Ossman ossman at cendio dot se --- I assumed that this would be what happened: Given --build=B --host=H and --target=T: 1. A gcc would be configured with --build=B --host=H --target=T and put in the installation directory. 2. A second gcc would be configured with --build=B --host=B --target=T and used to build all the libraries that execute on the target system (libgcc, libstdc++, libobjc, etc.). But I guess what you are saying is that only the first compiler is built, and if B != H then you use the system compiler to build the libraries? But how could that possibly work given that you will then produce libraries for H, not T?
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 Andrew Pinski pinskia at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |INVALID --- Comment #5 from Andrew Pinski pinskia at gcc dot gnu.org --- This is by design and there is no other way. even if we get by the configure issue, you still run into an issue because the cross compiler does not have objective-C support (libobjc contains objective-C code; you would think that right?). So closing as invalid.
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #6 from Pierre Ossman ossman at cendio dot se --- Just to make sure I understand you perfectly. This is not supported: ../configure --build=A --host=B --target=B Instead you have to do: ../configure --build=A --host=A --target=B Then use that to: ../configure --build=A --host=B --target=B And those two compilers better have the same settings with regard to the target or you're bound to get problems. Have I understood it correctly?
[Bug libobjc/64051] broken exception model detection in libobjc's configure
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64051 --- Comment #7 from Andrew Pinski pinskia at gcc dot gnu.org --- (In reply to Pierre Ossman from comment #6) Just to make sure I understand you perfectly. This is not supported: ../configure --build=A --host=B --target=B By itself yes this is not supported. Instead you have to do: ../configure --build=A --host=A --target=B Then use that to: ../configure --build=A --host=B --target=B And those two compilers better have the same settings with regard to the target or you're bound to get problems. Have I understood it correctly? Yes.
