[Bioc-devel] Package Installation Fails on Linux Kunpeng2 Due to ‘concaveman’ and ‘sf’ Dependencies

Martin Grigorov mgr|gorov @end|ng |rom @p@che@org
Thu Mar 27 09:02:29 CET 2025


biocbuild using kunpeng2 ~/g/CARDspa (devel)> R CMD build .
* checking for file ‘./DESCRIPTION’ ... OK
* preparing ‘CARDspa’:
* checking DESCRIPTION meta-information ... OK
* cleaning src
* installing the package to build vignettes
* creating vignettes ... OK
* cleaning src
* checking for LF line-endings in source and make files and shell scripts
* checking for empty or unneeded directories
* looking to see if a ‘data/datalist’ file should be added
* building ‘CARDspa_0.99.7.tar.gz’


The next build should be fine!

On Thu, Mar 27, 2025 at 9:44 AM Martin Grigorov <mgrigorov using apache.org>
wrote:

> I found a workaround!
>
> 1) I copied pcs.csv from gdal-2.4.4 (
> https://anaconda.org/conda-forge/gdal/files?page=464)
> 2) https://github.com/conda-forge/pyproj-feedstock/issues/130 explained
> the problem with PROJ - I had to manually export
> PROJ_LIB=/home/biocbuild/bioconductor/gdal/.pixi/envs/default/share/proj
>
> The 'sf' build is still running!
>
> On Thu, Mar 27, 2025 at 9:27 AM Martin Grigorov <mgrigorov using apache.org>
> wrote:
>
>> Using libgdal-core 3.x fails with:
>>
>> > BiocManager::install(c("sf"))
>> Bioconductor version 3.21 (BiocManager 1.30.25), R Under development
>> (unstable)
>>   (2025-02-19 r87757)
>> Installing package(s) 'sf'
>> trying URL 'https://cloud.r-project.org/src/contrib/sf_1.0-20.tar.gz'
>> Content type 'application/x-gzip' length 4492197 bytes (4.3 MB)
>> ==================================================
>> downloaded 4.3 MB
>>
>> * installing *source* package ‘sf’ ...
>> ** this is package ‘sf’ version ‘1.0-20’
>> ** package ‘sf’ successfully unpacked and MD5 sums checked
>> ** using staged installation
>> configure: CC:
>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-gcc
>> -std=gnu23
>> configure: CXX:
>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-g++
>> -std=gnu++17
>> checking for gdal-config...
>> /home/biocbuild/bioconductor/gdal/.pixi/envs/default/bin/gdal-config
>> checking gdal-config usability... yes
>> configure: GDAL: 3.10.2
>> checking GDAL version >= 2.0.1... yes
>> checking for gcc...
>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-gcc
>> -std=gnu23
>> checking whether the C compiler works... yes
>> checking for C compiler default output file name... a.out
>> checking for suffix of executables...
>> checking whether we are cross compiling... no
>> checking for suffix of object files... o
>> checking whether the compiler supports GNU C... yes
>> checking whether
>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-gcc
>> -std=gnu23 accepts -g... yes
>> checking for
>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-gcc
>> -std=gnu23 option to enable C11 features... none needed
>> checking for stdio.h... yes
>> checking for stdlib.h... yes
>> checking for string.h... yes
>> checking for inttypes.h... yes
>> checking for stdint.h... yes
>> checking for strings.h... yes
>> checking for sys/stat.h... yes
>> checking for sys/types.h... yes
>> checking for unistd.h... yes
>> checking for gdal.h... yes
>> checking GDAL: linking with --libs only... yes
>> checking GDAL:
>> /home/biocbuild/bioconductor/gdal/.pixi/envs/default/share/gdal/pcs.csv
>> readable... no
>> checking GDAL: checking whether PROJ is available for linking:... yes
>> checking GDAL: checking whether PROJ is available for running:... ERROR
>> 1: PROJ: proj_create_from_database: Open of
>> /home/biocbuild/bioconductor/gdal/.pixi/envs/default/share/proj failed
>> ERROR 1: PROJ: proj_create_from_database: Open of
>> /home/biocbuild/bioconductor/gdal/.pixi/envs/default/share/proj failed
>> ERROR 1: PROJ: proj_create: unrecognized format / unknown name
>> ERROR 1: PROJ: proj_create: unrecognized format / unknown name
>> no
>> configure: error: OGRCoordinateTransformation() does not return a
>> coord.trans: PROJ not available?
>> ERROR: configuration failed for package ‘sf’
>> * removing ‘/home/biocbuild/R/R-devel_2025-02-19/site-library/sf’
>>
>> gdal 2.x does not provide linux-aarch64 builds, so i cannot try it :-/
>>
>> Any ideas are welcome !
>>
>>
>> On Thu, Mar 27, 2025 at 8:52 AM Martin Grigorov <mgrigorov using apache.org>
>> wrote:
>>
>>> Hi,
>>>
>>> The problem is a transitive dependency:
>>>
>>> * installing *source* package ‘sf’ ...
>>> ** this is package ‘sf’ version ‘1.0-20’
>>> ** package ‘sf’ successfully unpacked and MD5 sums checked
>>> ** using staged installation
>>> configure: CC:
>>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-gcc
>>> -std=gnu23
>>> configure: CXX:
>>> /opt/ohpc/pub/compiler/gcc/14.2.0/bin/aarch64-unknown-linux-gnu-g++
>>> -std=gnu++17
>>> checking for gdal-config... no
>>> no
>>> configure: error: gdal-config not found or not executable.
>>> *** Installing this package from source requires the prior
>>> *** installation of external software, see for details
>>> *** https://r-spatial.github.io/sf/#installing
>>> ERROR: configuration failed for package ‘sf’
>>> * removing ‘/home/biocbuild/R/R-devel_2025-02-19/site-library/sf’
>>>
>>> There is no such package in the OS repository.
>>> I have tried to install it from conda-forge (
>>> https://anaconda.org/conda-forge/libgdal-core/files) but it leads to
>>> clashes due to its transitive dependencies ... I will try again !
>>>
>>>
>>> On Wed, Mar 26, 2025 at 11:37 PM Jing Fu <jing_fu using brown.edu> wrote:
>>>
>>>> Dear Bioconductor Team,
>>>>
>>>> I am the developer of the package CARDspa, which was recently submitted
>>>> to Bioconductor. While checking the package on the Linux Kunpeng2 platform,
>>>> the build fails with the following error:
>>>>
>>>> ERROR: dependencies ‘concaveman’, ‘sf’ are not available for package
>>>> ‘CARDspa’
>>>> Perhaps try a variation of:
>>>> install.packages(c('concaveman', 'sf'))
>>>>
>>>> These two packages are listed under Imports in my DESCRIPTION file. I
>>>> understand that both packages rely on system-level libraries or are not yet
>>>> available for ARM-based architectures like Kunpeng2. Is there a preferred
>>>> way to handle such dependencies for ARM platforms?
>>>>
>>>> I look forward to your suggestions.
>>>>
>>>> Best,
>>>> Jing
>>>>
>>>>
>>>>
>>>>         [[alternative HTML version deleted]]
>>>>
>>>> _______________________________________________
>>>> Bioc-devel using r-project.org mailing list
>>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
>>>>
>>>

	[[alternative HTML version deleted]]



More information about the Bioc-devel mailing list