Details
-
Bug
-
Resolution: Done
-
P3: Somewhat important
-
5.5.0
-
None
-
QNX Apps and Media 1.1 (x86 and armle-v7)
-
b474decee308ef5633af9fffaf4bbe5940a66185
Description
I am attempting to create unversioned release libraries (libfoo.so) with separate symbol files. In my project file, I include the following instructions:
# Generate separate debug symbols (*.sym files) for release builds CONFIG(release, release|debug) { # Build release with debug symbols QMAKE_CXXFLAGS_RELEASE += -g QMAKE_CFLAGS_RELEASE += -g # Create the symbol files CONFIG += separate_debug_info } # For the libraries, do not make versioned symlinks # (i.e. libq*.so.1, libq*.so.1.0, libq*.so.1.0.0) CONFIG += unversioned_libname unversioned_soname
When using Qt 5.3.1, this worked as expected. When upgrading to Qt 5.5.0, the symbol stripping is broken with the following error:
ntox86-objcopy: '../../out/libfoo.so.2.2.0': No such file make [ 2 ] : * * * [ ../../out/libfoo.so ] Error 1 make [ 1 ] : * * * [ sub-apps-make_first ] Error 2 mv -f libfoo.so ../../out/ ntox86-objcopy --keep-file-symbols ../../out/libfoo.so.2.2.0 ../../out/libfoo.so.2.2.0.sym && ntox86-objcopy --strip-debug -R.ident ../../out/libfoo.so.2.2.0 && ntox86-objcopy --add-gnu-debuglink=../../out/libfoo.so.2.2.0.sym ../../out/libfoo.so.2.2.0 && chmod -x ../../out/libfoo.so.2.2.0.sym
When I look at /qt5-5.5.0/mkspecs/features/unix/separate_debug_info.prf and compare it to the same file in the Qt 5.3.1 release, I see that the file has changed significantly and that $$QMAKE_RESOLVED_TARGET is being used to determine the name of the library file to strip. That variable obviously contains the fully versioned so name (i.e. libfoo.so.2.2.0). Investigation also indicates that the use of the config options "unversioned_libname" and "unversioned_soname" do not affect the $$QMAKE_RESOLVED_TARGET variable - I gather that some internal qmake magic happens with those config options.
I am hoping that some form of change is possible that allows both of these CONFIG options to co-exist and produce the correct output - however, I am far from an expert in qmake and am not certain what the optimal solution would be.