[geos-devel] 3.10.0beta1

[Roger Bivand]

On Sat, 2 Oct 2021, Roger Bivand wrote:

> On Fri, 1 Oct 2021, Greg Troxel wrote:
>
>>  Paul Ramsey <pramsey at cleverelephant.ca> writes:
>>
>>>  That feels... off the reservation for a library and something for the
>>>  final build? Like, not every platform requires that link, I don't think.
>>
>>  My quick reaction is that -lstdc++ seems funny for things that are
>>  compiled as C++, but if there's a link line intended to be called in a C
>>  build that's perhaps something else.   I'll see how that turns out on
>>  NetBSD shortly.
>> 
>
> Yes, R is C not C++, so the R contributed package (rgeos, sf, ...) DLL on 
> Windows from msys2 is seen as C rather than C++, see for example:
>
> https://developer.r-project.org/Blog/public/2019/03/28/use-of-c-in-packages/index.html
>
> for a discussion of general issues. The specific need here is triggered when 
> building binary contributed packages for macOS and Windows (here the Windows 
> case with gcc and msys2). See also:
>
> https://github.com/rsbivand/foss4g21/blob/main/bivand_foss4g_210930.pdf
>
> from the FOSS4G R-spatial panel two days ago, slides 2-3.

Further explanation from Tomas Kalibera, including detailed descriptions 
of our MXE cross-compilation setting (https://mxe.cc/):

I am having problems finding a documentation for geos-config, which would 
say exactly what --static-clibs and other options are supposed to return, 
it must be somewhere, but I could not find it.

I found in the README.md

     CFLAGS += `geos-config --cflags`
     LDFLAGS += `geos-config --ldflags` -lgeos_c

but it does not use --static-clibs nor other option for "libs"

The options were introduced by PR#497, 
https://trac.osgeo.org/geos/ticket/497, but the corresponding change 
https://trac.osgeo.org/geos/changeset/3832

did not add documentation.

When I use the original geos-config, my build of geos fails with

ln -sf 
'/home/tomas/toolchain/mxe/mxe/usr/x86_64-w64-mingw32.static.posix/bin/geos-config' 
'/home/tomas/toolchain/mxe/mxe/usr/bin/x86_64-w64-mingw32.static.posix-geos-config'
'x86_64-w64-mingw32.static.posix-gcc' -W -Wall -Werror -ansi -pedantic 
'/home/tomas/toolchain/mxe/mxe/src/geos-test.c' -o 
'/home/tomas/toolchain/mxe/mxe/usr/x86_64-w64-mingw32.static.posix/bin/test-geos.exe' 
`'/home/tomas/toolchain/mxe/mxe/usr/bin/x86_64-w64-mingw32.static.posix-geos-config' 
--cflags --clibs`
/home/tomas/toolchain/mxe/mxe/usr/bin/x86_64-w64-mingw32.static.posix-ld: 
/home/tomas/toolchain/mxe/mxe/usr/x86_64-w64-mingw32.static.posix/lib/libgeos_c.a(libgeos_c_la-geos_ts_c.o):/home/tomas/toolchain/mxe/mxe/tmp-geos-x86_64-w64-mingw32.static.posix/geos-3.9.1/capi/geos_ts_c.cpp:330: 
undefined reference to `__cxa_allocate_exception'

  so test-geos.exe cannot be linked. This test is part of the MXE 
configuration for geos, meant to test that the library can be linked 
properly:

     '$(TARGET)-gcc' \
         -W -Wall -Werror -ansi -pedantic \
         '$(TEST_FILE)' -o '$(PREFIX)/$(TARGET)/bin/test-geos.exe' \
         `'$(PREFIX)/bin/$(TARGET)-geos-config' --cflags --clibs`

So, this boils down to the original question what "--clibs" is supposed to 
do. Is the test correct or should it be changed?

If I understand the general comment correctly, yes, it might require some 
effort to find out how to link the standard C++ library on different 
platforms and with different compilers, and I don't have a suggestion 
ready how to do that in scope of geos. But shouldn't this be exactly what 
geos-config should do for the users? That is, perhaps autoconfig/cmake 
should find out the correct options and fill in geos-config appropriately?

RSB: Since geos-config knows its build environment at build time (when it 
is written after processing from geos-config.in), this seems reasonable; 
the problem was the same with autoconf previously too, so this is not a 
cmake issue.

Roger

>
> Roger
>
>

-- 
Roger Bivand
Emeritus Professor
Department of Economics, Norwegian School of Economics,
Postboks 3490 Ytre Sandviken, 5045 Bergen, Norway.
e-mail: Roger.Bivand at nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en