bug#39204: r-rgdal: Reading of vector GIS data causes segfault

[Arun Isaac]

> You mean:
>
>   guix build --with-input=proj.4=proj r-rgdal
>
> then it compiles a lot... and I do not understand why gdal is
> recompiled. Anyway!

Your command recursively replaces proj.4 with proj. So, some dependency
of gdal might have been modified resulting in a rebuild of gdal.

> So after some CPU burning, I get:
>
> --8<---------------cut here---------------start------------->8---
> Testing examples for package ‘rgdal’
> Running specific tests for package ‘rgdal’
>   Running ‘srs_rendering.R’
>   comparing ‘srs_rendering.Rout’ to ‘srs_rendering.Rout.save’ ...
> 5c5
> < [1] "Rel. 6.2.0, September 1st, 2019, [PJ_VERSION: 620]"
> ---
>> [1] "Rel. 6.0.0, March 1st, 2019, [PJ_VERSION: 600]"
> 7c7
> < [1] "GDAL 3.0.2, released 2019/10/28"
> ---
>> [1] "GDAL 2.4.0, released 2018/12/14"
> 11c11
> <
>                            scot_BNG
> ---
>>                                                                              
>>                                                                         
>> trin_inca_pl03
> 12c12
> < "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000
> +y_0=-100000 +ellps=airy +units=m +no_defs"
> ---
>>                                                                              
>>                                                                              
>>        NA
> 13c13
> <
>                      trin_inca_pl03
> ---
>>                                                                              
>>                                                               
>> kiritimati_primary_roads
> 14c14
> <
>                                  NA
> ---
>>                                                                              
>>                                    "+proj=utm +zone=4 +datum=WGS84 +units=m 
>> +no_defs "
> 16c16
> <
> "+proj=longlat +datum=WGS84 +no_defs"
> ---
> <
>            kiritimati_primary_roads
> ---
>>                                                                              
>>                                                                              
>>  scot_BNG
> 18c18
> <                                                       "+proj=utm
> +zone=4 +datum=WGS84 +units=m +no_defs"
> ---
>> "+proj=tmerc +lat_0=49 +lon_0=-2 +k=0.9996012717 +x_0=400000 +y_0=-100000 
>> +ellps=airy +towgs84=446.448,-125.157,542.06,0.15,0.247,0.842,-20.489 
>> +units=m +no_defs "
> 22c22
> < [1] "+proj=longlat +a=6378137.01 +rf=298.257223563
> +towgs84=0,0,0,0,0,0,0 +no_defs"
> ---
>> [1] "+proj=longlat +ellps=WGS84 +towgs84=0,0,0,0,0,0,0 +no_defs "
> 24c24
> < [1] "+proj=utm +zone=23 +south +ellps=aust_SA
> +towgs84=-57,1,-41,0,0,0,0 +units=m +no_defs"
> ---
>> [1] "+proj=utm +zone=23 +south +ellps=aust_SA +towgs84=-57,1,-41,0,0,0,0 
>> +units=m +no_defs "
> 26c26
> < [1] "+proj=longlat +datum=WGS84 +no_defs"
> ---
>> [1] "+proj=longlat +datum=WGS84 +no_defs "
> 28c28
> < [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0
> +k_0=0.999877420000019 +x_0=600000 +y_0=2200000.00000032
> +ellps=clrk80ign +pm=paris +towgs84=-168,-60,320,0,0,0,0 +units=m
> +no_defs"
> ---
>> [1] "+proj=lcc +lat_1=46.8 +lat_0=46.8 +lon_0=0 +k_0=0.9998774200000193 
>> +x_0=600000 +y_0=2200000.000000325 +a=6378249.2 +b=6356515.000000472 
>> +towgs84=-168,-60,320,0,0,0,0 +pm=paris +units=m +no_defs "
> 40c40
> < file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.6666666666667
> +lon_0=-88.3333333333333 +k=0.999975 +x_0=152400.30480061 +y_0=0
> +ellps=clrk66 +towgs84=-8,160,176,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  SP27GTIF.TIF , SRS:  +proj=tmerc +lat_0=36.66666666666666 
>> +lon_0=-88.33333333333333 +k=0.9999749999999999 +x_0=152400.3048006096 
>> +y_0=0 +datum=NAD27 +units=us-ft +no_defs
> 41c41
> < file:  cea.tif , SRS:  +proj=cea +lat_ts=33.75
> +lon_0=-117.333333333333 +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> ---
>> file:  cea.tif , SRS:  +proj=cea +lon_0=-117.333333333333 +lat_ts=33.75 
>> +x_0=0 +y_0=0 +datum=NAD27 +units=m +no_defs
> 42c42
> < file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30
> +lon_0=-82.1666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80
> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> ---
>> file:  erdas_spnad83.tif , SRS:  +proj=tmerc +lat_0=30 
>> +lon_0=-82.16666666666667 +k=0.9999 +x_0=200000 +y_0=0 +ellps=GRS80 
>> +towgs84=0,0,0,0,0,0,0 +units=us-ft +no_defs
> 43c43
> < file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +ellps=WGS84
> +towgs84=0,0,0,0,0,0,0 +units=m +no_defs
> ---
>> file:  scaleoffset.vrt , SRS:  +proj=utm +zone=18 +datum=WGS84 +units=m 
>> +no_defs
>   Running ‘test_proj.R’
>   comparing ‘test_proj.Rout’ to ‘test_proj.Rout.save’ ... OK
>    Running ‘tests.R’
>   comparing ‘tests.Rout’ to ‘tests.Rout.save’ ... OK
>   Running ‘tripup.R’
>   comparing ‘tripup.Rout’ to ‘tripup.Rout.save’ ...
> 266c266
> <  coords FALSE
> ---
>>  coords TRUE
> 267c267
> <  holes FALSE
> ---
>>  holes TRUE
> 273c273
> <  coords FALSE
> ---
>>  coords TRUE
> 274c274
> <  holes FALSE
> ---
>>  holes TRUE
> Running vignettes for package ‘rgdal’
>   Running ‘OGR_shape_encoding.Rnw’
> phase `check' succeeded after 18.7 seconds
> --8<---------------cut here---------------end--------------->8---
>
>
> Therefore, I do not confirm, I guess.

I don't understand. With proj instead of proj.4, it does work, doesn't
it? There are no errors and the check phase succeeds.

signature.asc
Description: PGP signature