<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'>C/C++ interop/linking thoughts?<BR>
<BR>What are people's thoughts on interop with and C and C++?<BR>
<BR>In particular, that of static linking C and C++ with Modula-3, in the same .dll/.so/.exe?<BR>Or that of loading a Modula-3 .dll/.so into a process that is otherwise just C and C++?<BR>
<BR>I ask for NOT the most important of reasons.<BR>
<BR>The Modula-3 dependency on the C runtime on Windows is pretty light,<BR> and it is in fact mostly for the startup code.<BR> The startup code doesn't do much. Mainly it runs C++ constructors/destructors.<BR> And C code can have initializers/cleanup.<BR>
<BR>I think it might be interesting to drive this dependency to zero, but<BR> it depends on expectations of C and C++ statically linked into a Modula-3 .dll/.so/.exe working.<BR>
<BR>I know there is C code in the system already. It is light. It works without the startup<BR> code in my experience.<BR>
<BR>I already changed Modula-3 .dlls to build with /noentry.<BR>.exes take a bit more.<BR>It's in the config file.<BR>
<BR>
There are comments in the config file about it, including the contrary point of a C generating back end<BR>
.<BR>
On a very related note, I almost forgot..on Mac OS X, there is shared or static libgcc.<BR>
The man pages say roughly this:<BR>
g++ and gcj (Java) specify shared libgcc by default <BR>
gcc specifies static libgcc by default <BR><BR>
C++ and Java favor shared in order to enable throwing/catching exceptions across .dll/.so boundaries.<BR>
"Pure" Modula-3 code wouldn't care about that. Modula-3 code linking with C++ might.<BR>
Perhaps in these scenarios, the "build system" and linking will tend to escape cm3 anyway?<BR>Make Modula-3 static .libs/.a with cm3 but not link the final file with it?<BR>
<BR>
I think the current config file links .dylibs(.dll/.so, but usually .dylib in this context, at least by convention) with static libgcc and executables with shared.<BR>
I found in groveling over the results that, there were four or six functions imported from shared libgcc, little math helpers for division or such.<BR>
It seems not worth depending on another file for just a few small functions.<BR>
<BR>
Just use static?<BR>
<BR>
On a less related note, for anyone who likes to go down such paths, I concluded that calling ld directly on Mac OS X is not a great idea, best stick to calling gcc (or g++/whatever) to do the linking, as the current files do.<BR>
<BR>
- Jay<BR><br /><hr />i’m is proud to present Cause Effect, a series about real people making a difference. <a href='http://im.live.com/Messenger/IM/MTV/?source=text_Cause_Effect' target='_new'>Learn more</a></body>
</html>