Summary: | qt-4.1.4 debug build is stripped | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Georg Sauthoff <g_sauthoff> |
Component: | [OLD] Library | Assignee: | Gentoo Linux bug wranglers <bug-wranglers> |
Status: | VERIFIED DUPLICATE | ||
Severity: | normal | ||
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- |
Description
Georg Sauthoff
2006-08-25 16:26:00 UTC
That's what FEATURES="nostrip" is for. Well known and documented at bunch of places, such as http://www.gentoo.org/proj/en/qa/backtraces.xml At least the qt ebuild should print a big fat warning (and abort) if the 'debug' use flag is specified but _not_ the 'nostrip' feature. 'debug' without 'nostrip' really makes no sense. No, it shouldn't. We'd have to change all the ebuilds in portage that have debug, not going to happen. Reopen to dupe. *** This bug has been marked as a duplicate of 79481 *** Well, you could change portage to include such a trivial sanity check (if debug \in USE && nostrip \notin FEATURES then print warning). Then there is no need to fix every single ebuild file, which respects the debug use flag. Why don't you use FEATURES="splitdebug"? Anyway, see Bug 55708 for discussion on this. There's enough kludges in portage already, no need to add another one instead of solving this properly. I do not use 'splitdebug' because the 'debug' use flag enables the '-debug-and-release' qt feature. 'splitdebug' would only be an option, if every qt .so file is just built with debug information.
But with qt this is _not_ the case. qt build process builds with this option for every .so file a 2nd version with a _debug suffix. Thus you have libQtFoo.so without and libQtFoo_debug.so with debug informations.
And 'qmake' depends on this filenames, if the qt project file contains the debug CONFIG directive. With this directive the generated makefile will link against the _debug qt .so files.
> [..] no need to add another one instead of solving this properly.
And what is the proper solution?
Proper solutions are a good thing - but the bug id you referenced is 2 years old. Isn't it a nice thing to warn people, until the real proper solution is integrated?
|