Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.10, 5.12.0
-
None
-
-
8ffb200153d1b1a8402c875c4961160efb149201 (qt/qtbase/5.13)
Description
I realized that enabling -lctg in my Qt build on macos made dumping the symbols in my crash reporting system dysfunctional.
When adding -separate-debug-info to ./configure qmake produces a warning:
mkdir -p BUILD_DIR/qtbase/lib/QtCore.framework.dSYM/Contents/Resources/DWARF && dsymutil ../../lib/QtCore.framework/Versions/5/QtCore --flat -o ../../lib/QtCore.framework.dSYM/Contents/Resources/ DWARF/QtCore && strip -S ../../lib/QtCore.framework/Versions/5/QtCore warning: (x86_64) /tmp/lto.o unable to open object file: No such file or directory warning: no debug symbols in executable (-arch x86_64)
This can be worked around by adding -Wl,-object_path_lto,lto.o to QMAKE_LFLAGS_LTCG.
A correct fix is probably more involved and I don't know much about qmake internals, which is why I'm posting the report here instead of sending a PR. At least the following questions came to my mind:
- lto.o is obviously a hardcoded filename, is that ok to use? have targets their own build directory or is there a danger of name clashes?
- what's the proper way of checking that debug output should be generated and the linker flag should be applied? there are at least debug and release with debug info builds that would need this
- maybe -force-debug-info should imply -separate-debug-info if using -ltcg? otherwise the debug info is of really limited usage...
- do we need to check for the availability of the linker flag?
- Which mkspecs should this behavior be shared among?
- how can we make sure this doesn't break again?
All I've said refers to and is tested on macx-clang target with AppleClang on macos High Sierra.