Bug 2037724

Well, I just found that using '-DCMAKE_CXX_COMPILER_LAUNCHER=ccache' works; but still it'd be better if it can work by default.

FEDORA-2022-2730d809df has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-2730d809df

FEDORA-2022-2730d809df has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-2730d809df`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-2730d809df

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Are we expected to set CC/CXX env variables for it to work? Because, while in https://src.fedoraproject.org/rpms/mingw-filesystem/c/5788afad0b23f2970b6f056f79bfd38aa439a568?branch=f35 the addresses became relative, in https://src.fedoraproject.org/rpms/mingw-filesystem/c/ea5c8fc32e7a792782d6bc63aeafce5c324ca409?branch=f35 they are made absolute again; but it preserves environment variables if defined. So, it seems that if we do not define these variables, the compilers are still sepecified with absolute paths.

The variables need to be a full path according to [1] (and indeed cmake broke when I had set them to relative paths). But, you can use the mingw32-cmake resp mingw64-cmake wrapper scripts to build your project, these scripts set the CC/CXX env-vars as relative paths, and ccache will work.


[1] https://cmake.org/cmake/help/v3.9/variable/CMAKE_LANG_COMPILER.html#variable:CMAKE_%3CLANG%3E_COMPILER

Thanks for your prompt response.

I don't know why, but it doesn't work. I always use mingwXX-cmake wrapper scripts; but it still doesn't use ccache provided symlinks and chooses the compiler in /usr/bin. I even tried to export CXX and MINGW64_CXX variables to ccache links, but it still doesn't use them. Don't know why.

Did you try clearing the CMakeCache folder?

Yes, I create an empty build directory (Not related to this bug, but I wonder if Boost_ARCHITECTURE should also be set in the toolchain file):

hedayat@fedora Projects/powerfake] [master]% cd new.o 
[hedayat@fedora powerfake/new.o] [master]% mingw64-cmake ..
[hedayat@fedora powerfake/new.o] [master]% mingw64-cmake -DBoost_ARCHITECTURE=-x64 ..                                  
-- The CXX compiler identification is GNU 11.2.1
-- Detecting CXX compiler ABI info
-- Detecting CXX compiler ABI info - done
-- Check for working CXX compiler: /usr/bin/x86_64-w64-mingw32-g++ - skipped
-- Detecting CXX compile features
-- Detecting CXX compile features - done
-- Found Boost: /usr/x86_64-w64-mingw32/sys-root/mingw/include (found version "1.75.0") found components: unit_test_framework 
-- Configuring done
-- Generating done
CMake Warning:
  Manually-specified variables were not used by the project:

    CMAKE_INSTALL_LIBDIR
    INCLUDE_INSTALL_DIR
    SHARE_INSTALL_PREFIX
    SYSCONF_INSTALL_DIR


-- Build files have been written to: /home/hedayat/Projects/powerfake/new.o

[hedayat@fedora powerfake/new.o] [master]% make  VERBOSE=1 
[...]
make[2]: Entering directory '/home/hedayat/Projects/powerfake/new.o'
[  5%] Building CXX object CMakeFiles/powerfake.dir/powerfake.cpp.obj
/usr/bin/x86_64-w64-mingw32-g++ -DBOOST_ALL_DYN_LINK  -Wall -Wextra -Woverloaded-virtual -Wpedantic -fstack-protector-strong -std=gnu++17 -MD -MT CMakeFiles/powerfake.dir/powerfake.cpp.obj -MF CMakeFiles/powerfake.dir/powerfake.cpp.obj.d -o CMakeFiles/powerfake.dir/powerfake.cpp.obj -c /home/hedayat/Projects/powerfake/powerfake.cpp

My bad, the syntax for checking whether the env-vars are set was incorrect in the toolchain files. Fixed mingw-filesystem-127-1.fc35 building now.

FEDORA-2022-4083a68332 has been submitted as an update to Fedora 35. https://bodhi.fedoraproject.org/updates/FEDORA-2022-4083a68332

Thanks, tried the changes in the latest commit and it works fine. :)

Sorry to ask again, but isn't it appropriate to also set Boost_ARCHITECTURE in the toolchain file? Without it, boost libraries are not properly found.

BTW, I guess this bug can be closed.

How is your Boost getting detected? /usr/share/cmake/Modules/FindBoost.cmake should already contain code to detect the boost library architecture tag (look for _boost_ARCHITECTURE_TAG).

(This bug will automatically get closed when the update is pushed to stable)

I use this (You can try building this using mingw: https://github.com/hedayat/powerfake):

find_package(Boost REQUIRED COMPONENTS unit_test_framework)

But it doesn't find boost libraries if I don't define Boost_ARCHITECTURE explicitly on cmake command execution.

Apparently, CMAKE_CXX_COMPILER_ARCHITECTURE_ID which is used by FindBoost does not have any values.

Does this help: https://koji.fedoraproject.org/koji/taskinfo?taskID=80997847 ?

Not exactly. When I run mingw64-cmake in an empty build directory, it fails and FindBoost sees an empty CMAKE_CXX_COMPILER_ARCHITECTURE_ID. But if I run mingw64-cmake again in the same directory, it'll see CMAKE_CXX_COMPILER_ARCHITECTURE_ID and detect boost.

Apparently, this is a known bug and specifying Boost_ARCHITECTURE is a workaround specifically for this problem:

https://gitlab.kitware.com/cmake/cmake/-/issues/18553

https://gitlab.kitware.com/cmake/cmake/-/issues/17702

https://gitlab.kitware.com/cmake/cmake/-/issues/17701

Ok, so I guess just setting Boost_ARCHITECTURE as you suggested is the easiest way, please try https://koji.fedoraproject.org/koji/taskinfo?taskID=81000281

Yeah, and I agree that it is an ugly workaround for that cmake bug :(

Anyway, please the it to "-x64" rather than "x64"; and it'll work:

set(Boost_ARCHITECTURE "-x64")

Thanks

And for 32bit mode, it should be "-x32" rather than "x86".

FEDORA-2022-4083a68332 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-4083a68332`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-4083a68332

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

Ok, done in mingw-filesystem-128 proper. Thanks for reporting!

You're welcome, and thank you for your dedication.

FEDORA-2022-b023907185 has been pushed to the Fedora 35 testing repository.
Soon you'll be able to install the update with the following command:
`sudo dnf upgrade --enablerepo=updates-testing --advisory=FEDORA-2022-b023907185`
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2022-b023907185

See also https://fedoraproject.org/wiki/QA:Updates_Testing for more information on how to test updates.

FEDORA-2022-b023907185 has been pushed to the Fedora 35 stable repository.
If problem still persists, please make note of it in this bug report.