Hi,
i am not able to provide an exact solution. Just some hints.
With IRIX and gcc the -s option to ld does fail too. Please see in the
SGI readme file in documents. The -s option means to "strip" symbolic
information on the binary output
of the linker.
One intermediate solution would be to ommit the -s option to ld and to
strip the binaries later manually before creating the bindist. This is
done like this:
cd whereevergrassis ; find . -type f -exec strip {} \;
Perhaps there is an optimized/adapted gcc compiler for OS X/Darwin?
Where is your ld binary located?
For Solaris 8: Is there need for a Solaris 8 _and_ a Solaris 7 binary?
IMHO not. Which architecture (x86/SPARC)? For SPARC it would be
theoretically possible to make a 64bit binary, but this is not
recommended.
Markus Neteler wrote:
Hi Andy
(cc to the list)
On Tue, May 22, 2001 at 05:50:51AM -0500, andy agena wrote:
> Hello everyone:
>
> I have the same problems with the 20_may as I did with the CVS a few weeks
> ago on OS X / Darwin. I looked through the configure file and I'm not sure
> why the "ld -s" check fails, but it does, and I suspect this is the main problem.
> Could someone explain what this is looking for? Is there some way I can
> specify this during configure (e.g. --with dynlibs=...)? (Specifying tiff
> and jpeg worked out, thoughtIt seems that this error is the key to the large Mac OSX binaries (> 100MB).
If "ld -s" check wouldn't fail, the binaries could get common size.
I have not much ideas about this, but maybe another one here?> On a somewhat related note, is any one building binaries for Solaris 8?
Up to now no volunteer...Markus
_______________________________________________
grass5 mailing list
grass5@geog.uni-hannover.de
http://www.geog.uni-hannover.de/mailman/listinfo/grass5
--
Andreas Lange, 65187 Wiesbaden, Germany, Tel. +49 611 807850
Andreas.Lange@Rhein-Main.de - A.C.Lange@GMX.net