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

[Jay K]

Right.
What you want something like:
import_standalone("libfoo")
or import_static("libfoo")

shouldn't be too hard.
Just stick libfoo in some global hashtable and then when linking looks for libfoo.so vs. libfoo.a, it can use that to guide.

That is assuming libfoo is built by Modula-3 and that there are both.
If it is a C library, you'll have to do something else.

<rant>
I find Unix link command lines extremely confusing and very likely both
  having too many and too few features. What with options being in effect
until end of command line, or maybe not, or being able to turn them off/on as you go,
making it all ridiculously order-dependent. You really want to "attach" options to parameters,
or just have a dramatically simpler model and fewer options.
With Windows it is very simple. You give it a full path to a .lib or a leaf path and %LIB% is searched.
There are no options that apply to some or all .libs. It is much much much simpler, and provides
all that you need/want.
All the more reason, perhaps, to write our linker in Modula-3!
  (That'd be a great piece of a cross build story...but is a ton ton ton of work.)
Unix linkers also have a ridiculous number of confusing options like -z origin (why?), -z now (the
default on Windows, unless you use -delayload), -z combreloc, etc. etc. etc. including man pages
that list options that aren't really there because the loader doesn't support them (.e.g -z origin
historically on NetBSD).

Not to mention the historical defaults that were obviously wrong at the time and now have all been since deprecated.
  e.g. the flat namespace, leading to more confusing an inefficiency. As if emulating static linking
  was of such paramount importance that everything could be made worse in support of this misguided direction...
</rant>


 - Jay


----------------------------------------
> From: dragisha at m3w.org
> To: jay.krell at cornell.edu
> Date: Thu, 7 Oct 2010 07:58:55 +0200
> CC: m3devel at elegosoft.com
> Subject: Re: [M3devel] static linking of some C libs...
>
> 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ć 
>