[M3devel] link options (was LINUXLIBC6 on 64 bit Hardware) (rambly)

[Jay]

[adding m3devel]




----------------------------------------
> From: jay.krell at cornell.edu
> To: wagner at elegosoft.com
> Subject: RE: link options (was LINUXLIBC6 on 64 bit Hardware) (rambly)
> Date: Sat, 27 Jun 2009 00:43:58 +0000
>
>
> ps: You don't see -lc there either.
> Change SYSTEM_CC to include -Wl,-v or such and you can see what gcc feeds to ld, surely it'll have hints of -lc and -lgcc_s. Or gcc -dump-specs or somesuch.
> You could try running that then without the -lgcc_s but you'll likely have unresolved externals related to 64 bit integers. libgcc is about more than 64 bit integers, also like C++ and Ada exception handling, but it seems like overkill for us. 64 bit systems shouldn't need it for 64 bit math, at least.
> THe thing is, choice of shared libgcc or not, is that, you know, you /might/ be (static) linking your Modula-3 with some C++ code that uses exceptions, and you /might/ be /dynamically/ linking to other C++ code that throws exceptions and you might want interop, in which case shared libgcc is desired.
>
>
> But then the common case is the "opposite" -- all Modula-3.
>
>
> I think it is tenuous to have exceptions go across dynamic link boundaries, but some people think the line between dynamic and static linking should be quite blurry and things should work the "same" either way.
> (Thus why the older symbol resolution algorithms where all symbols looked across all .so files, to emulate static linking, eventually/gradually replaced with "two level namespace". That is Apple's term and I think a good description of what everyone now favors even if they don't call it that; but then the defaults often unchanged for compatibility, Apple changed the default, NT was always this way (except maybe Interix)).
>
>
> Actually, now that I think about it...this is stuff that actually needs to be controllable from each m3makefile, and possibly from the cm3 command line.
>
> I used to think it was a config file thing and I'd try to make a reasonable choice for everyone, but now I think it's not even a per-machine thing but more granular. Anyway, the default is reasonable, just that it should probably be changable.
>
>
> So probably we should have new Quake directives that mimic gcc's command line options, like:
> SharedLibGcc();
> StaticLibGcc();
>
>
> and they'd just be ignored on SOLsun, NT386, etc.
> They'd just be trivially implemented in cm3cfg.common and set a global that m3_link adds to the link command line, very simple.
>
>
> I guess this is a general exercise: See what switches in gcc/ld people tend to vary on a project by project basis, see which ones are relevant to Modula-3 (ie: more linking flags, not compile flags) and expose them in Quake.
> AND/OR ensure it is/remains viable for people to use Makefiles, combine Modula-3 with gcc using Makefiles and gcc, and just using cm3 to build some pieces of their project. Personally I've never tried that.
> That way, you know, they can just form their own link commands in a Makefile and Quake doesn' t have to provide full access.
> Also we could make SYSTEM_LD not readonly and leaf m3makefiles could just munge it.
> That is an easy way to add flexibility.
>
>
> - Jay
>
> ----------------------------------------
>> Date: Fri, 26 Jun 2009 23:20:34 +0200
>> From: wagner
>>>>
>>>> I don't see gcc_s in the link command, and on birch there _is_
>>>> /lib/libgcc_s.so.1
>>>>
>>>> Any ideas?
>>>>
>>>> Olaf