[M3devel] static linking of some C libs...

Jay K jay.krell at cornell.edu
Thu Oct 7 00:52:22 CEST 2010


I don't have a good answer here.
I have some bad ones: Only have static libraries.
We have several linkers in use: GNU ld, Solaris ld, Apple ld, Microsoft link.


Microsoft link doesn't really have the notion you ask for. It just has libraries.
It has a better model imho.
It never links to .so/.dll files.
It links to .libs.
Those .libs might be "normal" static ones with real code in them,
or they might be "import libraries" that actually end up putting only metadata in the resulting .exe/.dll.
(In reality, it is an .obj by .obj case, and .lib is just a bunch of .objs. There are a very small number of
.libs that contain a mix of static and dynamic .objs -- such as msvcrt.lib. That's why there is no "crt0.o".
It's analogous content is in msvcrt.lib. This construct is pretty rare and therefore not well known.
However it is heavily used (msvcrt.lib!) and so the evidence of its existance is readily at hand
once you know to look.)


The Unix linkers have a wierd model where they probe around like mad and are willing
to "link" to an .so/.dll file with no .lib/.a in sight.
It is good in terms of "self description" but bad in terms of conflating runtime and tools.


In Windows, the libraries are always shipped seperately. Cross-building (ie. to a different OS version)
is the norm.


The import libraries are to a large extent a small transform of the .dll files, so, well,
there is something to the Unix model. It isn't completely crazy, it seems better at first
maybe but it is wierd and inferior ultimately.


So, for Windows, which I suspect you are talking about, point the linker at a static library.
The Microsoft linker is willing to do some "probing around" such as searching the %LIB%
environment variable, or the -libpath command line option. But it doesn't make its own
static vs. dynamic decisions or probe around in a way to do so, except to the extent
that you have multiple foo.lib in %LIB% and it takes the first. As long as you use
full paths to .lib files, what you ask for is what you get.


(I do suspect you are asking specifically about Windows.)


Modula-3 does something slightly tricky in order to allow static and dynamic and
for it to later chose. It makes static libraries for everything: foo.lib.sa.
"sa" = standalone.
And then it makes import libraries if the library isn't declared build_standalone: foo.lib.
If it is build_standalone, it renames foo.lib.sa to foo.lib.


Then if the client is build_standalone, it looks for foo.lib.sa and gives that to the linker.
If the client is not build_standalone, it just uses foo.lib, which might be static or dynamic.


All this is done by cm3/the config file though. No trickery or probing in the linker.


It is how "by default" you are dependendent on m3core.dll, but cm3 is not.
And how there is m3core.dll, but no m3quake.dll.


I does basically identical for Unix even.
Part of the Unix story is using -fPIC always.
It is an inefficiency sometimes, but imho worth it.
I wish Windows code was always position independent, rather than worry
about base addresses and relocation costs (prior to Vista, relocs were
applied to entire .dll at load, killing demand paging and page sharing;
as of Vista, they are applied at page-in, which preserves demand paging
but still loses on page sharing).


 -Jay

----------------------------------------
> From: dragisha at m3w.org
> To: m3devel at elegosoft.com
> Date: Wed, 6 Oct 2010 22:40:12 +0200
> Subject: [M3devel] static linking of some C libs...
>
> I would like to statically link only some C libs. How to do it?
> --
> Dragiša Durić 
>
 		 	   		  


More information about the M3devel mailing list