Merging static libraries in a shared library with qmake -- empty result

[yeye_olive]

I am using qmake to build a project that consists of two applications (say A and B). In order to keep the structure clear, I divided the project in components using a subdirs template for the top level .pro file. Those components can be partitioned in three groups:
1) those that will be used by application A only,
2) those that will be used by application B only,
3) those that will be used by both.

I would like to build all components in group 3 as static libraries, then combine them in a large shared library that applications A and B would link to. I have not found anywhere how to achieve that with qmake. If I try something along the lines of

TEMPLATE = lib
 
CONFIG += shared
 
LIBS += \
	-lComponent_1_built_as_static_lib \
	-lComponent_2_built_as_static_lib \
	...
	-lComponent_n_built_as_static_lib

TEMPLATE = lib

CONFIG += shared

LIBS += \
	-lComponent_1_built_as_static_lib \
	-lComponent_2_built_as_static_lib \
	...
	-lComponent_n_built_as_static_lib

To copy to clipboard, switch view to plain text mode 

where Component_1_built_as_static_lib, ..., Component_n_built_as_static_lib are the static libraries corresponding to the components in group 3, I do get a shared library but it is empty; linking applications A and B obviously fails with unresolved symbols.

My guess is that the linker only picks what it needs from Component_1_built_as_static_lib, ..., Component_n_built_as_static_lib when building the shared library, but that library does not contain source files itself. Therefore I end up with nothing. How can I force qmake to act dumb and pick everything instead?

For the record, I use Qt 4.6.3 with gcc 4.4.5 and Linux 2.6.32.

Best regards, Olivier.

[Timoteo]

I think you are guessing right as to the cause (linker reference optimization). The right answer (IMO) is to build the shared library directly from source of group 3. You can try forcing the linker to resolve a symbol (for instance taking the address of an external function or declaring reference variable for external class). This doesn't necessarily have to work, though. Once the linker sees that the symbol is not being referenced by something that the library itself is exporting, there's no reason that it cannot just drop it.

[yeye_olive]

Thanks, Timoteo. I ended up building the shared library from source, which solved the issue. Alternatively, in order to force the linker to export some classes I was thinking of simply defining factory functions for them in the library.