From simon.urbanek at math.uni-augsburg.de  Sun Aug  1 11:21:40 2004
From: simon.urbanek at math.uni-augsburg.de (Simon Urbanek)
Date: Sun Aug  1 11:21:44 2004
Subject: [Rd] R + OS X + gcc 3.5 = not quite there ..
In-Reply-To: <095CB4BC-E326-11D8-9ED2-000A95A67E82@stat.ucla.edu>
References: <095CB4BC-E326-11D8-9ED2-000A95A67E82@stat.ucla.edu>
Message-ID: <322F3E63-E39C-11D8-89F4-000A959F327E@math.uni-augsburg.de>

On Jul 31, 2004, at 9:15 PM, Jan de Leeuw wrote:

> [cabledoc70:Developer/R/R-devel] deleeuw% bin/R
> Error in lazyLoadDBfetch(key, datafile, compressed, envhook) :
>         internal error in decompress1

I forgot to post it here, but the problem I had was in libz (thanks to 
Luke for some tips). When I used system's libz then the problems went 
away. I suspect the supplied libz is miscompiled in some way, however I 
had no time yet to track it down exactly.

> gfortran   -fno-common  -g -O2 -c ppr.f -o ppr.o
> /var/tmp//ccSqEJAf.s:8241:FATAL:Symbol __BLOCK_DATA____ already 
> defined.

Heh, I suspect it's the same code that my g77 cross-compiler hates, as 
I posed here few days ago ... got no response so far :/

> and the "bad restore file magic number" errors are there as well.

That's the libz thing: what happens is the following: first load opens 
the file as gzip, that should work, but for some reason it doesn't, so 
load falls back to raw mode and tries to read it as-is, however then 
the magic number is bogus since it's actually gzipped, so load fails. 
If you use system's libz the file is decompressed correctly.

Cheers,
Simon


[Rd] R + OS X + gcc 3.5 = not quite there ..
Simon Urbanek