| Summary: | x11-libs/qt-core-4.6.3 - qmake generates incorrect Makefile with CONFIG+=debug | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Egor Y. Egorov <egorov_egor> |
| Component: | Current packages | Assignee: | Qt Bug Alias <qt> |
| Status: | RESOLVED FIXED | ||
| Severity: | normal | CC: | jer, sh |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: |
traceback
qt-core-4.6.3-add-ignore-predefined-cflags-options.patch sip-4.10.5-add-ignore-predefined-cflags-options.patch qt-core-4.6.3-add-ignore-predefined-cflags-options.patch qt-core-4.6.3-add-ignore-predefined-cflags-options.patch proposed patch |
||
|
Description
Egor Y. Egorov
2010-07-23 07:08:34 UTC
It shouldn't as far as I am aware. -g should be added through CFLAGS as a general Gentoo policy, and never through USE=debug. I should explain.
This is manifested during the development on Qt4.
For example I create simple project:
eegorov@egorov-ey /tmp/123 $ cat main.cpp
#include <stdio.h>
int main()
{
return 5+4;
}
eegorov@egorov-ey /tmp/123 $ cat main.pro
CONFIG+=debug
CONFIG-=gui
SOURCES += main.cpp
TARGET = test1
eegorov@egorov-ey /tmp/123 $ qmake && make && gdb test1
GNU gdb (Gentoo 7.1 p1) 7.1
Copyright (C) 2010 Free Software Foundation, Inc.
License GPLv3+: GNU GPL version 3 or later <http://gnu.org/licenses/gpl.html>
This is free software: you are free to change and redistribute it.
There is NO WARRANTY, to the extent permitted by law. Type "show copying"
and "show warranty" for details.
This GDB was configured as "x86_64-pc-linux-gnu".
For bug reporting instructions, please see:
<http://bugs.gentoo.org/>...
Reading symbols from /tmp/123/main...(no debugging symbols found)...done.
(gdb)
So I can not carry out debugging of my application.
The reason for this - lack of key "-g" in Makefile:
eegorov@egorov-ey /tmp/123 $ grep ^CFLAGS Makefile
CFLAGS = -pipe -Wall -W -D_REENTRANT $(DEFINES)
Should be:
eegorov@egorov-ey /tmp/123 $ grep ^CFLAGS Makefile
CFLAGS = -pipe -g -Wall -W -D_REENTRANT $(DEFINES)
(In reply to comment #1) > It shouldn't as far as I am aware. -g should be added through CFLAGS as a > general Gentoo policy, and never through USE=debug. > Exactly. qt4-build.eclass strips C{,XX}FLAGS from mkspecs for that reason. This bug is invalid IMHO. (In reply to comment #2) That's not an issue at all. Just put: QMAKE_CXXFLAGS_DEBUG += -g (or -ggdb) in your .pro file. http://doc.qt.nokia.com/4.6/qmake-manual.html If this is not a bug, it is necessary to document this feature in Gentoo, IMHO, because http://doc.qt.nokia.com/4.6/qmake-manual.html says: QMAKE_CFLAGS_DEBUG This variable contains the flags for the C compiler in debug mode.The value of this variable is typically handled by qmake or qmake.conf and rarely needs to be modified. (In reply to comment #4) > (In reply to comment #2) > > That's not an issue at all. Just put: > QMAKE_CXXFLAGS_DEBUG += -g (or -ggdb) > in your .pro file. > > http://doc.qt.nokia.com/4.6/qmake-manual.html > Adding this to .pro not allowed because this project will not be cross-platform Use conditional scopes... (In reply to comment #7) > Use conditional scopes... > I do not think this idea reasonable. Qt4 itself well does this work. In my opinion, portage did not have to rebuild Qt4 to fit your needs. He has to use Qt4 as he has. Now the algorithm of the qmake on Gentoo differs from the algorithm on any other platforms. We must not forget that qmake used not only for the Portage. No, the algorithm hasn't been modified. We just changed some configuration details. You can't rely on such things anyway, since they may be different on different machines. (In reply to comment #9) > No, the algorithm hasn't been modified. We just changed some configuration > details. You can't rely on such things anyway, since they may be different on > different machines. > qmake CONFIG+=debug && make on all platforms should compile the project with debug http://doc.qt.nokia.com/4.6/qmake-variable-reference.html#config Could you show me the point where it says that CONFIG+=debug adds -g to CFLAGS please? Note that "compiling in debug mode" is very different from "compiling with debug info". (In reply to comment #11) > Could you show me the point where it says that CONFIG+=debug adds -g to CFLAGS > please? > Could you show me the point where it say that QMAKE_CFLAGS_DEBUG need be redefined? http://doc.qt.nokia.com/4.6/qmake-tutorial.html#making-an-application-debuggable (In reply to comment #12) > Note that "compiling in debug mode" is very different from "compiling with > debug info". > No comment. http://bugs.gentoo.org/show_bug.cgi?id=312689 @Davide Pesavento You'll continue to say that everything is OK? I've never said that everything is OK. The only thing I know is that qmake sucks (and SIP is even worse wrt bug #312689). Anyway, you're making the problem bigger than it is and that's not helping us. If you want complete control over which CFLAGS are used in your project, you should be prepared to do that. I've seen a lot of projects doing so. Or you could suggest a solution that works for both portage builds and "personal" use. (In reply to comment #16) > The only thing I know is that qmake > sucks (and SIP is even worse wrt bug #312689). This is a topic for separate discussion. > If you want complete control over which CFLAGS are used in your project, you > should be prepared to do that. I've seen a lot of projects doing so. Agreed. But this does not negate the fact that qmake in Gentoo does not operate as intended. > Or you could suggest a solution that works for both portage builds and > "personal" use. I think about it. And I'm ready to help as I can. However, I beg to acknowledge that a problem exists. I propose an alternative.
Create a new mkspec:
egorov-ey usr # ls -l /usr/share/qt4/mkspecs/gentoo_portage
итого 0
-rw-r--r-- 1 root root 143 Июл 28 16:51 qmake.conf
lrwxrwxrwx 1 root root 26 Июл 28 16:52 qplatformdefs.h -> ../default/qplatformdefs.h
egorov-ey usr # cat /usr/share/qt4/mkspecs/gentoo_portage/qmake.conf
include(../default/qmake.conf)
QMAKE_CFLAGS_RELEASE =
QMAKE_CFLAGS_DEBUG =
QMAKE_CXXFLAGS_RELEASE =
QMAKE_CXXFLAGS_DEBUG =
load(qt_config)
Fixes qt4-r2.eclass:
- "${EPREFIX}"/usr/bin/qmake -makefile -nocache \
+ "${EPREFIX}"/usr/bin/qmake -makefile -spec gentoo_portage -nocache \
In the case of PyQt4 fixes configure.py:
- return args
+ return "-spec gentoo_portage %s" % (args)
What do you say?
...оr just in qt4-r2.eclass to determine variable QMAKESPEC=gentoo_portage (In reply to comment #18) > I propose an alternative. > > Create a new mkspec: > egorov-ey usr # ls -l /usr/share/qt4/mkspecs/gentoo_portage > итого 0 > -rw-r--r-- 1 root root 143 Июл 28 16:51 qmake.conf > lrwxrwxrwx 1 root root 26 Июл 28 16:52 qplatformdefs.h -> > ../default/qplatformdefs.h This sounds good to me. qmake is not only a tool for allowing portage to portage to generate makefiles for its own packages. It is also a valid application for any user to use outside of portage and as such I would hope for it to behave like qmake on pretty much every other platform - which is to add suitable compiler flags when building debug or release builds. If portage needs something different than the widely accepted default behaviour, then portage should be the thing to jump through the extra hoops, not the users. Having said that, Egor's solution does not require much hoop jumping at all for portage and so seems a good way forwards to me. Tracking this down has cost me a whole day of debugging - I was getting mislead due to having the same package installed on two systems one which behaved as expected and one which has the new broken (IMHO) behaviour due to the qt4-build.eclass file change. Created attachment 240641 [details]
traceback
(In reply to comment #18) I had that idea too, but I'm afraid it wouldn't work. A lot of qmake project files use conditional scopes based on the currently active mkspec tuple [1]. Therefore passing '-spec gentoo_portage' would break virtually every build system out there. [1] http://doc.qt.nokia.com/4.6/qmake-advanced-usage.html#platform-scope-values (In reply to comment #22) > (In reply to comment #18) > > I had that idea too, but I'm afraid it wouldn't work. > A lot of qmake project files use conditional scopes based on the currently > active mkspec tuple [1]. Therefore passing '-spec gentoo_portage' would break > virtually every build system out there. > > [1] http://doc.qt.nokia.com/4.6/qmake-advanced-usage.html#platform-scope-values > And if you do so? sed "s/linux-g++/gentoo_portage/g" -i "${S}/*.pro" (In reply to comment #23) No, I don't like that: too hackish and too fragile. What I propose is to partially revert the C(XX)FLAGS stripping currently performed by qt4-build.eclass and just remove the flags from QMAKE_C{,XX}FLAGS_RELEASE variables, thus leaving debug variables as shipped by upstream. (In reply to comment #24) > (In reply to comment #23) > > No, I don't like that: too hackish and too fragile. > > What I propose is to partially revert the C(XX)FLAGS stripping currently > performed by qt4-build.eclass and just remove the flags from > QMAKE_C{,XX}FLAGS_RELEASE variables, thus leaving debug variables as shipped by > upstream. > That's reasonable. However, I think the question should be left open. Created attachment 240803 [details]
qt-core-4.6.3-add-ignore-predefined-cflags-options.patch
Please, test this patch for qt-core-4.6.3
If environment variable QMAKE_IGNORE_PREDEFINED_CFLAGS defined and not empty, qmake will ignore the predefined CFLAGS in mkspec.
That doesn't solve the issues with SIP-based packages. (In reply to comment #27) > That doesn't solve the issues with SIP-based packages. > Why? SIP does not see the environment variables? Not without patching I guess... How many SIP-based packages in the portage? Maybe there is such a way to fix SIP... Now I'll see what it was... Created attachment 240841 [details]
sip-4.10.5-add-ignore-predefined-cflags-options.patch
Please test.
This path allow make
QMAKE_IGNORE_PREDEFINED_CFLAGS=yes CFLAGS="-g -O0" CXXFLAGS="-g -O0" ebuild /usr/portage/dev-python/PyQt4/PyQt4-4.7.3.ebuild clean compile
right
Created attachment 240845 [details]
qt-core-4.6.3-add-ignore-predefined-cflags-options.patch
The variable QMAKE_IGNORE_PREDEFINED_CFLAGS is no longer obliged to be non-empty
Created attachment 240943 [details]
qt-core-4.6.3-add-ignore-predefined-cflags-options.patch
Sorry. In the previous patch error.
The patch sip-4.10.5-add-ignore-predefined-cflags-options.patch has been tested by me on all versions of SIP in portage. I think this is a better solution than the one that exists now. The Qt team decided to implement what I proposed in comment #24. Created attachment 245844 [details, diff]
proposed patch
Davide, how about this patch?
(In reply to comment #36) > Created an attachment (id=245844) [details] > proposed patch > > Davide, how about this patch? > Perfect! Patch applied You need to rebuild qt-core for these changes to take effect |
