2

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?

eyevan
  • 1,475
  • 8
  • 20

2 Answers2

2

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.

Mark Nunberg
  • 3,551
  • 15
  • 18
  • Yeah, I know. Static linking of Qt is pain. I guess I'll have to stick to shared libraries then. – eyevan Sep 19 '12 at 09:41
1

1) It depends on what your objective is.

2) If it's about minimizing the hassle building it, you could include Qt's static libraries as static to your Foo lib. All that matters is that the symbols you reference in Foo can be found at runtime. That way you won't need to include Qt libs in your PerlMake.

3) If it's about minimizing executable size you'd have to go for shared libraries. Then you should build everything as a shared-lib.

Building statically has the advantage to be independent of installed shared libraries on the target platform, while having the disadvantage of executable-size bloat and non re-usability of libraries (more memory needed to load two same executables).

Linking against shared has the advantage of smaller code size but at the same time the proper shared libs have to be installed on the target platform.

count0
  • 2,537
  • 2
  • 22
  • 30
  • Well, the initial problem was to make those to different ways of generating Makefiles work together. Building static version of Qt might be problematic. For example, the latest version of Qt doesn't support static linking of QtWebkit. So if I stick to building everyhing as shared libraries I would have to drag all those dependencies along? – eyevan Sep 18 '12 at 19:24
  • As far as i understood you're linking Foo statically, so the simplest thing would probably be to add (statically link) all the Qt-libs into your Foo archive. This will result in one big bloated archive though. – count0 Sep 18 '12 at 19:29