On Sat, 2 Oct 2021, Roger Bivand wrote:
On Fri, 1 Oct 2021, Greg Troxel wrote:
Paul Ramsey <pram...@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.biv...@nhh.no
https://orcid.org/0000-0003-2392-6140
https://scholar.google.no/citations?user=AWeghB0AAAAJ&hl=en
_______________________________________________
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
