-1

I'm trying to link with an external library which consists of 22 static library (.a) files. When I use visual studio, I just need to pass down the directory to VS and it will link with the files in the directory. With gcc what I can first think of is,

-LC:\...\directory_of_library -lsth1 -lsth2 -lsth3 ... -lsth22

, which I am trying to find a better way than.

Also, will there be any problems with 'overlinking'? so linking with more libraries than necessary. Or will the compiler smartly ignore the redundant part?

  • "trying to find a better way than" -- because it doesn't work? – Brian Cain Sep 01 '14 at 21:32
  • because I am lazy and I don't like typing too many things, it sure works of course :) –  Sep 01 '14 at 21:36
  • You have in fact asked two questions. The second is perhaps legitimate and of interest, the first is just trivial, liable to cause the second to be ignored, and having admitted it is precipitated by laziness, will attract downvots. You spent more time typing the question than you might spend typing that *once* into an IDE project or makefile. – Clifford Sep 01 '14 at 21:50

2 Answers2

1

1) Your command is simply "linking". It's fine as-is.

2) "static" linking would mean to specify "-Bstatic", or specify a static ".a" library.

Here are a couple of good links that explain "static" vs. "dynamic" linking:

Community
  • 1
  • 1
FoggyDay
  • 11,962
  • 4
  • 34
  • 48
  • Could you please explain me a little more? My current un-deep understanding of static and dynamic linking is that the former will refer to the precompiled .a or .lib file in compile time and make up one big executable, while the latter means the .dll or .so(?) files will have to be set separate to run together with the executable. Is something different in just simple 'linking'? –  Sep 01 '14 at 21:43
  • Your understanding of .a/lib (static) vs. .so/.dll is exactly right. I hasten to add that dynamic libraries are a Good Thing. "Linking" binds together any combination of object modules (.o/.obj), static and dynamic libraries into an executable (.exe). FINAL NOTE: the linker autopmatically only includes what's "needed" in the final executable. Shared libraries have the additional benefit that "what's needed" is determined at runtime. And .so's/.dlls can be "shared" between running processes. Which can result in *large* efficiencies of memory usage. – FoggyDay Sep 01 '14 at 21:55
0

When the linker scans the library files, it only links the object code necessary to resolve the symbols not resolved by earlier object code or libraries. Unreferenced object code from archives will not be linked.

Specifying redundant libraries may extend the build time. You can help that by specifying the most used libraries first, but in all but the largest projects that is unlikely to be significant.

Clifford
  • 88,407
  • 13
  • 85
  • 165