Question

I have a following question about linking on Linux:

Suppose I have a class Foo that uses Qt. To build this class I’d have to use qmake to generate Makefile.

Later on I want to use this class Foo for a Perl module, which is a shared library. However, to build it I have to use Perl’s MakeMaker to generate Makefile of it’s own.

The way I’m doing it right now is that I build class Foo as a static library, and when building Perl module’s shared library I’m linking it against Foo’s static library.

The problem is that when building Perl module’s shared library I have to link it against all those Qt libraries that Foo’s static library is linked against.

So the question is:

1. Does this approach even make sense?!

2. Is it possible to build Foo’s static library in a way that I wouldn’t have to specify all it’s dependencies when building the Perl module’s shared library? (Because it is somewhat hard to add all those dependencies to module’s Makefile)

3. Would it be any different if Foo’s library was shared, not static?

Answer 1

1) You can’t link a static library against a shared library.

2) You would not need to explicitly link against Foo‘s dependencies if Foo itself was a DSO

3) You can easily modify the Makefile.PL LIBS section to add extra linker dependencies.

4) Qt is a downright pain to link statically anyway. You’re better off just doing the whole dynamic shebang unless you have specific version dependencies and OS/platform limitations. Hint: Even if you do have a ‘static’ build of Qt, this ‘static’ build won’t include things which it might decides need to be present as loadable modules. Been there.

5) I believe there’s a CPAN module (somewhat recent) which provides Qt4 bindings. I’ve never used it and don’t know its status, but it may be worth checking out.

But your best bet is to make Foo a dynamic library.. everyone’s happy then.