5

There are static libraries and then there are shared libraries. Wouldn't it be possible to have just the shared ones and link them in statically if needed?

Compiling once with -fPIC and once without seems like a waste. I don't know much assembly, but shouldn't it be possible to transform rellocatable code into static code orders of magnitude faster than recompiling everything?

Petr Skocik
  • 58,047
  • 6
  • 95
  • 142
  • This answer mentions that it's advisable to compile twice to to avoid the PIC overhead for static libs: http://stackoverflow.com/questions/4863791/creating-both-static-and-shared-c-libraries – Petr Skocik Jan 05 '16 at 23:01
  • 2
    Library flavors are an attribute of the binary format(s) supported by the OS. Neither C nor C++ knows anything about them, nor even about libraries themselves. – John Bollinger Jan 05 '16 at 23:01
  • There is no language C/C++. And the question is not specific to a PL. – too honest for this site Jan 05 '16 at 23:54
  • Shared libraries are not related to `-FPIC` actually. That is a different thing. – too honest for this site Jan 06 '16 at 09:10
  • @Olaf Related they are. But as far as I understand, you can have a shared library without involving PIC code in it but then the linker needs to do more work and modify whole .text segments instead of just a couple of tables. Also it should work on on 32 bit, but it doesn't work on x86_64. At least gcc won't even let me make a shared library out of non-PIC on x86_64. – Petr Skocik Jan 06 '16 at 09:34
  • Please elaborate how they are related in thour thoughts. These are two different options with `-fPIC` generating different code. Note that you cannot generate position-independent code. also PIC requires run-time support to load base-addresses, etc. Btw. this is more an issue of the loader (although some linkers include these features, too). – too honest for this site Jan 06 '16 at 09:39
  • @Olaf I think my comment says it. If you can have a shared library made out of non-PIC, then it should be performance-wise inferior to a shared library made out of PIC + you need PIC to make a shared library on x86_64. You're right that the C tag is only tangentially related to the question. It's an OS question. Feel free to edit it or retag it or downvote. I don't care that much about pidgeoholing it super well. – Petr Skocik Jan 06 '16 at 09:41
  • 1
    Load-time might be longer (this depends on the architecture), but run-time is well-possible slower for PIC do to (more or less) frequent loading of base-pointers through tables (similar to OOP vtables). Also on quite some targets PIC has limited brancing range, so needs more trampolines, etc. As always things are not that simple as one thinks. – too honest for this site Jan 06 '16 at 09:45

3 Answers3

6

This is partially a historical issue. Once there were only static libraries. They were linked statically to every binary the system compiled. However this represented a maintenance nightmare among other things, requiring all the using packages to be recompiled if a library was patched or changed.

Then shared libraries came along fixing these issues. Now for your question, firstly there are some significant optimisations that can take place in a statically linked library that it is impossible to perform on a dynamic one, therefore even if one were to transform dynamic libraries into static ones it would likely be less efficient than code compiled statically in the first place.

Secondly, most modern systems use solely shared libraries anyway, so there is not much of an issue, things are compiled only once, as a shared library.

As a slight aside, however still relevant you might look into prelinking. A step that takes away some of the start-up overhead (though still not necessarily achieving the same performance as a static link) and allowing software that dynamically links in libraries to launch faster.

Vality
  • 6,577
  • 3
  • 27
  • 48
  • Thanks. I do use prelink on my Linux. I'm curious if it is possible to link a static library statically, though. I think at least theoretically it should be since PIC object files link in just fine. – Petr Skocik Jan 05 '16 at 23:15
  • 1
    "Then shared libraries came along fixing these issues." ...and create hundreds more... – Lee Daniel Crocker Jan 05 '16 at 23:15
  • @PSkocik Yes, it is possible, http://statifier.sourceforge.net/ and http://magicermine.com/ do so, but beware the binaries they generate are very very large, substantially slower than dynamic or normal static ones and often flaky or unreliable – Vality Jan 05 '16 at 23:20
  • Thanks. I just found out that static libs with rellocatable code are linkable statically and very fast to transform into a shared library. I think that's what I was looking for. – Petr Skocik Jan 05 '16 at 23:30
1

Although in theory, one surely could post-process dynamic libraries into static ones, the difficulty of such a task -- especially of doing it well -- would be comparable to compiling from scratch. Getting the same result by post-processing as by performing a from-scratch static build is probably more difficult than simply building again, plus any tool to do that would carry its own maintenance burden. Why go for that when there is already a perfectly good way to reach the same objective?

Moreover, building both static and shared libraries is by no means required. Even where you want to do that, the incremental cost of doing so is (should be) a quite small part of the overall development time.

John Bollinger
  • 160,171
  • 8
  • 81
  • 157
0

You would use static libraries when you want your executable to not depend on some library. Basically the library is "shipped" within the executable.

Of course this is very situational as most of the times shared libraries are the way to go.

bolov
  • 72,283
  • 15
  • 145
  • 224