Details
-
Bug
-
Resolution: Cannot Reproduce
-
Not Evaluated
-
None
-
0.3
-
None
-
Windows 7 (64-bit), MinGW-w64 (64-bit)
Description
Just stumbled across annoying blocker.
StaticLibrary { Depends { name: 'cpp' } Depends { name: 'Qt.core' } name: 'A' destination: 'lib' files: ['sources/**'] ProductModule { Depends { name: 'cpp' } cpp.includePaths: ['includes'] } }
DynamicLibrary { Depends { name: 'cpp' } Depends { name: 'A' } Depends { name: 'Qt.core' } name: 'B' destination: qbs.targetOS === 'windows' ? 'bin' : 'lib' files: ['sources/**'] }
Now Qbs will try to prepend -l before the absolute path to the A library when linking it to B.
This is very unfortunate because, for example, when I link some dynamic library to application in the same way as above (using ProductModule) - everything is fine, i.e. it does not prepend -l to absolute path of the dynamic library during linking.
I've tried to fix this bug myself, but I was out of luck. However, what was really surprising is this: go to share/qbs/modules/cpp/gcc.js line #11:
for (i in staticLibraries) { if (FileInfo.isAbsolutePath(staticLibraries[i])) { // <--- here args.push(staticLibraries[i]); } else { args.push('-l' + staticLibraries[i]); } }
clearly this line is supposed to handle this case. However:
for (i in staticLibraries) { if (FileInfo.isAbsolutePath(staticLibraries[i])) { args.push(staticLibraries[i]); } else { print('--->' + staticLibraries[i]); // <--- prints A args.push('-l' + staticLibraries[i]); } }
reveals that library with absolute path does not pass this check:
--->D:/Users/Haroogan/Projects/Test/build/qt-4-8-4-x64-debug/lib/libA.a
I checked isAbsolutePath function as well and it seems OK too. I'm completely lost where you have missed something. Anyway, you know the code better so I'd rather leave it to you.
Another interesting point:
for (i in dynamicLibraries) { if (FileInfo.isAbsolutePath(dynamicLibraries[i])) { args.push(dynamicLibraries[i]); } else { args.push('-l' + dynamicLibraries[i]); } }
is the same loop, but for dynamic libraries. Recall I said that linking dynamic library to application (using ProductModule too) does not prepend -l. Curiously, such dynamic library does not appear in this loop at all. I was confused which code path (bypassing above snippet) it takes to end up in the command line without -l. Probably, this is due to the differences in the code between dynamic library linker (used in the 1st case) and application linker (used in this case). But this is just to give you some thoughts on where to seek for a possible bug.