Created attachment 933466 [details] Test case Description of problem: When cross-compiling a C++ project with MinGW that uses CMake as the build system then no matter what CMAKE_BUILD_TYPE one uses, debug symbols always get included. Version-Release number of selected component: mingw-filesystem 99-1 How reproducible: always. Steps to Reproduce: 1. Have a minimal CMake based C++ project (extract the one from the attachment) in $TEST_DIR 2. cd $TEST_DIR && mkdir build && cd build && mingw32-cmake -DCMAKE_BUILD_TYPE=MinSizeRel .. && mingw32-make 3. Observe the compilation commands executed by make Actual results: the -g flag is included in the compiler flags Expected results: since this is a minimal release build we are asking, no extra symbols should be included: the -g flag should not be there. Additional info: The -g flag originates from /etc/rpm/macros.mingw32 file where it's set for the %mingw32_cflags macro. It seems that this macro is used in every kind of build that is made. Possibly affects C projects also and possibly doesn't need CMake to be involved, but this is how I found this out. If doing a regular build (i.e. not cross-compiling and building for the host environment) then similar commands to step 2 above (cd $TEST_DIR && mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=MinSizeRel .. && make) produce a build where the -g flag is not set. This is as expected.
Although this bug only mentions the -g flag that gets added to the builds I think that actually all the compiler flags that macros.mingw32 (or macros.mingw64) set should not be there. The flags are currently: -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions --param=ssp-buffer-size=4 While these flags could be useful in some situations and their usage can be justified many times, it is not the job of the build framework to force them. The control should always stay on the user to be able to fully specify the build process (including compiler parameters). Hence I would actually propose that all of them should be removed from the macros.
Even more, the %mingw32_cmake macro (which I understand is used when the mingw32-cmake command is used) forces -DCMAKE_VERBOSE_MAKEFILE=ON and -DBUILD_SHARED_LIBS:BOOL=ON. I don't think these should be there either.
This bug is similar to 987644. The main 'issue' is that the mingw32-cmake/mingw64-cmake wrapper scripts use the RPM macros %mingw32_cmake/%mingw64_cmake to generate the complete cmake command. The RPM macros %mingw32_cmake/%mingw64_cmake are based on the RPM macro %cmake (/usr/lib/rpm/macros.d/macros.cmake) and thus their behaviour is also the same. When building RPMs it is needed to build with debug symbols by default, to use the recommended compiler flags and also to perform verbose builds. I don't plan on changing this. The behaviour of the wrapper script could be changed to a minimal variant, but a method has to be found to keep the behaviour of the RPM macros intact and without duplication of code...
This makes me think that perhaps the mingw32-* commands shouldn't be used by the users of mingw (in Fedora) in the first place. It seems that they are tuned for building various rpm packages. I tried to build a more complex project using the standard cmake giving it -DCMAKE_TOOLCHAIN_FILE=/usr/share/mingw/Toolchain-mingw32.cmake argument but this failed because cmake failed to find the freetype package (which is one of the requirements for this project). Freetype just happens to be the first package that is requested with a find_package() cmake command so I'm assuming that the same failure would happen with the other required packages too and this isn't anything freetype specific. So I guess there's something different in the environment when run via mingw32-cmake and pure cmake. I tried to set some environment variables (PATH and PKG_CONFIG_LIBDIR) according to the output of `rpm --eval %{mingw32_cmake}` but couldn't yet figure out a working environment. Assuming I failed just because of some environment issue, could there be some "setup MinGW environment" script that would set the environment correct?
This message is a notice that Fedora 19 is now at end of life. Fedora has stopped maintaining and issuing updates for Fedora 19. It is Fedora's policy to close all bug reports from releases that are no longer maintained. Approximately 4 (four) weeks from now this bug will be closed as EOL if it remains open with a Fedora 'version' of '19'. Package Maintainer: If you wish for this bug to remain open because you plan to fix it in a currently maintained version, simply change the 'version' to a later Fedora version. Thank you for reporting this issue and we are sorry that we were not able to fix it before Fedora 19 is end of life. If you would still like to see this bug fixed and are able to reproduce it against a later version of Fedora, you are encouraged change the 'version' to a later Fedora version prior this bug is closed as described in the policy above. Although we aim to fix as many bugs as possible during every release's lifetime, sometimes those efforts are overtaken by events. Often a more recent Fedora release includes newer upstream software that fixes bugs or makes them obsolete.
Fedora 19 changed to end-of-life (EOL) status on 2015-01-06. Fedora 19 is no longer maintained, which means that it will not receive any further security or bug fix updates. As a result we are closing this bug. If you can reproduce this bug against a currently maintained version of Fedora please feel free to reopen this bug against that version. If you are unable to reopen this bug, please file a new report against the current release. If you experience problems, please add a comment to this bug. Thank you for reporting this bug and we are sorry it could not be fixed.
mingw-filesystem-100-1.fc22 has been submitted as an update for Fedora 22. https://admin.fedoraproject.org/updates/mingw-filesystem-100-1.fc22
mingw-filesystem-100-1.fc21 has been submitted as an update for Fedora 21. https://admin.fedoraproject.org/updates/mingw-filesystem-100-1.fc21
mingw-filesystem-100-1.fc20 has been submitted as an update for Fedora 20. https://admin.fedoraproject.org/updates/mingw-filesystem-100-1.fc20
mingw-filesystem-100-1.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.
mingw-filesystem-100-1.fc21 has been pushed to the Fedora 21 stable repository. If problems still persist, please make note of it in this bug report.
mingw-filesystem-100-1.fc20 has been pushed to the Fedora 20 stable repository. If problems still persist, please make note of it in this bug report.