Issues with cross compilers + ~/.mkcmake/mkc_imp.cc_gcc-X.X.X.mk
wdlkmpx opened this issue · 8 comments
This is a problem I found in mk-configure 0.37.0
where X.X.X is the gcc version
I noticed that file is not created automatically, so I have something like this to deal with that fatal design flaw
function _mkcmake () # mk-configure
{
if [ -z "$GCC_VER" ] ; then
## create compiler specs file, otherwise the build fails
GCC_VER=$(${CC} -dumpversion)
if [ ! -f "$HOME/.mkcmake/mkc_imp.cc_gcc-${GCC_VER}.mk" ] ; then
CC=${CC} CXX=${CXX} mkc_compiler_settings
fi
fi
...The biggest problem here is that mkc_imp.cc_gcc-X.X.X.mk doesn't take into account the target triplet (i.e i686-linux-musl, i686-linux-gnu, i686-w64-mingw32, etc), it assumes all compilers with the same version share the same specs, and that is completely and absolutely wrong
So this build system is not suitable for cross compiling, what if the cross compiler has the same version as the system compiler, the cross compiler will never be evaluated... sane build systems (cmake, autotools, etc) always check the compiler specs when they need to make sure some flags are supported
Will be fixed. Thanks!
Also, try the latest version of mk-configure.
Ok I'll test and provide feedback later
I guess this approach makes sense for clang which is a cross compiler for all supported targets, that one single binary
GCC uses a different toolchain (triplet) to cross compile for a different target, so you can compile cross-compilers with different features but with the same version and triplet.. it's a mess
# gcc -dumpmachine
i686-linux-gnu
So basically gcc is a symlink to i686-linux-gnu, it's the system compiler, no need to use the triplet, it's only needed when cross-compiling, but the triplet is used to identify the compiler, although there can be other compilers in other PATH with the same triplet, it's a complex issue, that's why build systems produce config.h or similar files, so that the compiler and sysroot specs can be reevaluated when needed... by running make distclean (or something like that) or "configuring" again
Testing mk-configure 0.38.2
/usr/share/mk-configure/mk/mkc_imp.cc_gcc-11.2.1.mk shouldn't be created as part of installation procedure
I have different cross compilers with the same version that don't get evaluated because /usr/share/mk-configure/mk/mkc_imp.cc_gcc-11.2.1.mk is already there
Now I want to use a cross compiler with version 12.2.0
bmake[1]: "/usr/share/mk-configure/mk/mkc_imp.platform.sys.mk" line 129: 'Settings for gcc-12.2.0 is not available, run "mkc_compiler_settings" utility'
mkcmake should automatically call mk_compiler_settings with CC=$CC and/or CXX=$CXX (whatever is currently needed)
Here we have 2 critical bugs, not taking into account the triplet
You should fix these 2 bugs as soon as possible, nothing generated should go to /usr/share/mk-configure/... it should go to $HOME
Critical bugs here that make mk-configure a nightmare for cross compiling or using any other compiler than the system compiler.... a cross-compiler may be in a non standard location, scripts export PATH with the correct bin path
Critical bugs here that should be fixed right now
Well, I think the only serious problem is that mk-configure doesn't work properly with different compilers (cross-compilers) with the same version. All other notices are minor, and can easily be fixed on your side. Triples for gcc should be a part of mkc_imp.cc_gcc-11.2.1.mk filename regardless of where this file is (in system directories or $HOME). As I said in the past I'll fix the issue with triplets in the next release.
mkc_imp.cc_gcc-11.2.1.mk shouldn't be created as part of installation procedure
I disagree. This file should be generated once at build and installation time in order to avoid its generation by user. The problem with cross-compilation is different and will be fixed in a different way.
I have different cross compilers with the same version...
I understand the problem. Thanks a lot for notifying me!
Critical bugs here that make mk-configure a nightmare for cross compiling or using any other compiler than the system compiler
Using a non-system compiler is not a problem at all. You may run mkc_compiler_settings utility like the following
$ CC=non-system-cc CXX=non-system-CC mkc_compiler_settings
As a result a configuration file will be created. Then, it will be possible to use any compiler you want. Again, the problem with cross-compiler with the same version is still actual. Also, see the documentation for MKCOMPILERSETTINGS variable. You may set it to YES in your .profile
Yeah I didn't get to read about MKCOMPILERSETTINGS ... there are like 40 advanced build systems with very specific documentation, I must admit that I didn't read the whole mk-configure manual, just like I haven't read the whole bmake manual
MKCOMPILERSETTINGS compiler settings should default to yes, why? Because it's only run once, once the global specs file for the compiler is created... it's never updated
Yep I compiled a lib 3 times, and mkc_compiler_settings just ran 1 time? The specs check appeared only 1 time
Well, that fixes one issue... well for me, but many others will still don't know what to do, it's in the best interests of this project to automate everything, people are beginning to use it, not by choice
I disagree. This file should be generated once at build and installation time in order to avoid its generation by user. The problem with cross-compilation is different and will be fixed in a different way.
This is worrying, people may cross compile a whole system to run on another machine... mk-configure is just another package, so the system compiler settings will contain info about the cross compiler
That's why it should go to home, that compiler settings file is never updated, so it's ok to have it in $HOME, and remove it when needed to force the creation of a new file... it only happens 1 time
I don't know, this is not an autotools replacement, it's behavior is completely different and incompatible
The biggest problem here is that mkc_imp.cc_gcc-X.X.X.mk doesn't take into account the target triplet (i.e i686-linux-musl, i686-linux-gnu, i686-w64-mingw32, etc), it assumes all compilers with the same version share the same specs, and that is completely and absolutely wrong
Have a look at the latest changes in master branch. This problem should be fixed now.