<html>
<head>
<style>
.hmmessage P
{
margin:0px;
padding:0px
}
body.hmmessage
{
FONT-SIZE: 10pt;
FONT-FAMILY:Tahoma
}
</style>
</head>
<body class='hmmessage'><div style="text-align: left;">truncated yet again, maybe I have to forward instead of reply..<br><br></div>
<blockquote><style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
<div style="text-align: left;">Truncated again..<br></div><blockquote><br>
<style>
.ExternalClass .EC_hmmessage P
{padding:0px;}
.ExternalClass body.EC_hmmessage
{font-size:10pt;font-family:Tahoma;}
</style>
<div style="text-align: left;">Static linking libc is a different matter.<br>It should work on Linux and NT but I realize it isn't universally supported.<br>I did it by accident.<br>The kernel does have a compatiblity burden, at least where the interfaces have been published.<br>(On NT, the layering is different. You can link statically to libcmt.lib, which to a very large extent is what people think of libc, but it doesn't call the kernel directly, it goes through kernel32.dll, which goes through ntdll.dll, and syscall numbers are not stable.)<br><br><br>Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better.<br></div><br>Whether we import the source is a separate variable -- can still build a static .a file and link to it and drop the runtime dependency.<br><br>That, or we get to deal with LD_LIBRARY_PATH and/or -rpath.<br><br>It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found.<br>This is a different matter vs. if current directory is in the search path for .exes.<br><br> - Jay<br><br><br><hr id="EC_EC_stopSpelling">> Date: Sat, 19 Apr 2008 12:43:06 +0200<br>> From: wagner@elegosoft.com<br>> To: m3devel@elegosoft.com<br>> Subject: Re: [M3devel] gmp and mpfr<br>> <br>> Quoting Jay <jayk123@hotmail.com>:<br>> <br>> > Thanks.<br>> ><br>> > > other thoughts?<br>> ><br>> > Static link?<br>> ><br>> > I should measure the bloat.<br>> > I accidentally statically linked to libc.a and the bloat was small, <br>> > I think x86 static was smaller than AMD64 dynamic.<br>> <br>> We must not link _any_ executable completely statically, we've been<br>> through that. Modern Unix systems all require dynamic linking, at<br>> least for all the standard C libraries.<br>> <br>> > > But that would mean a full install of gcc and libraries.<br>> ><br>> > Really?<br>> > Why not just gmp and mpfr and then point configure at them?<br>> > Besides, if necessary, import them but not under gcc?<br>> ><br>> > - Jay<br>> ><br>> ><br>> > From: HOSKING@cs.purdue.edu<br>> > To: m3devel@elegosoft.com<br>> > Date: Fri, 18 Apr 2008 17:23:24 -0400<br>> > Subject: [M3devel] gmp and mpfr<br>> ><br>> > I have added the necessary gmp and mpfr distributions to the <br>> > m3cc/gcc package. It turns out that gcc will try to build from <br>> > local source if it is available in the gcc hierarchy. Now, the only <br>> > question is how to make sure that installs will put things in the <br>> > right place. One option is to configure gcc to install into <br>> > INSTALL_ROOT from the m3cc m3makefile. But that would mean a full <br>> > install of gcc and libraries. Any other thoughts?<br>> <br>> If we really need to have these libraries in the distribution,<br>> we should either link them in statically or put the shared objects<br>> into INSTALL_ROOT/lib. We could either create different packages<br>> (that would require adding these to several scripts) or add some<br>> special quake code to build them all as part of m3cc:<br>> <br>> build libgmp<br>> ship libgmp to INSTALL_ROOT/lib<br>> build mpfr<br>> ship mpfr to INSTALL_ROOT/lib<br>> configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \<br>> --with-gmp=INSTALL_ROOT/lib/libgmp.so<br>> (I don't think the argument are completely correct, but you get the idea.)<br>> build gcc<br>> ship gcc<br>> <br>> The problem with this setup is that it wouldn't work for local builds<br>> (without shipping), and we'd have problems when the libraries need<br>> upgrade and we overwrite them (bootstrap will break). Or ensure<br>> proper versioning here (which is nowhere done up=to-now in cm3).<br>> <br>> Or (in case of build without ship) just specify the locations in the<br>> workspace? Then we'd need to re-link cm3cg in case of later build and<br>> ship.<br>> <br>> What do you think?<br>> <br>> Olaf<br>> -- <br>> Olaf Wagner -- elego Software Solutions GmbH<br>> Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany<br>> phone: +49 30 23 45 86 96 mobile: +49 177 2345 869 fax: +49 30 23 45 86 95<br>> http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin<br>> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194<br>> <br>
</blockquote>
</blockquote></body>
</html>