Bug 67116 - incorrect detection of thread model when cross-compiling the tool chain
Summary: incorrect detection of thread model when cross-compiling the tool chain
Status: RESOLVED INVALID
Alias: None
Product: gcc
Classification: Unclassified
Component: libstdc++ (show other bugs)
Version: 5.2.0
: P3 normal
Target Milestone: ---
Assignee: Not yet assigned to anyone
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2015-08-04 13:50 UTC by Cezary Śliwa
Modified: 2020-11-23 13:16 UTC (History)
1 user (show)

See Also:
Host:
Target:
Build:
Known to work:
Known to fail:
Last reconfirmed: 2015-08-04 00:00:00


Attachments
config.log (23.83 KB, text/plain)
2015-08-05 10:32 UTC, Cezary Śliwa
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Cezary Śliwa 2015-08-04 13:50:22 UTC
The configure script detects the thread model of the CXX compiler. When building the tool chain it is the compiler for the host rather than for the target. These are different when cross-compiling.

For example: I am on Linux; I have built a cross compiler to MinGW64 which uses Win32 threads; and I want to use it to cross-compile a native MinGW64 compiler for applications using POSIX threads. I such a situation libstdc++ detects Win32 thread model and builds without thread support.
Comment 1 Jonathan Wakely 2015-08-04 16:00:19 UTC
What are the configure commands you're using?

Libstdc++ is built using the target compiler, so its configure uses the target compiler not the host, so this shouldn't happen.
Comment 2 Cezary Śliwa 2015-08-04 16:11:55 UTC
This is a quite special case, target and host architecture are the same, only the thread models are different. I think libstdc++ uses the preinstalled compiler rather that the one just built. Anyway, the preinstalled compiler is:

$ x86_64-w64-mingw32-g++ -v
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-g++
COLLECT_LTO_WRAPPER=/opt/mingw64-v4.0.2/bin/../libexec/gcc/x86_64-w64-mingw32/5.2.0/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../gcc-5.2.0/configure --with-sysroot=/opt/mingw64 --prefix=/opt/mingw64 --enable-languages=c,c++,fortran,lto --target=x86_64-w64-mingw32 --enable-targets=all
Thread model: win32
gcc version 5.2.0 (GCC)


and the configure command:

../gcc-5.2.0/configure --with-sysroot=/mingw64 --prefix=/mingw64 --enable-languages=c,c++,fortran,lto --target=x86_64-w64-mingw32 --enable-targets=all --host=x86_64-w64-mingw32 --enable-threads=posix --enable-libgomp
Comment 3 Jonathan Wakely 2015-08-04 16:48:35 UTC
(In reply to Cezary Śliwa from comment #2)
> This is a quite special case, target and host architecture are the same,
> only the thread models are different. I think libstdc++ uses the
> preinstalled compiler rather that the one just built. 

If that is happening it's certainly a bug. Could you attach the $target/libstdc++-v3/config.log please?
Comment 4 Cezary Śliwa 2015-08-04 20:47:08 UTC
OK, the newly built compiler cannot be used because we are cross-compiling. The only thing that can be done is to move the trees to the target system and finish building target libraries there. A warning or error message could be a good idea, but otherwise you can close this bug report.
Comment 5 Jonathan Wakely 2015-08-05 08:55:52 UTC
(In reply to Cezary Śliwa from comment #4)
> OK, the newly built compiler cannot be used because we are cross-compiling.

That's not true, the compiler can be used, but you can't run the executables.

The relevant libstdc++ tests should only need the preprocessor, so should work with a cross-compiler.

Please attach the libstdc++-v3/config.log file so I can see what commands are used for the configure tests.
Comment 6 Cezary Śliwa 2015-08-05 10:32:32 UTC
Created attachment 36131 [details]
config.log

libstdc++v3 config.log
Comment 7 Jonathan Wakely 2015-12-11 22:49:35 UTC
The thread model is determined using:

  target_thread_file=`$CXX -v 2>&1 | sed -n 's/^Thread model: //p'`

where $CXX is *supposed* to be the newly-built GCC, e.g. for my native builds the value of CXX is

/home/jwakely/src/gcc/build/./gcc/xgcc -shared-libgcc -B/home/jwakely/src/gcc/build/./gcc -nostdinc++ -L/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/src -L/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/src/.libs -L/home/jwakely/src/gcc/build/x86_64-pc-linux-gnu/libstdc++-v3/libsupc++/.libs -B/home/jwakely/gcc/6/x86_64-pc-linux-gnu/bin/ -B/home/jwakely/gcc/6/x86_64-pc-linux-gnu/lib/ -isystem /home/jwakely/gcc/6/x86_64-pc-linux-gnu/include -isystem /home/jwakely/gcc/6/x86_64-pc-linux-gnu/sys-include

For a mingw64 cross I see /tmp/67116/./gcc/xgcc being used, so I don't know why your config.log shows x86_64-w64-mingw32-c++ being used.

Are you setting CXX or doing anything funny in the libstdc++ build dir?
Comment 8 Jonathan Wakely 2015-12-11 22:57:53 UTC
Yes, this would happen if you're setting CC and CXX, causing libstdc++ to be configured using the compiler specified by those variables, not the one that has just been built. So I think this is user error.
Comment 9 Jonathan Wakely 2020-11-23 13:16:21 UTC
(In reply to Cezary Śliwa from comment #6)
> Created attachment 36131 [details]
> config.log
> 
> libstdc++v3 config.log

This shows:

CXX=' x86_64-w64-mingw32-c++ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include   '
CXXCPP=' x86_64-w64-mingw32-c++ -L/mingw64/x86_64-w64-mingw32/lib -L/mingw64/mingw/lib -isystem /mingw64/x86_64-w64-mingw32/include -isystem /mingw64/mingw/include    -E'

That means you're building libstdc++ with the wrong compiler.