Bug 1136069

Summary: CMake C++ project is always built with debug symbols on
Product: [Fedora] Fedora Reporter: Aki Koskinen <redhat>
Component: mingw-filesystemAssignee: Erik van Pienbroek <erik-fedora>
Status: CLOSED ERRATA QA Contact: Fedora Extras Quality Assurance <extras-qa>
Severity: unspecified Docs Contact:
Priority: unspecified    
Version: 19CC: drizt72, erik-fedora, kalevlember, rjones
Target Milestone: ---   
Target Release: ---   
Hardware: x86_64   
OS: Linux   
Fixed In Version: mingw-filesystem-100-1.fc20 Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of: Environment:
Last Closed: 2015-02-18 11:03:25 UTC Type: Bug
Regression: --- Mount Type: ---
Documentation: --- CRM:
Verified Versions: Category: ---
oVirt Team: --- RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: --- Target Upstream Version:
Description Flags
Test case none

Description Aki Koskinen 2014-09-01 14:56:10 UTC
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.

Comment 1 Aki Koskinen 2014-09-02 07:24:29 UTC
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.

Comment 2 Aki Koskinen 2014-09-02 07:38:23 UTC
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.

Comment 3 Erik van Pienbroek 2014-09-02 08:15:11 UTC
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...

Comment 4 Aki Koskinen 2014-09-02 12:35:01 UTC
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?

Comment 5 Fedora End Of Life 2015-01-09 22:25:25 UTC
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.

Comment 6 Fedora End Of Life 2015-02-18 11:03:25 UTC
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

Thank you for reporting this bug and we are sorry it could not be fixed.

Comment 7 Fedora Update System 2015-04-11 20:33:53 UTC
mingw-filesystem-100-1.fc22 has been submitted as an update for Fedora 22.

Comment 8 Fedora Update System 2015-04-11 20:34:34 UTC
mingw-filesystem-100-1.fc21 has been submitted as an update for Fedora 21.

Comment 9 Fedora Update System 2015-04-11 20:35:05 UTC
mingw-filesystem-100-1.fc20 has been submitted as an update for Fedora 20.

Comment 10 Fedora Update System 2015-04-21 18:28:17 UTC
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.

Comment 11 Fedora Update System 2015-04-21 19:00:12 UTC
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.

Comment 12 Fedora Update System 2015-04-21 19:13:05 UTC
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.