[M3devel] gmp and mpfr

[Jay]

Static linking libc is a different matter.
It should work on Linux and NT but I realize it isn't universally supported.
I did it by accident.
The kernel does have a compatiblity burden, at least where the interfaces have been published.
(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.)


Anyway, for libgmp and libmpfr, I still think static linking to these two is definitely ok, or better.

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.

That, or we get to deal with LD_LIBRARY_PATH and/or -rpath.

It sure is nice how on Windows you can at least colocate .exes and .dlls in the same directory and the .dlls get found.
This is a different matter vs. if current directory is in the search path for .exes.

 - Jay


> Date: Sat, 19 Apr 2008 12:43:06 +0200
> From: wagner at elegosoft.com
> To: m3devel at elegosoft.com
> Subject: Re: [M3devel] gmp and mpfr
> 
> Quoting Jay <jayk123 at hotmail.com>:
> 
> > Thanks.
> >
> >  > other thoughts?
> >
> > Static link?
> >
> > I should measure the bloat.
> > I accidentally statically linked to libc.a and the bloat was small,   
> > I think x86 static was smaller than AMD64 dynamic.
> 
> We must not link _any_ executable completely statically, we've been
> through that. Modern Unix systems all require dynamic linking, at
> least for all the standard C libraries.
> 
> >   > But that would mean a full install of gcc and libraries.
> >
> > Really?
> > Why not just gmp and mpfr and then point configure at them?
> > Besides, if necessary, import them but not under gcc?
> >
> >  - Jay
> >
> >
> > From: HOSKING at cs.purdue.edu
> > To: m3devel at elegosoft.com
> > Date: Fri, 18 Apr 2008 17:23:24 -0400
> > Subject: [M3devel] gmp and mpfr
> >
> > I have added the necessary gmp and mpfr distributions to the   
> > m3cc/gcc package.  It turns out that gcc will try to build from   
> > local source if it is available in the gcc hierarchy.  Now, the only  
> >  question is how to make sure that installs will put things in the   
> > right place.  One option is to configure gcc to install into   
> > INSTALL_ROOT from the m3cc m3makefile.  But that would mean a full   
> > install of gcc and libraries.  Any other thoughts?
> 
> If we really need to have these libraries in the distribution,
> we should either link them in statically or put the shared objects
> into INSTALL_ROOT/lib. We could either create different packages
> (that would require adding these to several scripts) or add some
> special quake code to build them all as part of m3cc:
> 
>    build libgmp
>    ship libgmp to INSTALL_ROOT/lib
>    build mpfr
>    ship mpfr to INSTALL_ROOT/lib
>    configure gcc with --with-mpfr=INSTALL_ROOT/lib/libmpfr.so \
>      --with-gmp=INSTALL_ROOT/lib/libgmp.so
>    (I don't think the argument are completely correct, but you get the idea.)
>    build gcc
>    ship gcc
> 
> The problem with this setup is that it wouldn't work for local builds
> (without shipping), and we'd have problems when the libraries need
> upgrade and we overwrite them (bootstrap will break). Or ensure
> proper versioning here (which is nowhere done up=to-now in cm3).
> 
> Or (in case of build without ship) just specify the locations in the
> workspace? Then we'd need to re-link cm3cg in case of later build and
> ship.
> 
> What do you think?
> 
> Olaf
> -- 
> Olaf Wagner -- elego Software Solutions GmbH
>                 Gustav-Meyer-Allee 25 / Gebäude 12, 13355 Berlin, Germany
> phone: +49 30 23 45 86 96  mobile: +49 177 2345 869  fax: +49 30 23 45 86 95
>     http://www.elegosoft.com | Geschäftsführer: Olaf Wagner | Sitz: Berlin
> Handelregister: Amtsgericht Charlottenburg HRB 77719 | USt-IdNr: DE163214194
> 
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3devel/attachments/20080419/93db0cb5/attachment-0002.html>