[Gdal-dev] Re: [GRASS-user] gdal and grass new problem from "is, but isn't" series

[Roger Bivand]

On Fri, 22 Sep 2006, [windows-1252] Jaros?aw Jasiewicz wrote:

> Roger Bivand napisa?(a):
> > Jarek:
> >
> > This feels very much like the rgdal issue with libproj.a. Did that get 
> > resolved, by the way? Is the target machine 64-bit, and the software a 
> > mixture of 32-bit and 64-bit installs? 
> >   
> Roger
> >   
> 
> Not for now
> But You're right
> It isn't 64 bit machnie but some instalers (including gdal) treat is as 
> 64 bit. Now I look for solution on that path
> 
> Anyway problem on computer wchich I try to configure is only "about 
> gdal" I have no problem with other lots of aplications - maby I shall 
> consult with gdal specialists?

I was at the Lausanne FOSS4G meeting, and issues like this were discussed, 
but not resolved. We mentioned for example having some way of software 
reporting how it had been built, because configure scripts can differ 
across software which is expected to work together. The gdal-config script 
is one example, another which is pretty complete is R CMD config with lots 
of arguments and flags, but neither of them seem to report the length of 
pointers directly. For R:

$ echo '.Machine$sizeof.pointer' | R --vanilla --quiet
> .Machine$sizeof.pointer
[1] 4
$

does work, but means asking the running program. Section 2.5 in:

http://cran.r-project.org/doc/manuals/R-admin.html

describes how sub-architectures are managed in R.

I've included a CC to the GDAL development list partly because your
situation, Jarek, is really difficult - if I understand it correctly, you
have proj, gdal, GRASS, grass-plugin, and R all working together on one
machine (i386 Linux 32-bit?, OS distribution unknown) and on trying to
install the same software on a different machine that you say GDAL
(wrongly) thinks is 64-bit (Linux, OS distribution unknown), you see
installed libraries that configure then does not pick up.

The report we saw on R-sig-geo earlier this month copied from R-sig-mac
suggests that they (on a different platform (G4/G5)) do see problems on
installation when some configure scripts choose one thing and others
something else with regard to pointer length, when shared objects are
being built for subsequent linking. Do you have the possibility to
document both machines and installations?

Unfortunately I do not have access to a 64-bit machine to play with, so I 
have no very good way of knowing what is going on here, but if it is 
possible to install a distribution such that software installed from 
source to work together does not do so, then some way of flagging what is 
going on would be valuable.

Within R for R built from source, the compile flags for shared objects in 
contributed packages (like rgdal) are taken from those used to build the R 
engine, but of course these can differ from flags used for building 
external libraries linked to the contributed package. This seems to be 
your case for libproj.a not being accepted by ./configure in the R rgdal 
package, and may be the case between the GDAL/OGR GRASS plugin and the 
GRASS libraries.

Roger


> 
> regards
> 
> Jarek
> 

-- 
Roger Bivand
Economic Geography Section, Department of Economics, Norwegian School of
Economics and Business Administration, Helleveien 30, N-5045 Bergen,
Norway. voice: +47 55 95 93 55; fax +47 55 95 95 43
e-mail: Roger.Bivand at nhh.no