qmake build lib without automatic lib prefix

[mcarter]

Forum is a little hard to search so sorry if this has been asked before

I am trying to create a .pro file that can used used on multiple platforms to build a library (MyLib.so,MyLib.dll,...). Seems fairly easy with qmake and it all works, except that the name of the library has a prefix 'lib' when built on a *nix system (libMyLib.so). And this might be okay except for the fact that I am using QLibrary to load the library and trying to use a common name: Qlibrary mylib("MyLib"). While QLibrary does try different extensions (.so,.dll), it does not try to add a 'lib' prefix. So is there a way to have qmake build a lib with a name that I specifically want?

[wysota]

You can force it to do it but it is a bad idea. It is a well established scheme to prefix libraries on Unix with "lib". It's much easier to convince QLibrary to use a proper name:


QLibrary loader;
#ifdef Q_OS_UNIX
loader.setFileName("libMyLib");
#else
loader.setFileName("MyLib");
#endif

[mcarter]

While I agree its a well established scheme on *nix systems to prefix with "lib", it should not be forced on you. If there is a legitimate need to have a library be named a certain way based on project need, you should be able to do that. Knowing that qmake forces that, I can work around it . . . mainly for project use of loading library at runtime with QLibrary.

It also seems that qmake will use the VERSION on a windows build to tack on a version major number to the library name. I had to work around that as well . . . good thing that if you leave it blank it will not generate one on its own.

So now I have the following in my .pro file to build the same name across my platforms [linux/mac/windows], all with lib- prefix:


win32 {
TARGET = lib$$qtLibraryTarget($$TARGET)
} else {
TARGET = $$qtLibraryTarget($$TARGET)
VERSION = $$system(awk \'/const VERSION/ { print substr( $6, 3 ) }\' main.cpp)
# clean up shared libs as version number changes
QMAKE_DISTCLEAN += *.so*
}
TEMPLATE = lib

The only ugliness that I have seen from this is that in a mingw build on windows, there is a temporary library .a that is created before making the .dll that qmake forces to have a lib prefix, so the temp name is liblibNAME.a. Since it is temp, I am not worrying to much about that.

My description was for a simple case. Eventually the name will be changed so the #if method will not work. I guess I could have subclassed QLibrary to try additional prefixes, but this seems to work for now.

[wysota]

Knowing that qmake forces that, I can work around it
Nothing forces it. It's just the default setting for qmake.


Eventually the name will be changed so the #if method will not work.
It will work if you do it properly (e.g. using defines).

[ChrisW67]

It also seems that qmake will use the VERSION on a windows build to tack on a version major number to the library name.
It does this for a very good reason: DLL hell is not much fun. The version number allows you to distinguish libraries built with incompatible interfaces.

[mcarter]

It does this for a very good reason: DLL hell is not much fun. The version number allows you to distinguish libraries built with incompatible interfaces.
I agree DLL hell is not fun at all. I like that fact the VERSION is embedded into the DLL. However, I do not want to be forced (hard-coded in the qmake source code if VERSION is used) to a specific naming convention. It would nice to figure out how to get the version back into dll without using VERSION.

[wysota]

It would nice to figure out how to get the version back into dll without using VERSION.
This seems a bit contradictory. By the way, is there a specific reason why you are using QLibrary instead of other solutions of using a library in your program?

[mcarter]

It would nice to figure out how to get the version back into dll without using VERSION.

This seems a bit contradictory. By the way, is there a specific reason why you are using QLibrary instead of other solutions of using a library in your program?
It sounded strange even as I wrote it. Since using VERSION in the .pro file causes qmake to append the major number to the library name, I wanted to avoid using it, but qmake uses the VERSION to embed into dll. I wanted to do the latter and avoid the library name change.

For my application, I can connect to multiple sources. Each of the sources is a "library" that implements the application API to gather data for displaying. The app is to be used on multiple platforms all using the same config file. That is the reason for one common name across platforms.

I am using QLibrary to load the library at run-time. Using Qt, I thought that was the easiest to implement. Everything was there for cross-platform. I was trying to avoid writing my own. Is there a better solution?

[wysota]

Since using VERSION in the .pro file causes qmake to append the major number to the library name, I wanted to avoid using it, but qmake uses the VERSION to embed into dll. I wanted to do the latter and avoid the library name change.
That doesn't avoid DLL hell (at least not without a dedicated manifest).


For my application, I can connect to multiple sources. Each of the sources is a "library" that implements the application API to gather data for displaying. The app is to be used on multiple platforms all using the same config file. That is the reason for one common name across platforms.

I am using QLibrary to load the library at run-time. Using Qt, I thought that was the easiest to implement. Everything was there for cross-platform. I was trying to avoid writing my own. Is there a better solution?

Wouldn't it be easier to use plugins? QLibrary requires you to resolve all the symbols manually. You don't have to do that with QPluginLoader (which internally uses QLibrary). The additional benefit is that if you build a library as a plugin, it solves all your other problems automatically -- qmake doesn't prefix it with "lib" on Unices and (afair) doesn't append the version number on Windows.

[mcarter]

Wouldn't it be easier to use plugins? QLibrary requires you to resolve all the symbols manually. You don't have to do that with QPluginLoader (which internally uses QLibrary). The additional benefit is that if you build a library as a plugin, it solves all your other problems automatically -- qmake doesn't prefix it with "lib" on Unices and (afair) doesn't append the version number on Windows.
Alas, these libraries are not Qt based. :( With the api, the libraries can be created by any number of developers, who may or may not have Qt. The lowest common denominator was not to wrap the library in Qt. That may change in the future, but for now I do not think I can use QPluginLoader unless it is purely Qt-based.