[M3commit] CVS Update: cm3

[Jay]

Here is someone in a very similar situation and using a very similar fix:

  http://gcc.gnu.org/ml/gcc-help/2008-01/msg00041.html

He renames away the .so files during the build, where I copy the .a files to a new directory.

>        /usr/local/lib/libmpfr.1.dylib (compatibility version 3.0.0, current version 3.0.0)
What happens when we redistribute this cm3cg?
People have to get and build libmpfr?
Maybe. But I'm avoiding that.

When I just tell configure --with-mpfr=/usr/local --with-gmp=/usr/local, it builds ok, but then cm3cg fails, unable to find libmpfr.so and possibly libgmp.so.
You can see this in the Tinderbox build I believe, from around last night.
It is fixed now with static linking. I realize this might not be ideal, but there is a problem and this is a fix or at least workaround.

 - Jay

CC: m3commit at elegosoft.com
From: hosking at cs.purdue.edu
To: jayk123 at hotmail.com
Subject: Re: [M3commit] CVS Update: cm3
Date: Fri, 18 Apr 2008 00:08:12 -0400

I don't understand.  If gmp and mpfr are installed (in the usual places like /usr/local) then gcc will happily find them.  If not, then you may need to tell configure where they are with an option.  I would be surprised if gcc's configure does not add the necessary ld library paths to the build of m3cgc1.   For me on Mac OS X "otool -L" (equivalent of ldd) shows:
hosking$ otool -L /usr/local/cm3/bin/cm3cg/usr/local/cm3/bin/cm3cg:        /usr/local/lib/libintl.3.dylib (compatibility version 8.0.0, current version 8.3.0)        /usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)        /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 111.0.0)        /usr/local/lib/libmpfr.1.dylib (compatibility version 3.0.0, current version 3.0.0)        /usr/local/gcc-4.3.0/lib/libgcc_s.1.dylib (compatibility version 1.0.0, current version 1.0.0)
This cm3cg runs with both -m32 and -m64 switches to build both I386_DARWIN and AMD64_DARWIN on the same machine.
On Apr 17, 2008, at 11:51 PM, Jay wrote:Just take the dependency on libgmp.so and libmpfr.so?
The dependency on libmpfr.so broke Tinderbox, in a larger changable context. Just change LD_LIBRARY_PATH, or figure out -rpath, or install to /usr instead of /usr/local or /usr/contrib??

 - Jay


> CC: m3commit at elegosoft.com
> From: hosking at cs.purdue.edu
> To: jayk123 at hotmail.com
> Subject: Re: [M3commit] CVS Update: cm3
> Date: Thu, 17 Apr 2008 22:03:29 -0400
> 
> I don't think you should need this.
> 
> On Apr 17, 2008, at 9:24 PM, Jay wrote:
> 
> >
> > Previous cm3cg (on birch) is/was only dependent on:
> >
> > % ldd /usr/local/cm3/bin/cm3cg
> > linux-gate.so.1 => (0xffffe000)
> > libc.so.6 => /lib/tls/i686/cmov/libc.so.6 (0xb7e83000)
> > /lib/ld-linux.so.2 (0xb7fc3000)
> >
> > we shouldn't add libgmp.so and libmpfr.so to this, right?
> > At least not libmpfr.so. That dependency at least was causing 
> > Tinderbox breaks.
> > Perhaps just add /usr/local/lib to LD_LIBRARY_PATH or something with 
> > -rpath?
> > I poked around a little with -rpath. I'd'thunk it'd be more automatic.
> >
> > Ok for building m3cc to have extra dependencies, but the result less 
> > so, right?
> >
> > Granted, a) the source could be imported, small compared to gcc b) 
> > could provide a .deb or such with a declared dependency and have apt- 
> > get get the dependencies if they are missing. Should probably be 
> > building .deb files anyway. Yeah, I know I'm late to this party.
> > If everyone statically linked, everything would explode in size.
> >
> > - Jay
> >
> >> From: hosking at cs.purdue.edu
> >> To: jkrell at elego.de
> >> Date: Thu, 17 Apr 2008 13:09:47 -0400
> >> CC: m3commit at elegosoft.com
> >> Subject: Re: [M3commit] CVS Update: cm3
> >>
> >> It should just build. Not sure what you are trying to achieve by
> >> static linking.
> >>
> >> On Apr 17, 2008, at 7:31 AM, Jay Krell wrote:
> >>
> >>> CVSROOT: /usr/cvs
> >>> Changes by: jkrell at birch. 08/04/17 07:31:36
> >>>
> >>> Modified files:
> >>> cm3/m3-sys/m3cc/src/: m3makefile
> >>>
> >>> Log message:
> >>> statically link libmpfr.a by hook and by crook, see if I can get
> >>> this to work on birch..
> >>
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://m3lists.elegosoft.com/pipermail/m3commit/attachments/20080418/f4965f11/attachment-0002.html>