qmake: Create dll from lib?

Asperamanca

I would like to generate a dll from a single lib file (Win/VC2010)
I have set

TEMPLATE=dll

and have set correct values on the following variables: LIBS (paths and libraries), DESTDIR, MAKEFILE (only filename), QMAKE_LFLAGS (to set the PDB path)

qmake generates a mak-File, but rejects generating the .mak.Debug and .mak.Release files with the error

WARNING: Unable to generate output for: <correct path>/<correct filename>.mak.Debug [TEMPLATE dll]
WARNING: Unable to generate output for: <correct path>/<correct filename>.mak.Release [TEMPLATE dll]

I have activated -d option to get debug output, but (at least around the warning lines) I don't see anything that would explain it.

Any ideas where I could look?

SGaist

Hi,

The template is lib whether it's a static or dynamic lib doesn't matter.

If you don't get any .dll, did you properly do the classes exportation ?

Asperamanca

Right, I don't do classes exportation. And it won't make sense for what I try to achieve:
My intention isn't really building a dll, but to build a single library in a way so missing external dependencies become visible. This would allow me to trace dependencies between libs.
My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

raven-worx

@Asperamanca
should be:

TEMPLATE = lib

From where do you have the dll value?!

Edit: oops, way too late. Don't know what went wrong here.

SGaist

On Windows, if you don't export anything then there's no .dll created since there's nothing to "share". Why won't it make sense since it's what you need to achieve what you want ?

Qt provides the necessary macros that you can easily incorporate into your code.

It's all described here

Asperamanca

I don't see how to use the macros to simply export all symbols?

Edit: Ok, maybe I should elaborate: My goal is to make dependencies of a library visible. Linking it to a lib doesn't do that. Linking it to a dll would. However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

kshegunov

@Asperamanca

Linking it to a lib doesn't do that. Linking it to a dll would.

This doesn't make any sense. You always (at least when working with MS's tools) link with the help of a .lib file even when linking against a .dll. There are 2 types of .lib files - a static library and an import library (for a .dll). So what are you having?

However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

It probably would, as @SGaist is correct - not exporting anything from a library will cause MS's linker to not produce a binary at all. But taking in mind this:

My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

Then you can just export a single dummy, thus tricking the linker to generate the binary, and ultimately it will fail on the unresolved externals.

Asperamanca

@kshegunov said:

@Asperamanca

Linking it to a lib doesn't do that. Linking it to a dll would.

This doesn't make any sense. You always (at least when working with MS's tools) link with the help of a .lib file even when linking against a .dll. There are 2 types of .lib files - a static library and an import library (for a .dll). So what are you having?

My thought was to create a dll to make unresolved externals of a library visible (=symbols used by code that is part of the library). Maybe building a DLL is not the way to do it. I certainly have no use for the DLL itself - I currently generate the final executable by directly linking all required libs together.

However, if that would require all code files to be extended with macros exporting symbols (certainly >10000 symbols in total), it wouldn't really be worth it.

It probably would, as @SGaist is correct - not exporting anything from a library will cause MS's linker to not produce a binary at all. But taking in mind this:

My hope was to have a simple way where all symbols within a lib are exported in a dll, which would force the linker to display unresolved externals.

Then you can just export a single dummy, thus tricking the linker to generate the binary, and ultimately it will fail on the unresolved externals.

That sounds interesting, but I don't quite understand what you mean. Because the MS linker seems to ignore all symbols that are not used - and will not display unresolved externals for them. Exporting a single dummy would thus only display dependencies relied upon by that dummy (and the tree of dependencies behind it).

kshegunov

@Asperamanca

I currently generate the final executable by directly linking all required libs together.

Again, are those static libraries? This'd ensure that internally all symbols are resolved. As for the API, you need to link the .dll to the executable so the linker knows what's needed and thus generate errors.

Because the MS linker seems to ignore all symbols that are not used - and will not display unresolved externals for them.

As any linker does. It won't care about a symbol if it isn't referenced anywhere; it may even strip it from the final binary depending on the optimizations.

Exporting a single dummy would thus only display dependencies relied upon by that dummy (and the tree of dependencies behind it).

Yes, most probably I've misunderstood what you want to accomplish.

Asperamanca

I'll try to better explain what I would like to achieve. I'm pretty agnostic about how to achieve it:

I have ~100 static lib projects (in form of .pro files). Plus a dozen or so application projects that include very little code themselves (basically only the main.cpp). The applications link the static libs together to produce the final executables.

So far, so good. It works.

However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

kshegunov

@Asperamanca

I have ~100 static lib projects

Is maintaining that even realistic ...?

However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

Honestly, this sounds like a futile task ... I'd just group up the code into a number of dynamic libraries and resolve the dependency hell by hand and once and for all. I assume that's not what you expect or want, but I really don't think there's a better way in the long run.

These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

Well, you can run an external tool to get the symbol table (undecorated) and ultimately build a fake "linker" yourself. Although, as I said, I'm suspicious of the wisdom of it ...

Kind regards.

Asperamanca

@kshegunov said:

@Asperamanca

I have ~100 static lib projects

Is maintaining that even realistic ...?

Why not? As long as you have a good overview. With less lib projects, there would be more complexity hidden inside the single projects.

However, the static libs have a complex web of dependencies to each other. Library A needs symbols from libraries B, C and D (or alternatively a dummy defined in library Z), Library B needs C, G and X, and in some cases the dependencies form recursions.

Honestly, this sounds like a futile task ... I'd just group up the code into a number of dynamic libraries and resolve the dependency hell by hand and once and for all. I assume that's not what you expect or want, but I really don't think there's a better way in the long run.

The "once and for all" made me chuckle. Things change, the code is in flux. So are the dependencies. I don't bemoan that fact - it's part of life. Just like I wouldn't bemoan getting lost in a foreign city - I would get a map.

There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

These dependencies only become visible when you have a specific linker problem while building an executable. That means, I can fix specific dependency problems as they appear, but I don't really "see" the web of dependencies between the libraries. And I would like to make this web visible - somehow. A start would be a list of symbols a single, isolated library needs. By parsing those lists, I could learn a lot about the inter-dependencies between the libraries, and could start thinking about improving things.

Well, you can run an external tool to get the symbol table (undecorated) and ultimately build a fake "linker" yourself. Although, as I said, I'm suspicious of the wisdom of it ...

Kind regards.

Which "external tool" would that be? Very interested....

kshegunov

@Asperamanca

The "once and for all" made me chuckle.

I'm glad I'm providing quality entertainment.

Things change, the code is in flux. So are the dependencies.
There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

Meaning one should provide API and binary compatibility, at least that's what I'd do, but it's your code and you can manage it as you see fit.

Which "external tool" would that be? Very interested....

Perhaps, this thread might be useful: http://stackoverflow.com/questions/488809/tools-for-inspecting-lib-files

If you're working/listing the symbols on Linux, you can use nm (readelf isn't useful here, as there's no ELF header for archives). I think for OS X the corresponding tool is otool but don't hold me to it. @SGaist can confirm or deny that last piece of information.

Kind regards.

Asperamanca

@kshegunov said:

@Asperamanca

The "once and for all" made me chuckle.

I'm glad I'm providing quality entertainment.

No hard feelings, I hope.

Things change, the code is in flux. So are the dependencies.
There is a good reason not to use dynamic libraries: We need to run different versions of applications side by side, without any hassle. That's very easy to do with a single resulting executable, but hard if you have dynamic libraries.

Meaning one should provide API and binary compatibility, at least that's what I'd do, but it's your code and you can manage it as you see fit.

Well, it's a team thing, too. I feel there is a mess that should be fixed, but to make it happen, I need to provide good arguments and some solid data.

Which "external tool" would that be? Very interested....

Perhaps, this thread might be useful: http://stackoverflow.com/questions/488809/tools-for-inspecting-lib-files

If you're working/listing the symbols on Linux, you can use nm (readelf isn't useful here, as there's no ELF header for archives). I think for OS X the corresponding tool is otool but don't hold me to it. @SGaist can confirm or deny that last piece of information.

Kind regards.

dumpbin -symbols might just provide what I need. Thank you!

kshegunov

@Asperamanca

No hard feelings, I hope.

No, none.

Well, it's a team thing, too. I feel there is a mess that should be fixed, but to make it happen, I need to provide good arguments and some solid data.

I'd think your best argument is any cyclic dependencies you may have. When building as dlls the linker is your last line of defence against having that kind of spaghetti-linkage. Also shared libraries are intended to be shared, which is what you describe, and the OS loader may apply few optimizations when needing to map the same library to memory multiple times.