Hi, the qt ebuild respects the 'debug' use flag. It is translated to the qt '-debug-and-release' configure option. With this option every .so is built a 2nd time with debug information. The debug version of libQtFoo.so is called libQtFoo_debug.so. The portage 'install' action (like in 'ebuild ... install) strips _every_ .so files. Thus the 2nd built was just a waste of time. I guess you can work around this, by adding the 'nostrip' option to your make.conf. But if an ebuild provides a debug option (via use flag), it is responsible to install the debug stuff (IMHO). Regards Georg Sauthoff
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?
