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

[Dragiša Durić]

gcc GSTABS_TO_WARN_COMMON_LD_ARGS -Wl,-rpath,/usr/local/cm3/bin/../lib  -o MYPGM  _m3main.o MYOBJS /usr/local/cm3/pkg/openssl/AMD64_LINUX/libhm3openssl.a /usr/lib64/libssl.a /usr/lib64/libcrypto.a -lz -L/usr/local/cm3/pkg/libm3/AMD64_LINUX -lm3 -L/usr/local/cm3/pkg/m3core/AMD64_LINUX -lm3core -lm -ldl -lkrb5 -pthread

This is what I made.... Manually of course.
      * build_standalone() in m3makefile ;
      * cm3 -commands (this fails at linking because it cannot succeed
        if fully static, but I get original linking command I edit
        later)
      * cd ../AMD64_LINUX
      * command from first line...

build_standalone() is just setting build_shared somewhere in Builder.m3
to FALSE.. So it's all or nothing. What we need is a way to specify
(best would be in main app m3makefile, so installed libraries can be
static on demand) what libraries we need static. With that info passed
through m3makefile, current quake code can produce custom command.

If nobody has time/will to do this, I'll do it after I deliver my
current project.

On Wed, 2010-10-06 at 22:52 +0000, Jay K wrote:
> 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ć 
> >
>  		 	   		  

-- 
Dragiša Durić <dragisha at m3w.org>