Re: Committers + EvenR
> It would be about time to stop calling that role "committer", btw, > as with `git` everyone has commit rights, we should find some other > word (same problem with most other projects). Indeed. Obviously we should call it "pusher".
Re: coderabbit AI as a committer ?
Brian M Hamlin writes: > if coderabbit AI makes a complete PR in the future, and a GEOS team > member approves and merges it, what is the committer attribution? Is > the "author" of that commit now "coderabbitai" .. are there legal > implications for the project? code generated by "AI" is basically a copyright violation, and thus may not be added to the project. I think that's pretty obvious and not really open to debate, but of course others may differ.
Re: [geos-devel] [postgis-devel] MacOS DYLD Fix
Paul Ramsey via postgis-devel writes: >> On Nov 10, 2023, at 3:46 PM, Regina Obe wrote: >> >> This isn’t an issue with other projects besides PostGIS that use GEOS? >> Perhaps related, how much trouble would it be to get PostGIS to use >> pkgconfig for GEOS. I see that GEOS does ship pkgconfig files. > > We could probably do it on a going-forward basis, but per usual we’d > end up with all the old code *plus* the pkgconfig code, so it wouldn’t > really “clean up” anything. There are autoconf macros already in > configure.ac doing pkgconfig stuff on other deps, so not too too hard > of an add. We need the old code because postgis allows geos that is too old for pkgconfig? I lean to use pkgconfig if it exists and then drop support for not-pkgconfig when geos that doesn't do it ages out. >> It’s always annoying when I try to do it that I have to explicitly >> specify the geos-config file in PostGIS when in other cases, we can >> read the pkg-config and have in fact standardized on that for other >> dependencies we use. >> >> I’ve added PostGIS dev to this since well we seem to be talking about >> PostGIS now. > > I’m honestly at a bit of a loss as to whether installing with an rpath > and expecting linking software to set an appropriate search path is > the right thing, or locking in a fixed installation location is the > right thing. Certainly the latter results in less nonsense in the > postgis build. But it broke proj, which had some tests that expected > to be able to manually move an installation post-install. Software that searches for a library should (again speaking normally not macOS-ish), should after finding the lib in prefix add -I$prefix/include to CPPFLAGS add -L$prefix/lib -Wl,-R$prefix/lib -lfoo to LDFLAGS/LDADD or however R, rpath, should be. this is basically from pkgconfig's misnamed flags: $ pkg-config --cflags geos; pkg-config --libs geos -I/usr/pkg/include -L/usr/pkg/lib -lgeos_c Installed pkgconfig files often get this wrong and omit the rpath. That's ok to do if $prefix/lib is in the system's default search path, which it isn't in this case. glib, in contrast, produces: $ pkg-config --cflags glib-2.0; pkg-config --libs glib-2.0 -I/usr/pkg/include/glib-2.0 -I/usr/pkg/lib/glib-2.0/include -I/usr/pkg/include -Wl,-R/usr/pkg/lib -L/usr/pkg/lib -lglib-2.0 -lintl For pkgsrc, this missing -R is not in practice a problem in almost all cases because almost everything is in /usr/pkg (or /opt/pkg, but the same place) and there is an overall -R for that. When things are in a subprefix (for parallel installation of multiple versions), it matters more. For Debian and most GNU/Linux distributions, everything is in /usr and thus in the default path. Running objdump -x on /usr/pkg/lib/libgeos_c.so: NEEDED libgeos.so.3.12.0 NEEDED libstdc++.so.9 NEEDED libm.so.0 NEEDED libgcc_s.so.1 NEEDED libc.so.12 SONAME libgeos_c.so.1 RPATH/usr/pkg/lib and that seems right. That RPATH really is needed formally as one cannot assume that the program linking in geos_c has RPATH, only that it found geos_c. It sounds like the issue is that macOS does things differently and we weren't ending up with the equivalent of RPATH set on macOS builds? ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] MacOS DYLD Fix
Paul Ramsey via geos-devel writes: > I’m on both sides of the argument now. The best/better practice might > be to leave the install behaviour as-is and try to coerce PostGIS into > ensuring the LD_RPATH on postgis.so, and other targets is set to the > discovered locations of the dylib files in the ./configure. I don't follow. If a shared library A needs another shared library B to load, then it needs to set RPATH (however that is spelled on systems that are Different) for the path where B is. When a program links with A, it needs to set RPATH to fine A. I can see why /usr/local/lib no longer being in a default search path would cause this to be noticed, but surely /opt/pkg/lib and /foo/bar/lib were never there, so this seems like a bug fix. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12 release warning
Sebastiaan Couwenberg writes: > Warning message: > In fun(libname, pkgname) : > rgeos: versions of GEOS runtime 3.12.0beta2-CAPI-1.18.0 > and GEOS at installation 3.11.1-CAPI-1.17.1differ Also, I found that geoe does not use the just-built library when running tests, due to inadequate RPATH/LD_LIBRARY_PATH, so if you are testing 3.12 on a system with 3.11 installed, the tests may be running 3.11 code. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
"Regina Obe" writes: >> On Thu, Jun 15, 2023 at 6:30 AM Greg Troxel wrote: >> >> > Looking at the logs (at end), overall this smells like either a >> > systematic issue where the floating point on my system is broken, or >> > there is some slight floating point difference from x86, and geos >> > tests are very sensitive to exact FP results. But that's just guessing. >> >> In terms of CI, it's linux/windows/macos all on Intel. In terms of >> development, >> there's me on MacOS AppleSilicon, so getting a little >> Arm64 in there. It's possible there's something special about the floating >> point >> in the RPI3, but there's also a failure in unit-io-GeoJSONReader in there, >> which >> ... is not doing any heavy lifting. So I duno. As with other fun platforms >> I'm >> always open to patches. :) > > We do have 2 rasberry Pis (Arm64 and Arm32) running debian bullseye testing - > berrie and berrie64 > And those look to be showing successes. But not sure about the endian. > > https://libgeos.org/project/development/ci_status/ Interesting. Raspberry Pi culture is very much to run LE, and I have never heard of Debian doing BE on RPI. NetBSD people do occasionally, just to be difficult, I mean to help with testing. > I think we've had issues in past specific to big endian. I would expect so absent testing. Someday(tm) I will have an emulated sparc64 to run tests on. For now, I think the project should just keep my report in mind in case there are similar, but I don't think it's reasonable to ask anyone to do anything, mostly. My only suggestion for the CI page is: Avoid using '32-bit' and '64-bit' as if that describes a CPU type, using i386/x86_64 for PCs and armv7/aarch64 (or some such) for RPI/ARM. but that's just being picky about wording, not anything real. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta2
I have no clear memory of whether I ever tried to build geos or run tests on RPI3 before. I have a very very vague memory of having trouble and never having chased it down. So I am definitely not asking that the release be held for this! > https://download.osgeo.org/geos/geos-3.12.0beta2.tar.bz2 I am using gcc version 7.5.0 (nb4 20200810) On NetBSD 9 amd64, after installing it, tests all pass. [snip] Start 466: xml-validate-TestRelatePP 466/466 Test #466: xml-validate-TestRelatePP .. Passed0.01 sec 100% tests passed, 0 tests failed out of 466 Total Test time (real) = 20.89 sec On NetBSD 9 earmv7hf-el (RPI3 hardware, specifically), after installing it, most but not all tests pass. I ran it twice with the same results 96% tests passed, 18 tests failed out of 465 Total Test time (real) = 111.91 sec The following tests did not run: 377 - xml-issue-issue-geos-837 (Disabled) The following tests FAILED: 25 - unit-algorithm-construct-MaximumInscribedCircle (Subprocess aborted) 32 - unit-capi-GEOSBuffer (Subprocess aborted) 35 - unit-capi-GEOSClipByRect (Subprocess aborted) 42 - unit-capi-GEOSCoordSeq (Subprocess aborted) 62 - unit-capi-GEOSGeomGeoJSONRead (Subprocess aborted) 94 - unit-capi-GEOSInterrupt (Subprocess aborted) 104 - unit-capi-GEOSMaximumInscribedCircle (Subprocess aborted) 140 - unit-capi-GEOSUnaryUnion (Subprocess aborted) 143 - unit-capi-GEOSUnion (Subprocess aborted) 168 - unit-geom-Dimension (Subprocess aborted) 212 - unit-io-GeoJSONReader (Subprocess aborted) 233 - unit-operation-buffer-BufferOp (Subprocess aborted) 240 - unit-operation-distance-IndexedFacetDistance (Subprocess aborted) 300 - xml-general-TestBuffer (Subprocess aborted) 305 - xml-general-TestDensify (Subprocess aborted) 361 - xml-issue-issue-geos-366 (Subprocess aborted) 373 - xml-issue-issue-geos-605 (Subprocess aborted) 399 - xml-misc-safe-TestBufferJagged (Subprocess aborted) Errors while running CTest Output from these tests are in: /d0/n0/pkgsrc/geography/geos/work/geos-3.12.0beta2/Testing/Temporary/LastTest.log Use "--rerun-failed --output-on-failure" to re-run the failed cases verbosely. gmake[4]: *** [Makefile:91: test] Error 8 gmake[4]: Leaving directory '/d0/n0/pkgsrc/geography/geos/work/geos-3.12.0beta2' *** Error code 2 Looking at the logs (at end), overall this smells like either a systematic issue where the floating point on my system is broken, or there is some slight floating point difference from x86, and geos tests are very sensitive to exact FP results. But that's just guessing. I'm building for NetBSD 9 i386 and will also try macOS x86_64. FWIW, I ran paranoia and got: No failures, defects nor flaws have been discovered. Rounding appears to conform to the proposed IEEE standard P754. The arithmetic diagnosed appears to be Excellent! I am curious if others have been running tests on CPUs other than x86, and on those systems, if other than GNU/Linux. Here's the output of "ctest --rerun-failed --output-on-failure": Test project /usr/pkgsrc/geography/geos/work/geos-3.12.0beta2 Start 25: unit-algorithm-construct-MaximumInscribedCircle 1/18 Test #25: unit-algorithm-construct-MaximumInscribedCircle ...Subprocess aborted***Exception: 0.40 sec === GEOS Unit Test Suite === geos::algorithm::construct::MaximumInscribedCircle: ...terminate called after throwing an instance of 'geos::util::GEOSException' what(): Non-finite envelope encountered. Start 32: unit-capi-GEOSBuffer 2/18 Test #32: unit-capi-GEOSBuffer ..Subprocess aborted***Exception: 0.09 sec === GEOS Unit Test Suite === capi::GEOSBuffer: .NOTICE: IllegalArgumentException: Invalid buffer endCap style NOTICE: IllegalArgumentException: Invalid buffer join style .terminate called after throwing an instance of 'geos::util::GEOSException' what(): Shell empty after removing invalid points Start 35: unit-capi-GEOSClipByRect 3/18 Test #35: unit-capi-GEOSClipByRect ..Subprocess aborted***Exception: 0.09 sec === GEOS Unit Test Suite === capi::GEOSClipByRect: .terminate called after throwing an instance of 'geos::util::IllegalArgumentException' what(): IllegalArgumentException: Invalid number of points in LinearRing found 3 - must be 0 or >= 4 Start 42: unit-capi-GEOSCoordSeq 4/18 Test #42: unit-capi-GEOSCoordSeq Subprocess aborted***Exception: 0.08 sec
Re: [geos-devel] 3.12.0beta2
This is of course not a request to hold the release; just a comment on something that I don't yet understand. I am able to run tests by installing the just built geos and then running them. The plot thickens on the meta test issues. I built on RPI3 under NetBSD; geos had not been previously installed (because that CPU, 1 GB RAM, and no monitor or keyboard makes for a poor qgis experience!). The tests all failed, which if the issue was rpath order should not be. I then looked into the build dir: /usr/pkgsrc/geography/geos/work/geos-3.12.0beta2/bin $ ldd test_xmltester test_xmltester: -lgeos.3.12.0 => not found -lstdc++.9 => /usr/lib/libstdc++.so.9 -lm.0 => /usr/lib/libm.so.0 -lc.12 => /usr/lib/libc.so.12 objdump says NEEDED libgeos.so.3.12.0 NEEDED libstdc++.so.9 NEEDED libm.so.0 NEEDED libc.so.12 RPATH/usr/pkg/lib which is ok for an installed program, but not one that intends to use a library from the build tree. I see 'make test' runs ctest, but I can't follow how that is supposed to set up LD_LIBRARY_PATH to pre-load from the built but not installed library. I can't find 'LD_LIBR' by grepping the source tree. I know autoconf/libtool links once in the tree and relinks at install time -- but I do not have the impression cmake does it that way. I wonder if for others, tests work from a build, in the case of no geos at all installed on the system, and what ldd/objdump says on bin/test_xmltester after building. Can anyone explain the theory of how the tests are run linking against the just-built library instead of one that is (or is not) installed in the system? ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
Paul Ramsey writes: >> On Jun 7, 2023, at 5:26 PM, Greg Troxel wrote: >> >> If I install the 3.12.0beta1 package, then the tests pass. So there is >> a bug, but it is that the tests appaprently refer to installed files, >> rather than being controlled to use only files in the build tree. > > We had this out last release, it’s specific to a particular OS. Happy to look > over a cmake patch. > > https://lists.osgeo.org/pipermail/geos-devel/2022-June/010723.html I didn't remember anything from the last release... Are you saying that on every other OS, including some other BSD, that if one has installed to a prefix not in the default search paths, and has the old version installed, and runs the tests after building the new version, that they succeed? I did not absorb that from reading the archives. I am not particularly skilled at cmake, but I did find a note (that I managed not to read this time) that the problem is misordering RPATH args, so that the rpath passed in from a packaging system that says to find any depending libs in $prefix/lib happens before the special test rpath that says to get libs from something like builddir/lib. If that's true, this isn't OS specific (and is a regression from the autotools build). But I understand where you are coming from as ENOPATCH. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
If I install the 3.12.0beta1 package, then the tests pass. So there is a bug, but it is that the tests appaprently refer to installed files, rather than being controlled to use only files in the build tree. This requires alternate rpath processing, etc., and in the autoconf world is usually handled by libtool relinking at install time. Therefore, I have no reason to think 3.12.0beta1 is more troubled than any previous release -- this is likely not a regression. My only question then about 3.12.0beta1 is if the comings-and-goings diff of .h files is what the authors intend. I am kicking off a process to rebuild everything that depends on geos (that I have installed, but that extends all the way to postis and qgis). ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.12.0beta1
Paul Ramsey writes:
> First tagged release auto built and available at
>
> https://github.com/libgeos/geos/releases/tag/3.12.0beta1
distfile not found at standard release location but I fetched it
manually from github.
With the following changes, the package built. The Makefile is just the
version change, and is of course fine. The PLIST is basically about the
change in the set of installed files. There are a surprising amount of
.h files coming and going. I see some "new things" in NEWS, but the
withdrawals (mainly CoordinateArraySequenceFoo) are not really
explained.
Tests (netbsd 9 amd64) are a total train wreck, with nothign at all
passing, a sure sign of structural test issues. I will try tests on the
most recent formal release.
Index: Makefile
===
RCS file: /cvsroot/pkgsrc/geography/geos/Makefile,v
retrieving revision 1.46
diff -u -p -r1.46 Makefile
--- Makefile17 Mar 2023 15:16:47 - 1.46
+++ Makefile7 Jun 2023 23:27:04 -
@@ -1,8 +1,8 @@
# $NetBSD: Makefile,v 1.46 2023/03/17 15:16:47 gdt Exp $
-VERSION_BASE= 3.11.2
+VERSION_BASE= 3.12.0
# Accomodate testing unreleased versions.
-#VERSION_RC= rc0
+VERSION_RC=beta1
VERSION= ${VERSION_BASE}${VERSION_RC}
DISTNAME= geos-${VERSION}
EXTRACT_SUFX= .tar.bz2
Index: PLIST
===
RCS file: /cvsroot/pkgsrc/geography/geos/PLIST,v
retrieving revision 1.24
diff -u -p -r1.24 PLIST
--- PLIST 17 Mar 2023 15:16:47 - 1.24
+++ PLIST 7 Jun 2023 23:27:04 -
@@ -14,9 +14,11 @@ include/geos/algorithm/HCoordinate.h
include/geos/algorithm/InteriorPointArea.h
include/geos/algorithm/InteriorPointLine.h
include/geos/algorithm/InteriorPointPoint.h
+include/geos/algorithm/Interpolate.h
include/geos/algorithm/Intersection.h
include/geos/algorithm/Length.h
include/geos/algorithm/LineIntersector.h
+include/geos/algorithm/MinimumAreaRectangle.h
include/geos/algorithm/MinimumBoundingCircle.h
include/geos/algorithm/MinimumDiameter.h
include/geos/algorithm/NotRepresentableException.h
@@ -26,7 +28,7 @@ include/geos/algorithm/PointLocation.h
include/geos/algorithm/PointLocator.h
include/geos/algorithm/PolygonNodeTopology.h
include/geos/algorithm/RayCrossingCounter.h
-include/geos/algorithm/RayCrossingCounterDD.h
+include/geos/algorithm/Rectangle.h
include/geos/algorithm/RobustDeterminant.h
include/geos/algorithm/SimplePointInRing.h
include/geos/algorithm/construct/LargestEmptyCircle.h
@@ -43,6 +45,19 @@ include/geos/algorithm/locate/IndexedPoi
include/geos/algorithm/locate/PointOnGeometryLocator.h
include/geos/algorithm/locate/SimplePointInAreaLocator.h
include/geos/constants.h
+include/geos/coverage/Corner.h
+include/geos/coverage/CoverageBoundarySegmentFinder.h
+include/geos/coverage/CoverageEdge.h
+include/geos/coverage/CoverageGapFinder.h
+include/geos/coverage/CoveragePolygonValidator.h
+include/geos/coverage/CoverageRing.h
+include/geos/coverage/CoverageRingEdges.h
+include/geos/coverage/CoverageSimplifier.h
+include/geos/coverage/CoverageUnion.h
+include/geos/coverage/CoverageValidator.h
+include/geos/coverage/InvalidSegmentDetector.h
+include/geos/coverage/TPVWSimplifier.h
+include/geos/coverage/VertexRingCounter.h
include/geos/edgegraph/EdgeGraph.h
include/geos/edgegraph/EdgeGraphBuilder.h
include/geos/edgegraph/HalfEdge.h
@@ -50,17 +65,14 @@ include/geos/edgegraph/MarkHalfEdge.h
include/geos/export.h
include/geos/geom.h
include/geos/geom/Coordinate.h
-include/geos/geom/CoordinateArraySequence.h
-include/geos/geom/CoordinateArraySequenceFactory.h
include/geos/geom/CoordinateFilter.h
include/geos/geom/CoordinateList.h
include/geos/geom/CoordinateSequence.h
-include/geos/geom/CoordinateSequenceFactory.h
include/geos/geom/CoordinateSequenceFilter.h
-include/geos/geom/DefaultCoordinateSequenceFactory.h
+include/geos/geom/CoordinateSequenceIterator.h
+include/geos/geom/CoordinateSequences.h
include/geos/geom/Dimension.h
include/geos/geom/Envelope.h
-include/geos/geom/FixedSizeCoordinateSequence.h
include/geos/geom/Geometry.h
include/geos/geom/GeometryCollection.h
include/geos/geom/GeometryComponentFilter.h
@@ -194,15 +206,20 @@ include/geos/index/sweepline/SweepLineOv
include/geos/io/ByteOrderDataInStream.h
include/geos/io/ByteOrderValues.h
include/geos/io/CLocalizer.h
+include/geos/io/CheckOrdinatesFilter.h
include/geos/io/GeoJSON.h
include/geos/io/GeoJSONReader.h
include/geos/io/GeoJSONWriter.h
+include/geos/io/OrdinateSet.h
include/geos/io/ParseException.h
include/geos/io/StringTokenizer.h
include/geos/io/WKBConstants.h
include/geos/io/WKBReader.h
+include/geos/io/WKBStreamReader.h
include/geos/io/WKBWriter.h
+include/geos/io/WKTFileReader.h
include/geos/io/WKTReader.h
+include/geos/io/WKTStreamReader.h
include/geos/io/WKTWriter.h
include/geos/io/Writer.h
include/geos/linearref/ExtractLineByLocation.h
@@ -218,6 +235,7 @@
Re: [geos-devel] 3.10.5 and 3.11.2 released
In 3.11.2 vs 3.11.1 I find new files installed ERROR: The following files are in /tmp/work/geography/geos/work/.destdir/usr/pkg but not in the PLIST: ERROR: /tmp/work/geography/geos/work/.destdir/usr/pkg/include/geos/algorithm/PolygonNodeTopology.h ERROR: /tmp/work/geography/geos/work/.destdir/usr/pkg/include/geos/triangulate/polygon/PolygonNoder.h and do not immediately see adding new interfaces in NEWS, so I wanted to check that this is intended/correct before I push the update to pkgsrc. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Switching to C++14
proj in pkgsrc is behind, but it's coded 'c99 c++11', which means gcc 4.8 is probably ok and 4.9 is formally ok. But, that may not be accurate. I think of this as "what will be lost for people that don't have X". For geos, my impression is that this is needed for postgis, spatialite gdal, and hence qgis. But proj also is necessary for (on my system this minute): merkaartor-0.19.0nb2 libgeotiff-1.7.1nb3 py310-pyproj-3.2.1 osm2pgsql-1.3.0nb6 ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Switching to C++14
Daniel Baston writes: > advantage for reasons I described in a pull request [2]. I don't see a > reason not to make the change now, since it should have no effect on the > number of platforms that can build GEOS. (The only versions of gcc and MSVC > that can build GEOS also support C++14. What is the current lowest version? C++11 requires gcc 4.9, strictly, but 4.8 is often enough. Is this "4.9 worked before and will still work", or something else. In general, it's harder for people to upgrade compilers than other things, partly because C++ in practice more or less requires building everything that ends up in a binary with the same version, which means only having one. Personally, as long as gcc7 is ok, it won't bother me. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] End of Life Policy (EOL)
Martin Davis writes: > Our development resource bandwidth, and also downstream pipeline size. > > I think we should have a policy of one minor release per year (if needed) > And (try to) make them somewhat scheduled (which we already do informally, > to align with PostGIS). There's a big difference between Our current plans are to do X. We plan not to do Y. and We have a policy of releasing if Z. As a maintainer of various things, I have found people who use Free Software to act remarkably entitled as if they had a several-$K/year support contract. Thus I very much avoid anything that sounds like commitment to do something. To me, this policy is about saying that after 4 years, it's basically out of the question to have an updated version. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.11.0 Release Vote
Also, test suite passes on NetBSD 9 amd64. The bug (previously sent in email) where the tests use the installed version instead of the build tree version remains. But after I installed it and then built and run tests, they passed. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.11.0 Release Vote
Paul Ramsey writes: > 3.11.0beta2 has been out for a week, and no complaints. This is the vote on > final release of 3.11.0 I didn't get to it because it was pkgsrc's quarterly freeze week. It builds on NetBSD 9 amd64, and I've included the diff to the set of installed files, minus noise. The set of include changes is somewhat explainable from NEWS, but I'm not following. I don't mean to push on that; really I'm asking "is this what is expected?". +include/geos.h +include/geos/algorithm/hull/ConcaveHull.h +include/geos/algorithm/hull/ConcaveHullOfPolygons.h +include/geos/algorithm/hull/HullTri.h +include/geos/algorithm/hull/HullTriangulation.h +include/geos/geom/util/GeometryMapper.h +include/geos/index/VertexSequencePackedRtree.h +include/geos/noding/SegmentExtractingNoder.h +include/geos/operation/buffer/BufferCurveSetBuilder.h +include/geos/operation/buffer/OffsetCurve.h -include/geos/operation/buffer/OffsetCurveSetBuilder.h +include/geos/operation/buffer/SegmentMCIndex.h +include/geos/operation/overlayng/CoverageUnion.h -include/geos/operation/valid/ConnectedInteriorTester.h +include/geos/simplify/LinkedRing.h +include/geos/simplify/PolygonHullSimplifier.h +include/geos/simplify/RingHull.h +include/geos/simplify/RingHullIndex.h -include/geos/triangulate/polygon/VertexSequencePackedRtree.h -lib/libgeos.so.3.10.3 +lib/libgeos.so.3.11.0 lib/libgeos_c.so lib/libgeos_c.so.1 -lib/libgeos_c.so.1.16.1 +lib/libgeos_c.so.1.16.0 lib/pkgconfig/geos.pc signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] build failure of 3.10.3 on smartos (= illumos)
Paul Ramsey writes: > Well, it's super rare, platformwise so I don't really categorize it as > "our problem", but it's nice to be clearer. What's the simplest way to I said smartos but this is almost certainly most if not all solaris. > even find out if a change fixes this? I'm tempted to make everything > std::sqrt() on some kind of principle, but I have no idea if that will > actually change anything. Probably just changing the 5 to 5.0 would do > the trick. With a candidate change, I can apply it and see what happens. I don't know the C++ rules well enough to pick something that is correct by spec. If your preferred approach is changing to 5.0 (which I presume is a double constant since it is not 5.0f), then I can try that. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] build failure of 3.10.3 on smartos (= illumos)
Also, I should point out that we are carrying a patch, which seems like
it can't be related, but:
$NetBSD: patch-util_geosop_cxxopts.hpp,v 1.1 2022/03/27 13:33:21 tnn Exp $
On at least modern SunOS, int8_t is typedef'd to char, so parse_value()
that operates on int8_t& conflicts with the one that operates on char&.
--- util/geosop/cxxopts.hpp.orig2022-01-15 21:14:55.0 +
+++ util/geosop/cxxopts.hpp
@@ -677,12 +677,14 @@ namespace cxxopts
integer_parser(text, value);
}
+#if !defined(__sun)
inline
void
parse_value(const std::string& text, int8_t& value)
{
integer_parser(text, value);
}
+#endif
inline
void
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] build failure of 3.10.3 on smartos (= illumos)
pkgsrc is getting ready for quarterly branch, and I noticed geos fails to build on smartos. https://us-central.manta.mnx.io/pkgsrc/public/reports/upstream-trunk/20220620.2256/geos-3.10.3/build.log The issue is sqrt(5) leading to ambiguous overload with long double, double, float. Appparently that is supposed to be ok, and maybe cmath is supposed to be included, maybe using std::sqrt, maybe neither. And maybe c++11 is supposed to handle int as an arg to sqrt. Opinions as to whether this is a geos issue vs a smartos toolchain issue vs ? signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
"Regina Obe" writes: > It looks in the directory of the dependent executable first for dependencies > and then looks in PATH for what it couldn't find in the direct path. > I use the same trick (except export and $ signs) on Debbie and Berrie (both > Debian bots) and it works there too just overriding the > PATH > > Here is what Berrie64 build script looks like for example: > https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/ci/berrie64/cofigs.sh > #configuration where I flip the GEOS as needed > https://git.osgeo.org/gitea/postgis/postgis/src/branch/master/ci/berrie64/pg_init_start.sh > #postgresql startup script > > Though I think I had to set the LD_LIBRAY_PATH for building otherwise it > would pick up the system installed GEOS and PostgreSQL instead of my custom > compiled one. On UNIX/ELF, I don't think shared library resolution is affected by PATH. But LD_LIBRARY_PATH yes. I'll simply accept that whatever env var setup you have on windows causes shlib resolution to look in alternate places; that's pretty clearly not the problem. > All of these were compiled with CMake. I haven't used libtool on GEOS since > 3.6 or so.. > In GEOS 3.10.0 (and all cmake versions previous) -- the files in bin folder > are just the way I like them: > geos-config geosop.exe libgeos.dll libgeos_c.dll I am unfamiliar with Windows DLL naming culture. Setting aside macOS as mutant, ~all POSIX/ELF systems normally name shared libraries as libfoo.so.A.B.C A is major (or ABI breaks) B is minor (for new interfaces) C is micro (for bugfixes) On my system, shp2pgsql has NEEDED libgeos_c.so.1" because that is the ABI version it was built with. And there is a symlink with that name lrwxr-xr-x 1 root wheel 14 Nov 3 17:53 /usr/pkg/lib/libgeos_c.so -> libgeos_c.so.1 lrwxr-xr-x 1 root wheel 19 Nov 3 17:53 /usr/pkg/lib/libgeos_c.so.1 -> libgeos_c.so.1.16.0 -rwxr-xr-x 1 root wheel 315936 Nov 3 17:53 /usr/pkg/lib/libgeos_c.so.1.16.0 This allows the older ABI to be still present (such as on base system upgrades) and programs using the older ABI to find the version they need and work. It may be normal in windows not to do this, and I don't know if there if the shlib version is internal and if it is chdcked when dynamic linking. If it's not checked, this naming scheme is basically unsound. > and ldd of libgeos_c.dll looks like: > ldd /projects/geos/rel-3.10.0w64gcc81/bin/libgeos_c.dll > ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff968c3) > KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c1) > KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll > (0x7ff9663f) > msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a7) > libgcc_s_seh-1.dll => /mingw64/bin/libgcc_s_seh-1.dll (0x6144) > libgeos.dll => /projects/geos/rel-3.10.0w64gcc81/bin/libgeos.dll > (0x64c4) > libstdc++-6.dll => /mingw64/bin/libstdc++-6.dll (0x6fc4) > libwinpthread-1.dll => /mingw64/bin/libwinpthread-1.dll (0x6494) > USER32.dll => /c/WINDOWS/System32/USER32.dll (0x7ff967a6) > win32u.dll => /c/WINDOWS/System32/win32u.dll (0x7ff96677) > GDI32.dll => /c/WINDOWS/System32/GDI32.dll (0x7ff966dd) > gdi32full.dll => /c/WINDOWS/System32/gdi32full.dll (0x7ff96695) > msvcp_win.dll => /c/WINDOWS/System32/msvcp_win.dll (0x7ff96635) > ucrtbase.dll => /c/WINDOWS/System32/ucrtbase.dll (0x7ff966af) > IMM32.DLL => /c/WINDOWS/System32/IMM32.DLL (0x7ff96756) So that finds the 3.10.0 you have pointed it to, and it's not clear there is ABI version checking. > In GEOS 3.10.1 (where things started sucking as far as file names go) > geos-config geosop.exe libgeos-3.10.1.dll libgeos_c-1.dll > (I do recall my libtool builds having the full name at least for the c++ > part and that libgeos_c-1.dll that is why I assumed it was to congeal the > two systems). Ah, so now I get the -1. Is this the normal way in windows to encode the shared library version in the file? In the C++ one, is "3.10.1" a string which is the shared library major version? (I am not 100% sure that there aren't ABI breaks in libgeos.3.9.0 to libgeos-3.10.0, but as in theory nothing else loads that it doesn't matter.) If this is the windows way to have the equivalent of libgeos_c.so.1, then it seems like it is the right thing. Someday, we might need to have an ABI break in libgeos_c, even though it's been avoided so far, and that would necessitate libgeos_c.so.2. > $ ldd /projects/geos/rel-3.10.1w64gcc81/bin/libgeos_c-1.dll > ntdll.dll => /c/WINDOWS/SYSTEM32/ntdll.dll (0x7ff968c3) > KERNEL32.DLL => /c/WINDOWS/System32/KERNEL32.DLL (0x7ff967c1) > KERNELBASE.dll => /c/WINDOWS/System32/KERNELBASE.dll > (0x7ff9663f) > msvcrt.dll => /c/WINDOWS/System32/msvcrt.dll (0x7ff968a7) > libgcc_s_seh-1.dll =>
Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
"Regina Obe" writes: >> > So my PostGIS is compiled with GEOS 3.9.0, but it should work with >> > GEOS 3.11. >> >> You presumably have swapped out the geos implementation? How? >> > [Regina Obe] > I test PostGIS / PostgreSQL with a PostgreSQL launch script that sets the > path of all the key dependencies. > So I have a compiled (lots of other old geos) , GEOS 3.9.0, GEOS 3.10.0, > GEOS 3.10.1, GEOS 3.11 (main) all just different in bin path by the version. > > So when I want to compare differences I compile PostGIS with the lowest > version I want to compare > And then switch the paths in my PG launch script and then start up > PostgreSQL again. > > Ignore the windowishness of this script, pretend you see export and $ signs > instead > -- START SCRIPT -- > SET OS_BUILD=64 > SET GCC_TYPE=gcc81 > SET MINGW=C:\ming%OS_BUILD%%GCC_TYPE%\mingw%OS_BUILD% > SET PROJECTS=C:\ming%OS_BUILD%%GCC_TYPE%\projects > SET GDAL_VER=3.3.3 > #I change this > SET GEOS_VER=3.10.1 > SET PGDATA=%~dp0\data > SET PGDATABASE=postgres > SET PGUSER=postgres > SET PGPORT=5451 > : lots of other dependencies cut out to keep this shorter > @SET > PATH=%PROJECTS%\zlib\rel-zlib-%ZLIB_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS% > \CGAL\rel-cgal-%CGAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\cgal\rel-sfcga > l-%SFCGAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%MINGW%\bin;%~dp0bin;%PROJECTS%\gdal > \rel-%GDAL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\geos\rel-%GEOS_VER%w%OS_ > BUILD%%GCC_TYPE%\bin;%PROJECTS%\rel-libiconv-%ICONV_VER%w%OS_BUILD%%GCC_TYPE > %\bin;%PROJECTS%\proj\rel-%PROJ_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\lib > xml\rel-libxml2-%LIBXML_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\curl\rel-cu > rl-%CURL_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\expat\rel-expat-%EXPAT_VER > %w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\freexl\rel-freexl-%FREEXL_VER%w%OS_BUI > LD%%GCC_TYPE%\bin;%PROJECTS%\v8\%V8_VER%;%PROJECTS%\ssl\rel-openssl-%OPENSSL > _VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\sqlite\rel-sqlite%SQLite_VER%w%OS_ > BUILD%%GCC_TYPE%\bin;%PROJECTS%\protobuf\rel-%PROTOBUF_VER%w%OS_BUILD%%GCC_T > YPE%\bin;%PROJECTS%\pcre\rel-%PCRE_VER%w%OS_BUILD%%GCC_TYPE%\bin;%PROJECTS%\ > lz4\rel-lz4-%LZ4_VER%w%OS_BUILD%%GCC_TYPE%\bin;%~dp0\bin > > "%~dp0\bin\initdb" -E UTF8 -U postgres -A trust > "%~dp0\bin\pg_ctl" -D "%~dp0/data" -l logfile_%PGPORT% start > > ECHO "Click enter to stop" > pause > "%~dp0\bin\pg_ctl" -D "%~dp0/data" stop -m fast > -- END SCRIPT -- This is probably my lack of windows knowledge, but is the postgis build somehow configured to find the needed shared libraries by looking in PATH? On POSIXy systems, the libraries are looked for in DT_RPATH (or RUNPATH, a minor complication not that important). E.g. objdump -x on /usr/pkg/bin/shp2pgsql has this output: NEEDED libgeos_c.so.1 NEEDED libproj.so.15 NEEDED libsqlite3.so.1 NEEDED libpthread.so.1 NEEDED libm.so.0 NEEDED libjson-c.so.5 NEEDED libintl.so.1 NEEDED libc.so.12 RPATH/usr/pkg/lib:/usr/X11R7/lib and the same on the postgis so (that's dynamically loaded into postgresql, AIUI) is NEEDED libm.so.0 NEEDED libc++.so.1 NEEDED libgeos_c.so.1 NEEDED libproj.so.15 NEEDED libjson-c.so.5 NEEDED libprotobuf-c.so.1 NEEDED libxml2.so.2 NEEDED libz.so.1 NEEDED liblzma.so.2 NEEDED libc.so.12 NEEDED libstdc++.so.9 RPATH/usr/pkg/lib:/usr/X11R7/lib Earlier I talked about libgeos being added in, but it seems at least in the postgis build that is not happening. libgeos_c has: NEEDED libgeos.so.3.10.1 NEEDED libstdc++.so.9 NEEDED libm.so.0 NEEDED libgcc_s.so.1 NEEDED libc.so.12 SONAME libgeos_c.so.1 RPATH/usr/pkg/lib so postgis ends up with libgeos.so, but doesn't have a textual reference so replacing geos should still work. I am not finding anything that has a direct reference to libgeos, but I remember that happening, and there are notes in pkgsrc about it. However it does not seeem to be happening any more. >> Well, your real problem is that you are using windows! >> > [Regina Obe] > Is your other name Sandro. I might not be able to tell you apart anymore :) Actually we've never met, but great minds think alike! > You solved the problem :) > > Ldd Shows this: > ldd /projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll > : > ucrtbase.dll => /c/Windows/System32/ucrtbase.dll (0x7ff966af) > libgeos_c.dll => not found > : > > and I see the newer GEOS from 3.10.1 on have the file called > libgeos_c-1.dll > copying libgeos_c-1.dll back to the original name of libgeos_c.dll > fixed the issue. Well that
Re: [geos-devel] Is GEOS 3.11 C-API upward compatible with GEOS 3.9.0
"Regina Obe" writes: > I was always under the assumption that the C-API should be upward compatible > (only the C++ API is unstable). yes > Normally I can do the following: > > Compile PostGIS with GEOS say 3.9.0 > > Launch my PostgreSQL with GEOS 3.9.0 > > Then launch again with newer GEOS - in this case GEOS 3.11. That is not about API stability. It is about having the same ABI > So my PostGIS is compiled with GEOS 3.9.0, but it should work with GEOS > 3.11. You presumably have swapped out the geos implementation? How? > What I am finding is it is not. I thought maybe I had the paths wrong so I > double-checked a couple of times. > > This is what I get when I swap out the older GEOS 3.9.0 with newer GEOS 3.11 > (main branch) > > And then run any PostGIS function. > > ERROR: could not load library > "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": > The specified module could not be found. Well, your real problem is that you are using windows! That error doesn't show what couldn't be found, and I'd suggest the equivalent of objdump and ldd. > I then tried to swap with GEOS 3.10.0 and that worked okay. > POSTGIS="3.2.0dev 3.2.0beta3-2-g0b32bdd14" [EXTENSION] PGSQL="140" > GEOS="3.10.0-CAPI-1.16.0" PROJ="7.2.1" GDAL="GDAL 3.3.3, released > 2021/10/25" LIBXML="2.9.9" LIBJSON="0.12" LIBPROTOBUF="1.2.1" WAGYU="0.5.0 > (Internal)" TOPOLOGY RASTER > > GEOS 3.10.1 - errors > ERROR: could not load library > "C:/ming64gcc81/projects/postgresql/rel/pg14w64gcc81/lib/postgis-3.2.dll": > The specified module could not be found. > > Can someone confirm that? If it's just an issue with PostGIS 3.2, I guess > that is okay, though I would think it would mean just the newer features > like MakeValid would not be enabled by swapping out with a newer GEOS, but > it shouldn't break install. Also why GEOS 3.10.0 works and GEOS 3.10.1 > doesn't is very concerning. But seriously, that doesn't sound right. One issue is that the c library has a (on POSIX) DT_NEEDED for the C++, and sometimes (libtool?) when building a program that links with libgeos_c, the libraries that libgeos_c depend on are also added at DT_NEEDED to the program. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
Paul Ramsey writes: > Let me know what happens on your system? The destdir has RPATH of the prefix, and the tests have RPATH of only the build tree. The tests all pass (which is good, because that's really what matters as the present discussion is about the test harness, and not about the soundness of the resulting install). So this approach works for geos because it's a special case, but it won't work for programs with dependencies. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
Paul Ramsey writes:
> I'm running your script now, but just from looking at it, this seems
> suspicious...
>
> cmake .. \
>-DCMAKE_INSTALL_PREFIX=${PREFIX} \
>-DCMAKE_BUILD_RPATH=${LIBDIR} \
>-DCMAKE_INSTALL_RPATH=${LIBDIR}
>
> My understanding of the "build rpath" is that it exists in the built
> binaries PRE install, so for build testing, PRE install, you want it
> to point into the local library location. By over-riding it and
> setting it to LIBDIR, you're saying "no no no, please put this path
> into the rpath of of the PRE install binaries". I'd guess/hope that
> removing the CMAKE_BUILD_RPATH while leaving CMAKE_INSTALL_RPATH as
> you have it is closer to the intent, but I'll play with a build
> myself.
I am trying to figure out how to deal with cmake in the general case of
a packaging system. While geos usually has no dependencies (except
pthreads which are usually part of base but not always), packages built
with cmake in general do have dependencies. When packages with
dependencies build test programs, those programs will need to find those
dependency libraries.So they need to have the prefix's libdir in
RPATH.
I think there is only one real bug, which is that cmake uses as RPATH in
the build tree:
BUILD_RPATH:/path/to/build/tree/lib
when it should be doing
/path/to/build/tree/lib:BUILD_RPATH
so that when a library is in both places it comes from the build tree.
I do not know if this is a cmake bug or a bug in geos's CMakeFiles, but
I lean to cmake because I don't see anything like this in geos
CMakeFiles.
Consider if geos happened to use libtiff.so and that was in the same
prefix we were talking about. That's a concrete example of what I'm
speaking about generally.
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0rc1 (static)
Paul Ramsey writes: > OK, this is coming directly out of https://trac.osgeo.org/geos/ticket/1103 > > If I go back to using an "OBJECT" library in building ryu, then it > gets bundled right up into libgeos.a where we want it, and your link > line is nice and simple again. That implies a minimum cmake of 3.13, > whcih is 3+ years old now. My macports gives me 3.21 by default. I > dunno, we backed out of the OBJECT library to STATIC to keep the cmake > requirement low, but that implies generating two static libs and > sticking them both on the link line. > > I'm inclined to bias towards a newer cmake and still generating one static > library. I'm usually in the camp of not wanting to have aggressive dependency requirements, so having a look and opining. pkgsrc has 3.21.2 now (and it looks like 3.21.3 just came out). 3.13.0 was released on 2018-11-20. That's almost 5 years ago, and I therefore think it's entirely reasonable to require it if it makes anything even a little bit better. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0rc1
Sandro Santilli writes: >> So this script could perhaps >> >> print out that autoconf has been removed and that one must use cmake >> >> print out a hint that "cmake -DCMAKE_INSTALL_PREFIX=/usr/foo" is a >> replacement for ./configure --prefix=/usr/foo >> >> exit with status 1, so that any well-written script/package stuff will >> fail > > That script is mine. > > I would love to still use ./configure as the switches I use are... > well, none (and --prefix, for running your test). > > Right now you DO get the WARNING printed, and I think you get a > failure if you pass any unsupported switch, is that not enough ? It's likely that environment vairables are treated differently, but I don't really care personally. I maintain my own build scripts, one for each package, and pkgsrc will switch. So it's just that I think it's unhelpful for the next person, but I can see your point that there are people for whom it is helpful. So I change my comment to "abstain'. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0rc1
(I don't see a rc1 tag in git.) I see there's configure in git, that sort of deals. However, I don't think it really does the right thing for all sorts of args that are often passed to configure, and as much as I don't enjoy cmake pain, I think it's better for people running configure especially from packaging or scripts to realize that they need to translate their world into cmake. So this script could perhaps print out that autoconf has been removed and that one must use cmake print out a hint that "cmake -DCMAKE_INSTALL_PREFIX=/usr/foo" is a replacement for ./configure --prefix=/usr/foo exit with status 1, so that any well-written script/package stuff will fail signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
tl;dr:
I've done things the cmake way and the test are still not ok.
The problem is that the test RPATH is being *appended* to the BUILD
RPATH, instead of prepended.
long version:
My build script is:
#!/bin/sh
if [ -d $HOME/bin/ccache ]; then
echo "enabling ccache"
ccache -z
PATH=$HOME/bin/ccache:$PATH
fi
PREFIX=/usr/pkg
LIBDIR=${PREFIX}/lib
# In theory, BSD make is ok.
MAKE=make
(rm -rf build destdir &&
mkdir build &&
cd build &&
cmake .. \
-DCMAKE_INSTALL_PREFIX=${PREFIX} \
-DCMAKE_BUILD_RPATH=${LIBDIR} \
-DCMAKE_INSTALL_RPATH=${LIBDIR} \
> OUT.00.cmake 2>&1 &&
${MAKE} > OUT.10.make 2>&1 &&
(${MAKE} check > OUT.20.check 2>&1 || true) && \
make DESTDIR=../destdir install > OUT.30.install 2>&1 && \
echo BUILD DONE
)
BUILD_RPATH is passed because a packaging system invoking cmake must in
general ensure that programs/libs in the build environment can find
their dependencies at test time.
Some tests pass, and some fail, with "std:alloc bad" and various other
stuff. But a quick look shows that objdump -x of one of the test
programs has:
RPATH
/usr/pkg/lib:/home/n0/gdt/SOFTWARE/GEO/GEOS/geos-master/build/lib
so I expect it to go badly. This should have been
RPATH
/home/n0/gdt/SOFTWARE/GEO/GEOS/geos-master/build/lib:/usr/pkg/lib
and then I think it would have been fine.
If anyone can tell me what cmake args I should be using instead for the
general case of a program with a correct cmake setup and which might be
finding dependencies from ${PREFIX}, I'd like to hear about it. The
list above is what I came up after reading the cmake docs pointed out by
pramsey@ and strk@.
Greg
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
Sandro Santilli writes:
> On Wed, Oct 13, 2021 at 03:41:30PM -0700, Paul Ramsey wrote:
>> Actually searching for "RPATH" here turns up all kinds of knobs if you want
>> different things done to rpath
>>
>> https://cmake.org/cmake/help/latest/manual/cmake-variables.7.html
>
> Greg might be after this:
> https://cmake.org/cmake/help/latest/variable/CMAKE_INSTALL_RPATH.html
That looks close. What I need (in general) is to be able to specify:
RPATH value to be added to BUILD and INSTALL, so that dependency
libraries can be found, both at runtime and at test time.
RPATH value to be added to INSTALL so that geos can find its own libs
and these would both be ${RPREFIX}/lib.
It seems that for cmake to get the ordering of RPATHs right, which it
currently isn't, it's likely necessary to avoid putting anything that is
rpath in a linker flag of any kind, and to only use the CMAKE_*_RPATH
variables.
So I think that means settting
CMAKE_BUILD_RPATH=/usr/pkg/lib
CMAKE_INSTALL_RPATH=/usr/pkg/lib
both, in the general case for calling cmake. For geos where pthread is
from pkgsrc, this is the actual case. For geos when there aren't any
dependencies, the BUILD could be skipped as a special case.
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
I am guessing that this script is not doing anything to set RPATH and that FreeBSD puts /usr/local/lib in the default linker path. Which is interesting because people that build things not from ports might get ports libraries linked without asking for that prefix - but that's a system preference decision without a right/wrong answer. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
Sandro Santilli writes:
> On Wed, Oct 13, 2021 at 12:08:50PM -0400, Greg Troxel wrote:
>>
>> Sandro Santilli writes:
>>
>> > What do you mean by "I like how our tests work now" ? How do they work
>> > for you ? Are them guaranteed to be using the *just_built* (rather
>> > than the *installed*) libraries ?
>>
>> I believe I've found a bug in running tests. When one passes in
>> -W,-R/usr/foo/lib to the build (in LDFLAGS), the not-installed tests end
>> up having two RPATH entries:
>>
>> /usr/foo/lib
>> /path/to/build/tree/lib
>>
>> and they are ordered that way, resulting in libgeos_c being found in
>> /usr/foo/lib.
>
> Before I go on testing this let me please ask: why would you
> pass -W,-R/usr/foo/lib to the build ?
Well, you did test (thanks!), and you did reproduce the problem, but:
Stepping back from just thinking about geos, in the context of a
packaging system, there is a desire to do things in a way that works in
the general case, rather than tightly adapating to particular systems.
In general:
${PREFIX}/lib is not necessarily in the default linker search path
a given package may depend on other libraries which are already in
${PREFIX}/lib as dependency packages
build systems often either check for libraries with a test program
with #include and compiled with -lfoo, and for this to work
the -R needs to be present.
some build systems just add -lfoo because it's documented they need
them and don't check, and in that case -R needs to be present
and in the case of pkgsrc, passing -R in LDFLAGS as the standard
approach has survived the test of time in a system that runs on many (20
in theory, probably only 10 of which have users - HP-UX no longer
counts) systems with ~25K packages.
So there could be special logic to avoid it, but on the other hand it's
possible that on one of those systems pthreads is not part of the OS and
is a package that gets depended on, and thus it would be necessary.
I realize that the world is moving from "just use it" to "packages are
expected to use pkg-config", and that's a good thing as it's a single
uniform interface. Packaging systems have to deal with such interfaces,
and do -- but it imposes a lot of work when there are boutique methods
to do things. Fortunately geos is producing a pc file, and in general
things are getting more regularized.
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
Paul Ramsey writes: > That is the case on all the platforms we've had reported except > Gregs. Tests work against the libraries built in the build directory. I am not aware of a positive report for not Mac (which does all of this stuff totally differently from normal Unix) 3.9 installed in a prefix not in the default linker search path 3.10 built for the same prefix in a way that causes RPATH entries for that prefix, as would be required for it to work when installed. My list of conditions may sound odd, but it's basically all packaging systems that aren't mac or linux, where the "base system" is in /usr and packaging things are someplace else (/usr/pkg, /usr/ports, /usr/local, varies). signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] cmake detailed comments
Sandro Santilli writes: > What do you mean by "I like how our tests work now" ? How do they work > for you ? Are them guaranteed to be using the *just_built* (rather > than the *installed*) libraries ? I believe I've found a bug in running tests. When one passes in -W,-R/usr/foo/lib to the build (in LDFLAGS), the not-installed tests end up having two RPATH entries: /usr/foo/lib /path/to/build/tree/lib and they are ordered that way, resulting in libgeos_c being found in /usr/foo/lib. So maybe strk can test (on Linux I'm guessing): build and install geos 3.9.1 as --prefix=/usr/foo build geos 3.10 by telling cmake to use /usr/foo as prefix, and passing in the environment CPPFLAGS=-I/usr/foo/include LDFLAGS="-L/usr/foo/lib -Wl,-R/usr/foo/lib" as a packaging system building everything for /usr/foo would do. Then look at the test binaries with objdump -x, ldd, and run them.I expect they will mislink against the installed geos. If so, the bug in cmake or geos cmakefiles is that the extra RPATH for tests is put after the other RPATH values, rather then being put first. Or rather, that is the bug, but if you can reproduce it that's progress in understanding its scope. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] cmake detailed comments
As this is my first release using cmake I'm reading INSTALL etc. and
have a few comments.
0) INSTALL says;
mkdir build && cd build && cmake -DCMAKE_BUILD_TYPE=Release ..
Setting `CMAKE_BUILD_TYPE` to `Release` is necessary to enable compiler
optimizations.
but CMakeLists.txt says:
# Default to release build so packagers don't release debug builds
set(DEFAULT_BUILD_TYPE Release)
[set CMAKE_BUILD_TYPE from DEFAULT]
It seems to me that it's best if building without options builds what
users ought to run. Perhaps this is changed back and forth, but it
seems better to expect people testing who want non-optimized builds for
debug clarity to use a wrapper script to build it that way. (I tend to
have a build script for things I build from git, since I need to set up
prefix and LDFLAGS anyway.)
CMAKE_BUILD_DEVELOPER seems to be default on.
1) Doing a build without CMAKE_BUILD_TYPE gets me (among other things)
-- GEOS: Using default build type: Release
-- GEOS: Developer mode ENABLED
-- GEOS: Build astyle ON
so I'm not sure if this is a release build or not. Also, I don't
understand why astyle is built. It's not installed, but it seems to be
a source maintenance tool that happens to be in the repo, not part of
geos.
2) not about cmake but this seems to slow down geos a lot to make tests
repeatable even though I would guess the answers obtained with extended
floats[q aren't really wrong, just different -- unless there is some
"geos computes according to IEEE754" spec, in which case it would be
nice if the comment explained that instead of talking about making tests
pass.
# Use -ffloat-store for 32-bit builds (needed to make some tests pass)
target_compile_options(geos_cxx_flags INTERFACE
$<$,$>:-ffloat-store>
)
3) ryu. I am not able to follow this at all.
4) tests in top-level
The tests are written as if they are regular code; tests in general need
to be marked for special linking. I don't see anything special there
either.
5) complexities of RPATH handling
I found the following, which I don't fully understand yet:
https://dev.my-gate.net/2021/08/04/understanding-rpath-with-cmake/
https://gitlab.kitware.com/cmake/community/-/wikis/doc/cmake/RPATH-handling
https://cmake.cmake.narkive.com/6f4X1K39/change-rpath-at-the-packaging-stage
and not necessarily just about cmake but:
https://docs.conan.io/en/latest/howtos/manage_shared_libraries/rpaths.html
6) non-pkgsrc build
I did a build using cmake from the command line, but aligned with how
one would build on a (normal ELF, not mac) system that puts software in
a prefix that isn't part of the default search path, and thus passing
CPPFLAGS and LDFLAGS for that prefix. I realize geos is special in that
it only depends on libc and threads (and perhaps some doc programs), but
the installed geosop and library need to have a DT_RPATH section
pointing to $prefix/lib.
Doing that, the tests failed, differently from under pkgsrc, but the
installed libgeos_c was found and it ended up with both libgeos 3.9 and
3.10 both. The reason is that the test program had both the passed-in
/usr/pkg/lib RPATH as well as the RPATH from the build directory, but
the build directory one was after the one intended for install, not
before.
I think if the build-tree RPATH used for test programs was put before
the LDFLAGS-derived RPATH, things would be better.
7) RPATH not used at install time if not in LDFLAGS
After building for prefix=/usr/pkg, and not passing in LDFLAGS, I did
make DESTDIR=../destdir install
and got the expected files under destdir, parallel to build. All of
geosop, libgeos_c, and geos.pc were missing RPATH.
So probably this is ok, as I realize opinions vary between platforms
about RPATH.
8) RPATH used at install time if passed via LDFLAGS
I did a build with the right values for my situation:
CPPFLAGS=-I/usr/pkg/include LDFLAGS="-L/usr/pkg/lib -Wl,-R/usr/pkg/lib" \
and the (destdir) installed geosop, in objdump -x:
NEEDED libgeos_c.so.1
NEEDED libgeos.so.3.10.0
NEEDED libstdc++.so.9
NEEDED libm.so.0
NEEDED libgcc_s.so.1
NEEDED libc.so.12
RPATH/usr/pkg/lib
which looks right.
However geos.pc is missing the -Wl,-R:
Libs: -L${libdir} -lgeos_c
Perhaps I'm supposed to be doing something different, but I haven't been
able to understand what yet.
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
Paul Ramsey writes: > I feel like there is an answer somewhere out there that a NetBSD > expert could find and teach us, and I'd rather not bend around the > whole setup of things because of a fairly niche platform issue. People Maybe, and I'm working on that. So far, it doesn't seem like NetBSD itself as building into a different prefix with a packaging system, on a system that expects to use RPATH. So far it feels to me like the cmake setup is in general unsound; nobody has been able to point out a mechanism by which it is supposed to do testing right. I've tried to read about this and it seems both really complicated and there seems to be a notion that package authors are supposed to put a lot of complicated stuff in cmakefiles to manage handling of rpath in lots of different enviroments, instead of this being something that cmake provides. I know I've long not been a fan of cmake (and people on the lists know that too), but people keep telling me that it's better and that it does everything autoconf does, and I feel like I often run into regressions. > can still *use* GEOS pretty easily on NetBSD > (build/install/forget). The only thing they cannot easily do is run > tests, which is inconvenient to a very small population, which I > understand includes you but I hope you'll be OK with us continuing > down the release path nonetheless. Formally, I'm not ok with it as I keep hearing that moving from autoconf to cmake doesn't involve regressions, so I don't think there should be regressions. Practically, I have limited energy and won't take it personally. For now, I'm trying to understand better, as I have to deal with cmake in a number of projects. I am going to try to actually read the cmakefiles signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
I've been looking into the test failures. My build passes LDFLAGS of -R/usr/pkg/lib, because pkgsrc builds to a prefix that is not part of the default search path. And, while geos does not depend on libraries from pkgsrc, in general packages depend on other packages and need to find their libs at runtime. The build of the tests programs use those LDFLAGS (which seems natural enough). This results in a bunch of libs being DT_NEEDED: $ objdump -x /tmp/work/geography/geos/work/geos-3.10.0beta3/bin/test_geos_unit [snip] Dynamic Section: NEEDED libgeos_c.so.1 NEEDED libgeos.so.3.10.0 NEEDED libpthread.so.1 NEEDED libstdc++.so.9 NEEDED libm.so.0 NEEDED libgcc_s.so.1 NEEDED libc.so.12 RPATH/usr/pkg/lib [snip] which is all straightforward for a program to be installed. I still have not found any mechanism that attempts to arrange for the not-installed library to be used for the test. maybe the tests should be static? signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
Paul Ramsey writes: >> On Oct 6, 2021, at 4:21 PM, Greg Troxel wrote: >> >> Do you mean that if you >> >> have geos 3.9 installed in the system, in some prefix >> >> you build 3.10 with that same prefix -- as if you are building an >> updated package >> >> you run the tests in the 3.10 dir, before you have installed the >> newpackage >> >> that the tests find the 3.10 not-installed libs and do not find the >> installed version? > > Yes, that's 100% what I mean, and my dev environment would be > well-nigh unusable were that not the case. My unit tests in my working > dir link to the libraries in the same dir, so I can test my changes, > without picking up my old system installed versions. Great, we agree on how it ought to work. I have been turning on verbose build options and have found the link line for the tests. It carries through the -R/usr/pkg/lib line from the build environment and there doesn't appear to be any mechanism to force the not-installed libs. I need to look into this further, but so far I haven't found a mechanism that arranges for the correct libs to be used. I've asked NetBSD cmake people if they understand the grand plan how this is supposed to work. (On the pthread front, I think I was confused, so let's assume it's not an issue and I'll speak up again if it is.) signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
Paul Ramsey writes: > I found the relevant CMake line, and only the unit tests should be ending > up with a link dependency to pthreads. So don't declare the library itself > as having a pthread dependency. (Maybe next release, when we get all jiggy > with multi-threaded performance work, ha ha ha) > P > > --- from cmakelists.txt > find_package(Threads) > target_link_libraries(test_geos_unit PRIVATE geos geos_c Threads::Threads) Interesting. I wonder if the tests should avoid threads if the library isn't built with threads. It seems obvious (maybe I'm wrong) that if a library is not built with threads, then a threaded program that uses it must ensure that only one library call is happening at any given time, either by calling it only from one specific thread, or having a "call into geos" mutex. I found that the geos library did get linked with -lpthread. I will reproduce that and see if I can figure out why, after moving to rc3. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
Paul Ramsey writes: > On Sat, Oct 2, 2021 at 4:07 PM Greg Troxel wrote: >> >> > Also, the tests are broken for me. Running make check fails >> > completely, and I find in the log: > > Everything works fine in MacOS, I don't have access to a broken platform to > try things out on... Thanks for looking into this. > Sparrow:~/Code/geos-git-build pramsey% otool -L bin/test_geos_unit > bin/test_geos_unit: > @rpath/libgeos_c.1.dylib (compatibility version 1.0.0, current version > 1.16.0) > @rpath/libgeos.3.10.0.dylib (compatibility version 3.10.0, current version > 3.10.0) > /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version > 800.7.0) > /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version > 1281.0.0) > > The file diffs all look reasonable to me. Some classes were added, a few > were removed. Do you mean that if you have geos 3.9 installed in the system, in some prefix you build 3.10 with that same prefix -- as if you are building an updated package you run the tests in the 3.10 dir, before you have installed the newpackage that the tests find the 3.10 not-installed libs and do not find the installed version? Are you or someone else able to try this on Linux or FreeBSD? I wonder if anyone knows if there is a mechanism that intends to allow this to work, as I don't see how it would with specific effort. I will test with pkgsrc on Mac (prefix /opt/pkg). signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
Greg Troxel writes: > Also, the tests are broken for me. Running make check fails > completely, and I find in the log: > > /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit: Shared > object "libgeos.so.3.10.0" not found > > I am running tests from the build directory before I have built a > package and then replaced the existing 3.9 installation. So in > /usr/pkg/lib, where the library is expected to be, there is > libgeos.so.3.9.0 and no 3.10. Looking at the test program: > > $ ldd /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit > /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit: > -lgeos_c.1 => /usr/pkg/lib/libgeos_c.so.1 > -lgeos-3.9.1 => /usr/pkg/lib/libgeos-3.9.1.so > -lstdc++.9 => /usr/lib/libstdc++.so.9 > -lm.0 => /usr/lib/libm.so.0 > -lc.12 => /usr/lib/libc.so.12 > -lgcc_s.1 => /usr/lib/libgcc_s.so.1 > -lgeos.3.10.0 => not found > -lpthread.1 => /usr/lib/libpthread.so.1 > > I see it's also finding the wrong libgeos_c, so the root cause is very > likely not arranging a temporary library path for testing built but not > installed code. autoconf/libtool did this correctly, with a scheme to > link test programs (and anything else) against the built but not > installed library, and then to relink at installation. There are of > course multiple approaches, but "make check" needs to use the > programs/libs in the build tree, and ignore what's installed. I worked around the bug in "make check" by installing the package, and then building it again and running tests, so that when it links against the wrong library, it finds the same bits. I was happy to see that all the tests passed, so there aren't any real geos bugs, just cmake/test bugs. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta2
Greg Troxel writes: > http://download.osgeo.org/geos/geos-3.10.0beta2.tar.bz2 [This note replaces my briefer and less coherent note from last night.] I converted my package build to cmake, and it worked better than I expected, which is great. I did my build under pkgsrc on NetBSD 9 amd64. The diff to the main packaging control file is not that interesting to others, so I'll omit it; it's basically autoconf->cmake, dropping libtool, and declaring a dependency on pthreads. The diff of the set of installed files is significant, and I've appended it. Mostly I would like someone familiar with the changes to just skim it and nod "that's all expected". There are a lot of withdrawn .h files. I try to point out anything that I see that one wouldn't expect from reading NEWS, to sort those into real bugs and NEWS omissions. I do think it's good to fix NEWS during this period. * NEWS does not mention the withdrawal of autoconf * NEWS does not mention that libtool is no longer used and that libgeos.la is no longer installed. * include/geos.h is no longer installed. I am guessing that is intentional, but it is not mentioned in NEWS. * There are several .h files no longer installed. I am guessing these are intended API withdrawals, but NEWS does not say that there are any withdrawals. An example is include/geos/operation/overlay/FuzzyPointLocator.h * The build finds and uses pthreads. Before, the build did not link to pthread, and my 3.9 libraries are not linked with threads. However, I had not declared that the package used threads, and pkgsrc's mechanisms for hiding things that aren't declared are likely more successful for autoconf than cmake. In the sources, README and INSTALL do not mention threads. I can't figure out if this matters and how, and what the right answer is. Also, the tests are broken for me. Running make check fails completely, and I find in the log: /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit: Shared object "libgeos.so.3.10.0" not found I am running tests from the build directory before I have built a package and then replaced the existing 3.9 installation. So in /usr/pkg/lib, where the library is expected to be, there is libgeos.so.3.9.0 and no 3.10. Looking at the test program: $ ldd /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit /tmp/work/geography/geos/work/geos-3.10.0beta2/bin/test_geos_unit: -lgeos_c.1 => /usr/pkg/lib/libgeos_c.so.1 -lgeos-3.9.1 => /usr/pkg/lib/libgeos-3.9.1.so -lstdc++.9 => /usr/lib/libstdc++.so.9 -lm.0 => /usr/lib/libm.so.0 -lc.12 => /usr/lib/libc.so.12 -lgcc_s.1 => /usr/lib/libgcc_s.so.1 -lgeos.3.10.0 => not found -lpthread.1 => /usr/lib/libpthread.so.1 I see it's also finding the wrong libgeos_c, so the root cause is very likely not arranging a temporary library path for testing built but not installed code. autoconf/libtool did this correctly, with a scheme to link test programs (and anything else) against the built but not installed library, and then to relink at installation. There are of course multiple approaches, but "make check" needs to use the programs/libs in the build tree, and ignore what's installed. (I haven't yet installed the package and tried to build postgis against it. I'd like to be able to run tests first.) Perhaps "make check" is the wrong thing to do, but it's what everybody expects and it lets people who have no idea about the geos test setup be able to test and get a clean pass or need to look into it. Greg Index: PLIST === RCS file: /cvsroot/pkgsrc/geography/geos/PLIST,v retrieving revision 1.17 diff -u -p -r1.17 PLIST --- PLIST 3 Jan 2021 01:27:29 - 1.17 +++ PLIST 2 Oct 2021 11:32:55 - @@ -1,10 +1,11 @@ @comment $NetBSD: PLIST,v 1.17 2021/01/03 01:27:29 gdt Exp $ bin/geos-config -include/geos.h +bin/geosop include/geos/algorithm/Angle.h include/geos/algorithm/Area.h include/geos/algorithm/BoundaryNodeRule.h include/geos/algorithm/CGAlgorithmsDD.h +include/geos/algorithm/CGAlgorithmsDD.inl include/geos/algorithm/CentralEndpointIntersector.h include/geos/algorithm/Centroid.h include/geos/algorithm/ConvexHull.h @@ -17,15 +18,18 @@ include/geos/algorithm/InteriorPointPoin include/geos/algorithm/Intersection.h include/geos/algorithm/Length.h include/geos/algorithm/LineIntersector.h +include/geos/algorithm/LineIntersector.inl include/geos/algorithm/MinimumBoundingCircle.h include/geos/algorithm/MinimumDiameter.h include/geos/algorithm/NotRepresentableException.h include/geos/algorithm/Orientation.h +include/geos/algorithm/PointInRing.h include/geos/algorithm/PointLocation.h include/geos/algorithm/PointLocator.h include/geos/algorithm/RayCrossingCounter.h include/geos/algori
Re: [geos-devel] 3.10.0beta2
Paul Ramsey writes: > Here it is incorporating Sebs feedback, I'm going to try and be pretty > aggressive about pushing new packages so there's always something worth > testing against. Thanks. From my viewpoint a new tarball every time there's a signficant fix is good. > http://download.osgeo.org/geos/geos-3.10.0beta2.tar.bz2 Converting my build to cmake worked much better than I expected. Relative to NEWS I see a few things I don't follow: a bunch of API withdrawals, I think. include/geos.h is no longer installed and more seriously, running tests fails because it apparently doesn't use the built-but-not-installed libraries. I'll say this again more coherently tomorrow or Sunday. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta1
Paul Ramsey 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. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.10.0beta1
I don't care what the word is, but in my view a release which makes the massive change of dropping automake can't really be called beta, so I think we need to view this as more alpha like. I'll try to get to converting the package to cmake and testing soon, but it may take until Monday when it is raining. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] The Road to 3.10
Mike Taves writes: > On Thu, 30 Sept 2021 at 05:16, Paul Ramsey wrote: >> So the next step on the road to 3.10 is an interim release. I'd like >> to go right to beta1. If I don't hear any howls in the next 24-48 >> hours, I will cut that package so we can get our packager friends to >> take it for a spin. > > I have two pull requests that are ready to review: > - https://github.com/libgeos/geos/pull/445 > - https://github.com/libgeos/geos/pull/447 is this support already present in autoconf, and this is just cmake catching up? AIUI autoconf is still at least supported, and it's what pkgsrc is using. (In general, I find that every time a package switches to cmake it requires a bunch of patching of cmakefiles. Often they have "ifdef FooOS" rather than feature tests, but perhaps geos is free of that.) signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] The Road to 3.10
"Regina Obe" writes: > BTW according to Myon, they are planning to release PostgreSQL 14 this > Thursday (tomorrow) so I think our PostGIS 3.2.0 is going to be a little > later than PostgreSQL 14 release but hopefully we can coax packagers to > release it. > > That said PostGIS release isn't really that impacted by GEOS 3.10 release. > Few packagers are going to be jumping to carry GEOS 3.10 as I think we > already missed the big OS release cycles. > > Packagers please speak up if I have misspoken. I think there are more packaging systems than anybody really knows about with all sorts of release cycles. My reactions to the larger picture is: a beta1 means that it's thought to be pretty close, and definitely feature freeze, and that it needs more shaking out and testing than an rc. The idea of adding in features that aren't already working in main/trunk/master/whatever post beta seems off. If we are talking release within 15 or maybe even 30 days adding features seems too much regardless of what it's called. As a packager I don't care if 3.11 comes only a month or two after 3.10. I would like to know that 3.10.x is just bugfixes and no API/ABI breaks and therefore safe to update within a stable packaging branch. What really hurts in packaging is needing to synchronize things. The upcoming postgis release needs to work with a bunch of pgsql versions, not necessarily IMHO the released-tomorrow one, and it should work with all geos versions releaseed a year ago or more recently. With 3.10, I'd want to read NEWS to see if there any impacts onn existing code. With any luck, nothing is withdrawn that any even semi-maintained depending package uses, and all will build and work. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] The Road to 3.10
Paul Ramsey writes: > One thing worthy of discussion is pushing forward the cmake > dependency. If we pop forward to 3.12 we can fix this issue cleanly by > using OBJECT instead of STATIC linking for our vendored deps. > > https://github.com/libgeos/geos/issues/463 > > 3.12.0 was released in 2018. I personally at this point just use the > latest cmake build, which is so easy to do (download package, unzip in > /usr/local). I am a trailing edge type. 3.12 from 2018 sounds ancient even to me and it's hard to believe any system with 3.11 can cope with much of anything these days. So changing the cmake rule to 3.12 seems entirely reasonable. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Backporting geosop?
Martin Davis writes: > Autotools is still supported for versions <= 3.9.x. > > Not being an autotools expert, I was concerned about breaking something. > And since this is an optional tool, it wasn't clear that it would be needed > in packages. However, I can see that might be desirable. So maybe > autotools build is needed. From the packaging point of view, I'd say that either it shouldn't exist or it should be packagable. Essentially all people use things via packaging systems, despite almost all people who develop a particular thing not using packaging for it. For <=3.9, I feel like if it is built with cmake it needs to be built --- and distributed with make dist -- with autotools. OTOH if nobody needs it, then it can just not come to the branch, and people who want to play with it can build from devel sources. I would expect that it isn't hard to add it, but I haven't dug in. It looks like a bunch of cpp files to build and link together, and that's pretty normal and compact in a declarative Makefile.am. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] Backporting geosop?
Martin Davis writes: > I'm thinking about committing back-ported versions of geosop to 3.9, 3.8 > and 3.7. > > Any objections? And any further objections if I don't bother with the > autotools build setup? The pkgsrc packge for geos is at at 3.9.1, which I think is current, and is using configure. I really don't follow your question. Has there been a formal withdrawal of the autotools build? If so, then it follows that it is not supported and presumably would be removed. If not, it seems out of the question to commit something that doesn't work right with it. And, it would seem very surprising to withdraw a build system on a stable branch. Looking, 3.9.1's INSTALL says autotools works. So committing something to the 3.9 branch that breaks that seems not ok. I feel like I must be missing something. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.9.0 Released
Daniel Baston writes:
>>
>> Some headers I see were installed as a facility for C++ library users.
>> Nowadays we discourage those users so I don't see any big problem with
>> them being removed (like opBuffer.h and io.h)
>>
>
> I think this comment is about https://trac.osgeo.org/geos/ticket/999. That
> probably should have been in the NEWS if it was not.
>
> Because listserv chatter sometimes becomes a source of documentation for
> users, I think it's important to point out that the GEOS project ("we") has
> no policy of discouraging use by C++ library users.
That seems to be a policy change that I missed. We had this discussion
quite a while ago and the README said the C++ interface shouldn't be
used after that discussion. I then updated the comment in the geos
pkgsrc package to note that it was a bug for other packages to use the
C++ interface, and thus there was no need to consider the geos package
to have had an ABI change because of actual ABI changes or the usual C++
"C++ is so complicated we have no way to know if the ABI changed, so
change the shlib version, and then we know it did!" always-on ABI change.
Now the README just says that the C++ interface is unstable, to the
point where changes in it are not worthy of being mentioned in NEWS, let
along having some API compat and transition strategy. That is just
about equivalent to a recommendation not to use it.
I should point out that I don't really have an agenda about whether the
C++ interface should be recommended for use. But as I see it, there
are only two reasonable options:
1) recommend that the C++ interface not be used
2) say that use is ok, and have an API stability plan where code
written to each release's API is expected to continue working for some
significant period of time (perhaps 2 years) in future releases after
an API element is deprecated (Note that to me ABI stability is not
that big a deal.)
Perhaps, say it's ok to use the C++ API as long as you don't release
your code :-)
In all seriousness, packaging systems are put into a bind when a program
B depends on interface A, A turns out to be unstable and B doesn't get
instantly updated. Any plan for what's usable and API stability has to
take that into account, for packages that actually are used by other
packages. This is basically a summary of the view that prevailed in the
last discussion, as I remember it, which is fuzzily.
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7: Discontinue use of autotools
Sebastiaan Couwenberg writes: > On 1/10/21 2:44 AM, Daniel Baston wrote: >>> >>> Make the CMake build adhere to CMAKE_INSTALL_LIBDIR so that multiarch >>> keeps working, >> >> >> I created a pull request for this at >> https://github.com/libgeos/geos/pull/380 >> >> Have CMAKE_BUILD_TYPE=None define NDEBUG so that assert() is removed >>> from the code, thereby not storing the buildpath in the binaries helping >>> reproducible builds. >>> >> >> If you don't specify CMAKE_BUILD_TYPE it defaults to Release, and NDEBUG >> will be defined. > > But then -g is not used and there will be no debug symbols. > RelWithDebInfo is more what we need. > >> Do you mean that we should define a new build type called >> "None" ? > > It is used to have the buildflags set in the environment determine > optimization etc. > > CMake apparently uses the absolute path for __FILE__ whereas Autotools > uses the path relative to the Makefile. Hence we get > file-references-package-build-path issues after switching a package to > use the cmake buildsystem. So it seems that 'drop autotools' is not ready for prime time, until packaging systems can switch and report no residual issues/regressions. FWIW, pkgsrc is also using autotools to build. I can try to switch it to cmake and see how that goes. I'll be doing that on the most recent release, of course, for starters. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7: Discontinue use of autotools
Paul Ramsey writes: >> On Jan 8, 2021, at 9:25 AM, Daniel Baston wrote: >> >> I think the question we need to resolve is whether, after 11 years >> of working with and 5 years of officially supporting two build >> systems, we need to continue to spend developer effort maintaining >> both systems in order to accommodate those preferences. > > I agree. I can think of only one further technical task, which is > ensuring that the outputs of the cmake 'make dist' target are run > through to 'make check' in CI. Being able to bundle a release via > 'make dist' is a very handy thing and makes 'tag to release > automatically' a potential CI target which would also be nice. One thing autotools does that many cmake setups don't (but could) is 'make distcheck' which does make dist unpacks it does an objdir build runs make check in that does so in a way that the just-built libs are used and installed libs are ignored If that already works in cmake, fine, and if not I think that needs fixing before getting rid of autotools. The other thing is cross builds, and I have no idea what the state of that is in the geos cmake build. Often I have found that build systems proposed as a replacement for autotools don't do that. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.9.0 Released
I should add that 3.9.0 when built on NetBSD 9 amd64 with gcc 7.4.0 builds fine and passes make check. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.9.0 Released
(I am late in trying this, for no good reason.) I am doing a trial update of pkgsrc/geography/geos to 3.9.0 from 3.8.1. I am seeing a lot of header file withdrawals, and it is not clear to me that they are explained by "new overlay engine" (but also not clear that they are not explained by this). Hence I am posting my diff of installed files and would appreciate someone taking a quick scan and pronouncing "those changes are expected" vs "we have a problem". Given the new engine, I am guessing I should not update pkgsrc today since we are going into freeze within days for 12/31 quarterly stable release. Instead, I'd hold off until just after freeze. Please also let me know if you think that's confused. Thanks, Greg diff -u -p -r1.16 PLIST --- PLIST 11 Mar 2020 12:52:06 - 1.16 +++ PLIST 14 Dec 2020 19:35:01 - @@ -26,6 +26,8 @@ include/geos/algorithm/PointLocator.h include/geos/algorithm/RayCrossingCounter.h include/geos/algorithm/RayCrossingCounterDD.h include/geos/algorithm/RobustDeterminant.h +include/geos/algorithm/construct/LargestEmptyCircle.h +include/geos/algorithm/construct/MaximumInscribedCircle.h include/geos/algorithm/distance/DiscreteFrechetDistance.h include/geos/algorithm/distance/DiscreteHausdorffDistance.h include/geos/algorithm/distance/DistanceToPoint.h @@ -33,24 +35,13 @@ include/geos/algorithm/distance/PointPai include/geos/algorithm/locate/IndexedPointInAreaLocator.h include/geos/algorithm/locate/PointOnGeometryLocator.h include/geos/algorithm/locate/SimplePointInAreaLocator.h -include/geos/algorithm/ttmath/ttmath.h -include/geos/algorithm/ttmath/ttmathbig.h -include/geos/algorithm/ttmath/ttmathdec.h -include/geos/algorithm/ttmath/ttmathint.h -include/geos/algorithm/ttmath/ttmathmisc.h -include/geos/algorithm/ttmath/ttmathobjects.h -include/geos/algorithm/ttmath/ttmathparser.h -include/geos/algorithm/ttmath/ttmaththreads.h -include/geos/algorithm/ttmath/ttmathtypes.h -include/geos/algorithm/ttmath/ttmathuint.h -include/geos/algorithm/ttmath/ttmathuint_noasm.h -include/geos/algorithm/ttmath/ttmathuint_x86.h -include/geos/algorithm/ttmath/ttmathuint_x86_64.h -include/geos/algorithm/ttmath/ttmathuint_x86_64_msvc.asm include/geos/constants.h +include/geos/edgegraph/EdgeGraph.h +include/geos/edgegraph/EdgeGraphBuilder.h +include/geos/edgegraph/HalfEdge.h +include/geos/edgegraph/MarkHalfEdge.h include/geos/export.h include/geos/geom.h -include/geos/geom/BinaryOp.h include/geos/geom/Coordinate.h include/geos/geom/Coordinate.inl include/geos/geom/CoordinateArraySequence.h @@ -73,6 +64,7 @@ include/geos/geom/GeometryComponentFilte include/geos/geom/GeometryFactory.h include/geos/geom/GeometryFactory.inl include/geos/geom/GeometryFilter.h +include/geos/geom/HeuristicOverlay.h include/geos/geom/IntersectionMatrix.h include/geos/geom/LineSegment.h include/geos/geom/LineSegment.inl @@ -86,20 +78,26 @@ include/geos/geom/MultiPolygon.h include/geos/geom/MultiPolygon.inl include/geos/geom/Point.h include/geos/geom/Polygon.h +include/geos/geom/Position.h include/geos/geom/PrecisionModel.h include/geos/geom/PrecisionModel.inl +include/geos/geom/Quadrant.h +include/geos/geom/Quadrant.inl include/geos/geom/Triangle.h include/geos/geom/prep/AbstractPreparedPolygonContains.h include/geos/geom/prep/BasicPreparedGeometry.h include/geos/geom/prep/PreparedGeometry.h include/geos/geom/prep/PreparedGeometryFactory.h include/geos/geom/prep/PreparedLineString.h +include/geos/geom/prep/PreparedLineStringDistance.h include/geos/geom/prep/PreparedLineStringIntersects.h +include/geos/geom/prep/PreparedLineStringNearestPoints.h include/geos/geom/prep/PreparedPoint.h include/geos/geom/prep/PreparedPolygon.h include/geos/geom/prep/PreparedPolygonContains.h include/geos/geom/prep/PreparedPolygonContainsProperly.h include/geos/geom/prep/PreparedPolygonCovers.h +include/geos/geom/prep/PreparedPolygonDistance.h include/geos/geom/prep/PreparedPolygonIntersects.h include/geos/geom/prep/PreparedPolygonPredicate.h include/geos/geom/util/ComponentCoordinateExtracter.h @@ -115,8 +113,6 @@ include/geos/geom/util/PointExtracter.h include/geos/geom/util/PolygonExtracter.h include/geos/geom/util/ShortCircuitedGeometryVisitor.h include/geos/geom/util/SineStarFactory.h -include/geos/geomUtil.h -include/geos/geomgraph.h include/geos/geomgraph/Depth.h include/geos/geomgraph/Depth.inl include/geos/geomgraph/DirectedEdge.h @@ -139,9 +135,6 @@ include/geos/geomgraph/Node.h include/geos/geomgraph/NodeFactory.h include/geos/geomgraph/NodeMap.h include/geos/geomgraph/PlanarGraph.h -include/geos/geomgraph/Position.h -include/geos/geomgraph/Quadrant.h -include/geos/geomgraph/Quadrant.inl include/geos/geomgraph/TopologyLocation.h include/geos/geomgraph/TopologyLocation.inl include/geos/geomgraph/index/EdgeSetIntersector.h @@ -156,8 +149,6 @@ include/geos/geomgraph/index/SimpleSweep include/geos/geomgraph/index/SweepLineEvent.h
Re: [geos-devel] Motion: stop brain damage and move finally to github as primary repository
Sandro Santilli writes: > On Thu, Oct 01, 2020 at 11:03:29PM +0200, Even Rouault wrote: >> Hi, >> >> Github is a proprietary trap, but not being on it as the >> primary repository is just a waste of time and a lost battle. > > The battle is only lost if you don't fight it. > > --strk; Obviously I'm not on PSC, but I agreed with strk. I have always found the willingness of open source projects to use github distressing. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] --ldflags oddness in geos-config
Greg Troxel writes:
> Plus, it seems all the --libs stanzas have -L${exec_prefix}/lib in them,
> even though those are lddfags, not libs.
Theory:
geos considers "libs" to be
-L$prefix/lib -lgeos_c
and "ldflags" to be extra stuff
So in addition to my patch, probably the -L in ldflags should be
dropped.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] --ldflags oddness in geos-config
pkgsrc is carrying this patch. When expanded in our build, this turns
into
--ldflags)
echo -L${exec_prefix}/lib -Wl,-R/usr/pkg/lib
;;
It seems clear that the rpath type instructions need to be continued on;
without it the build of the program that depends on geos will be wrong.
(I'm not clear on why the -L argument doesn't get duplicated.)
Plus, it seems all the --libs stanzas have -L${exec_prefix}/lib in them,
even though those are lddfags, not libs.
Does this work for anyone, intalling into a prefix not in the default
link path, and using geos-config to build something against geos to a
third prefix so that there isn't a rpath command for the geos libdir?
Thoughts?
--- tools/geos-config.in.orig 2019-10-03 17:32:04.0 +
+++ tools/geos-config.in
@@ -58,7 +58,7 @@ case $1 in
echo -L@libdir@ -lgeos -lm
;;
--ldflags)
- echo -L@libdir@
+ echo -L@libdir@ @LDFLAGS@
;;
--includes)
echo @prefix@/include
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
Sandro Santilli writes: > Few-years-ago dependency could be fine, given GEOS requires C++10 now, > or we could just use quotes and allow for spaces in path names (while > still forbidding quotes and dollars etc. ?) (I realize this is moot with the simple space escaping you just added. Yay!) If you mean GNU Coreutils printf as "few-years-ago dependency", I don't follow. That is typical on GNU/Linux, but on BSD there is a different /usr/bin/printf which lacks %q but I believe conforms to POSIX. (As an aside, I think it's often not a good thing for programs that are required by POSIX to add extensions; that leads to people writing nonportable code. The poster child of this is bash and test ==.) ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
Sandro Santilli writes: > Escaping can also be done in POSIX shell, not a big deal. > Let's just understand what we really need. For instance, > how do we want the output of `geos-config --libs` look like, > when there's a space in the path ? > > 0. -L/usr/local silly/lib -lgeos-3.9.0 > 1. -L/usr/local\ silly/lib -lgeos-3.9.0 > 2. -L"/usr/local silly/lib" -lgeos-3.9.0 > 3. -L'/usr/local silly/lib' -lgeos-3.9.0 > > We got 0 before the change... > > With c263a0f7 I went with option 1, and restored proper output in > presence of an exec_prefix. I think 1 is reasonable. I am inclined to say: let's call it a day and wait for an actual bug report from an actual user (not a contrived test case) to address any further nonstandard characters in prefixes. This really feels like a non-problem to me, at least once spaces are handled. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
Mike Taves writes: > On Wed, 19 Feb 2020 at 03:11, Greg Troxel wrote: >> In searching for the POSIX printf spec, I found this post about escaping >> spaces in a portable manner. >> >> >> https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q >> >> The specs at opengroup.org seem hard to deal with today - not sure if >> they changed - but I found this POSIX printf description: >> >> https://www.unix.com/man-page/POSIX/1posix/printf/ > > Thanks for the resources! Thank you for listening (seriously). We are, amusingly enough, moving to a point where there is an assumption of all linux, much like the old days when it was assumed all was windows. >> > Currently, other Bash scripts are present in tools/ci/ but these are >> > not installed with GEOS. >> >> ci tools are quite a different story than a requirement for regular >> installs, although I see using bash there (vs /bin/sh) as a bug also. > > I'll consider going over these to see if they can be POSIX /bin/sh Thanks - I don't think that's nearly as big a deal, but in my experience dealing with packaging I have found that many uses of bash were not actually necessary or very easy to avoid. One common issue is using == in test, when POSIX specifies (and Bourne shells always were) just =. >> None of the BSDs have bash by default. When it is present, via ports, >> pkgsrc, etc., it's not in /bin. On NetBSD, it's in /usr/pkg/bin/bash. >> People use it for their login shell. I do too - I'm not a bash hater, >> but object to it for programming use. It's enormous, and is one >> particular implementation among many. I view it as personal choice to >> use it for interactive use, and not appropriate for scripting. >> >> The fact that /bin/bash does not exist on *BSD, and probably other >> places, prompted my question about looking for it and substituting the >> path. Expecting bash to be in /bin/bash is just not a valid assumption. >> >> So, given that there seems to be a way to do this without introducing a >> dependenchy on bash, I'd like to see this backed out. > > Aha, so there are some that will be alienated, which I agree is a bad > situation, so I'll submit a PR to restore back to #!/bin/sh Great, thanks. > I'll remove printf %q altogether and simply insert an escaped path to > the script. I'll probably only do this with CMake, since that's the > only install solution that supports spaces. I didn't realize autoconf flat-out objected to spaces, but it is not surprising since in the old-school command line tradition spaces is files are somewhere between bizarre and unthinkable. Sounds good to just escape spaces for cmake. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
"Regina Obe" writes:
> Speaking of reverting the last change that started this whole
> discussion -- does anyone have thoughts on alternative to printf for
> sh? I would like to keep the intent if possible without causing
> backward compatibility issues.
>
> I assume these are the sections that would need reverting.
>
> https://git.osgeo.org/gitea/geos/geos/pulls/99.diff - in the
> tools/geos-config.cmake #!/bin/sh
>
> index 24a5725..abef1e3 100644
> --- a/tools/geos-config.cmake
> +++ b/tools/geos-config.cmake
> @@ -1,12 +1,12 @@
> -#!/bin/sh
> +#!/bin/bash -e
>
> -prefix=@CMAKE_INSTALL_PREFIX@
> -exec_prefix=@CMAKE_INSTALL_PREFIX@/bin
> -libdir=@CMAKE_INSTALL_PREFIX@/lib
> +# escape path
> +prefix=$(printf %q "@CMAKE_INSTALL_PREFIX@")
> +libdir=${prefix}/lib
>
> and tools/geos-config.in
>
> --- a/tools/geos-config.in
> +++ b/tools/geos-config.in
> @@ -1,11 +1,12 @@
> -#!/bin/sh
> -prefix=@prefix@
> -exec_prefix=@exec_prefix@
> -libdir=@libdir@
> +#!/bin/bash -e
> +
> +# escape paths
> +prefix=$(printf %q "@prefix@")
> +libdir=$(printf %q "@libdir@")
So assigning
prefix=@prefix@
works perfectly fine. The problem is when that is printed later.
If it's just space we are worried about, one could basically printf into
sed to change space to "\ ", and I think that's what the stack overflow
suggestion is doing.
The basic problem is that the build ecosystems assume that one can use
space to tokenize arguments. That is indeed the ancient Unix tradition,
and fighting that leads to lots of pain with quoting.
There's another problem here, which is that inserting \ for quoting is
presuming that the output of geos-config is going to be interpreted by a
shell, rather than taken as is and used to build a command line. I
suppose there is that implication because there are multiiple arguments
separated by a space. One could argue that the interface is space
separated arguments, not shell language. So overall I see allowing
spaces in prefix as heading off into not-well-defined behavior.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
This seems to explain how to accomodate spaces in pathnames and escaping them, sticking to POSIX https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q cmake is very much set up to use pkg-config; it has become the normal way by which build systems query how to link to dependency packages. I don't think it has anything to do with Visual Studio in a cmake build. I don't know anything about cmake on windows, but it doesn't make sense that this would be trouble since it is so pervasive. But I could be off. That said even if we did go down the path of pkgsrc I think we need to support geos-config for a couple of minor versions to give libraries that depend on GEOS time to change. For example PostGIS expects a geos-config file. So we'd have to change all supported versions to allow .pc for geos. (pkg-config not pkgsrc, assuming word-o). Yes, would need some compat and switchover. Many programs have moved from foo-config to a .pc over the years. On my system I have only 65 foo-config programs, compared to to 557 pkgconfig files (both in /usr/pkg, so that is an apples to apples comparison). I am pretty sure there is an idiom which looks like try to find geos via pc if not, try geos-config at least in autoconf that was a fairly normal thing to do for a while. I will observe that a strategy of: add pkgconfig more or less now decline to worry about spaces in prefix in geos-config (tell people that want to put spaces in pathnames that to use pkgconfig ;-) seems reasonable to me. But I have no objection to accomodating spaces if it doesn't add a bash or other dependency. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
Paul Ramsey writes: > Pkg config is wonderous but still far from universal Interesting. As a packager, I see a vast number of things using it, and thus a system where it isn't available as a build dependency would seem very difficult to deal with in general. I would not have suggested it if I thought anyplace would have trouble with that (except that I don't pay attention to Windows at all). On my desktop there are 557 .pc files installed from pkgsrc, 9 from the base system, and 127 from pkgsrc. Geo-examples include proj, gdal and spatialite. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
Paul Ramsey writes: > Yeah, and with Apple changing the default shell in OSX, this only gets worse > not better over time… > Could follow the pgsql project and just rewrite the thing (the config > program) in C and be done with it… Or, perhaps generate a pkgconfig file and just get rid of geos-config? There is some one-time pain, but it seems that hand-written foo-config is no longer the preferred approach. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] dependency management and PSC
I was surprised to see a hard dependency on bash land without any prior discussion on the list. I would like to see PSC adopt a notion that any increases in deependencies, especially depending on anything that is not specified by POSIX, require on-list discussion and a PSC vote. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
Mike Taves writes: > On Tue, 18 Feb 2020 at 13:20, Greg Troxel wrote: >> "GEOS" writes: >> > **Specify bash, and use printf to escape paths (if needed)** >> > >> > This allows installation with CMake to other directories, such as `/opt/my >> > prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also >> > `printf` is a bash-only feature. >> >> It really seems like a regresssion to require bash, rather than POSIX >> shell, and it's definitely a regression if the build doesn't find bash >> and substitute in the path. >> >> Is this really necessary? > > As noted above, the printf function is built-in with Bash, and can > properly escape a path. While I see there is also /usr/bin/printf I'm > not sure how common or standard this tool is (my tests with /bin/sh > didn't go well, so I opted to switch to Bash for reliability). First, to me requiring bash is worse than telling people not to do ridiculous things like putting spaces in pathnames :-) But I realize other people think spaces in pathnames is an ok thing. The right question about tools is not what's typically on Linux but what POSIX requires. In searching for the POSIX printf spec, I found this post about escaping spaces in a portable manner. https://stackoverflow.com/questions/12162010/posix-sh-equivalent-for-bash-s-printf-q The specs at opengroup.org seem hard to deal with today - not sure if they changed - but I found this POSIX printf description: https://www.unix.com/man-page/POSIX/1posix/printf/ > Currently, other Bash scripts are present in tools/ci/ but these are > not installed with GEOS. ci tools are quite a different story than a requirement for regular installs, although I see using bash there (vs /bin/sh) as a bug also. > Besides Native Windows, what OSes (that GEOS is used on) does not have > Bash available? As far as I know, it's available on most Linux > distributions, all recent Solaris and macOS, and even some Windows. I > can't think of any other shell that is more common. The shell that is more common is the one required by POSIX: /bin/sh, having the behavior specified by POSIX. Bash either conforms to POSIX or is close enough, so code written for POSIX will work fine with bash. None of the BSDs have bash by default. When it is present, via ports, pkgsrc, etc., it's not in /bin. On NetBSD, it's in /usr/pkg/bin/bash. People use it for their login shell. I do too - I'm not a bash hater, but object to it for programming use. It's enormous, and is one particular implementation among many. I view it as personal choice to use it for interactive use, and not appropriate for scripting. The fact that /bin/bash does not exist on *BSD, and probably other places, prompted my question about looking for it and substituting the path. Expecting bash to be in /bin/bash is just not a valid assumption. So, given that there seems to be a way to do this without introducing a dependenchy on bash, I'd like to see this backed out. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] [GEOS] #1015: Update geos-config tool for consistency
"GEOS" writes: > #1015: Update geos-config tool for consistency > ---+-- > Reporter: robe | Owner: geos-devel@… > Type: defect | Status: new > Priority: minor | Milestone: 3.9.0 > Component: Build/Install (cmake) |Version: master > Severity: Unassigned | Keywords: > ---+-- > Details repeated from https://git.osgeo.org/gitea/geos/geos/pulls/99 > > > > **Specify bash, and use printf to escape paths (if needed)** > > This allows installation with CMake to other directories, such as `/opt/my > prefix`, since `geos-config --prefix` would return `/opt/my\ prefix`. Also > `printf` is a bash-only feature. It really seems like a regresssion to require bash, rather than POSIX shell, and it's definitely a regression if the build doesn't find bash and substitute in the path. Is this really necessary? ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.8.0 RC3
rc3 seems to be in good order from the pkgsrc viewpoint.
* a digression about 3.7.3
I updated pkgsrc belatedly from 3.7.1 to 3.7.3 and tests passed on
netbsd-8/amd64.
There is a C++ ABI break from 3.7.1 to 3.7.3, which was unexpected. Due
to libtool adding in dependency libs from the .la file, gdal links to
geos-3.7.3.so, even though it ought to just link to geos_c. This is
arguably a libtool bug (and perhaps only on pkgsrc, but I think bigger),
so this ABI break is notabable, even if there are really zero direct
users, and even if the 3.7.3 library has the same ABI as the 3.7.1
library. While I expect ABI breaks across major versions, I don't
expect them on micro releases and this surprised me.
* report on 3.8.0rc3
With 3.8.0rc3, on netbsd-8/amd64, it built and passed geos's own test suite.
a few very minor things, probably not worth the risk of changing other
than perhaps adjusting NEWS:
There are header files removed from the set of installed files. I
don't see these presumed API withdrawals in NEWS. (I am not saying
this is wrong, just that I don't understand.)
NEWS doesn't mention if there is an ABI break of the C++ API. In
pkgsrc, there are no known users of this now. But, libtool adds
dependency_libs to the link lines of depending packages, so even
things that don't use the C++ API end up linked against the lib
(arguably a bug, unknown extent of where this happens), and have to be
recompiled, so an API break is noteworthy.
I have a stray patch to geos-config.in, to add in @LDFLAGS@ to the
--ldflags command. I am really unclear if anyone ever sent it
upstream from pkgsrc. Also, there are --libs arguments that also
include -Llibdir, which seems wrong. Best to talk about this post
release I think -- not new or urgent.
I have a stray patch to capi/geos_ts_c.cpp, which uses const char *
instead of str in NOTICE_MESSAGE and ERROR_MESSAGE. I am unclear on
the origin of this patch, but it claims that non-POD types in variadic
functions are UB. Also seems best to defer to post release -- also
not new or urgent.
Removed header files:
include/geos/algorithm/CGAlgorithms.h
include/geos/algorithm/CentroidArea.h
include/geos/algorithm/CentroidLine.h
include/geos/algorithm/CentroidPoint.h
include/geos/algorithm/MCPointInRing.h
include/geos/algorithm/PointInRing.h
include/geos/algorithm/SIRtreePointInRing.h
include/geos/algorithm/SimplePointInRing.h
include/geos/geom/Lineal.h
include/geos/geom/Polygonal.h
include/geos/geom/Puntal.h
include/geos/noding/SingleInteriorIntersectionFinder.h
include/geos/platform.h
include/geos/timeval.h
$NetBSD: patch-ae,v 1.6 2018/09/11 16:13:29 gdt Exp $
TODO: explain what's in LDFLAGS.
TODO: explain why --libs has -L in the first place (vs --ldflags).
TODO: report upstream.
--- tools/geos-config.in.orig 2018-08-19 10:49:14.0 +
+++ tools/geos-config.in
@@ -58,7 +58,7 @@ case $1 in
echo -L${libdir} -lgeos -lm
;;
--ldflags)
- echo -L${libdir}
+ echo -L${libdir} @LDFLAGS@
;;
--includes)
echo ${prefix}/include
$NetBSD: patch-capi_geos__ts__c.cpp,v 1.2 2018/09/11 16:13:29 gdt Exp $
\todo Document this patch. It appears to be that passing non-POD types
to variadic functions is UB.
\todo File a bug upstream, if appropriate.
--- capi/geos_ts_c.cpp.orig 2015-09-08 16:31:02.0 +
+++ capi/geos_ts_c.cpp
@@ -214,7 +214,7 @@ typedef struct GEOSContextHandle_HS
}
void
-NOTICE_MESSAGE(string fmt, ...)
+NOTICE_MESSAGE(const char *fmt, ...)
{
if (NULL == noticeMessageOld && NULL == noticeMessageNew) {
return;
@@ -222,7 +222,7 @@ typedef struct GEOSContextHandle_HS
va_list args;
va_start(args, fmt);
- int result = vsnprintf(msgBuffer, sizeof(msgBuffer) - 1, fmt.c_str(),
args);
+ int result = vsnprintf(msgBuffer, sizeof(msgBuffer) - 1, fmt, args);
va_end(args);
if (result > 0) {
@@ -235,7 +235,7 @@ typedef struct GEOSContextHandle_HS
}
void
-ERROR_MESSAGE(string fmt, ...)
+ERROR_MESSAGE(const char *fmt, ...)
{
if (NULL == errorMessageOld && NULL == errorMessageNew) {
return;
@@ -243,7 +243,7 @@ typedef struct GEOSContextHandle_HS
va_list args;
va_start(args, fmt);
- int result = vsnprintf(msgBuffer, sizeof(msgBuffer) - 1, fmt.c_str(),
args);
+ int result = vsnprintf(msgBuffer, sizeof(msgBuffer) - 1, fmt, args);
va_end(args);
if (result > 0) {
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] spatialite on iOS/Android
Hans-Georg Haberl writes: > I'm a developer working on UWP, Android and iOS apps using the Xamarin > framework and Entity Framework Core. > I'm working on building spatialite for Android, which depends on the geos > library. > As far as I can tell LGPL is problematic for the Android and Apples App > Store so I was wondering if there is a way to license it in a way that > allows to create Android and IOS Applications without getting a headache > because there are no clear answers if this is allowed or not (Maybe add the > possibility that you can change the licence to i.e. MPL as long as it's put > on the Apple or Android Stores,...). I would suggest that you move from "as far as I can tell" to clear reasoning based on reading the terms and legal advice. You say "Android App Store". I use f-droid, which is an android app store, and it is full of code with LPGL and GPL :-) But seriously, if you mean "Google Play", then you should say that. There are applications on Google Play with GPL, and I have never heard claims that GPL or LGPL licenses are prohibited. As for iOS, perhaps you should ask Apple to change their terms. This is not a minor issue of license compatibility; it is a fundamental clash between their terms and Free Software principles. This question has come up before, and based on that discussion, it seems highly unlikely that there would be a license change. > I've been wondering if it's ok to just share a source of the app somewhere > but it seems all in all still very sketchy and questionable if this will > hold up in court if anyone ever complains (I'm working for a very small > company with only 3 full time developers and we've been sued several times > for no reason at all other than trying to hamper our company so they can > get our customers,... very questionable strategy since we've always played > fair) I am not following your comments, but it sounds like you are in need of legal advice, which you won't get here. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC 9: Restore C++ API as public API
lnkansa writes: > For the second time, this discussion has become very passionate at some > point. That being said, I believe all the package management issues being > used as an excuse are more of an issue for Linux-based systems. Those who > develop Linux-based applications should know better if they depend on > system wide library distribution for their dependencies via some package > management. For them, they should have stability in mind when doing their > development. Why should a larger community pay for the poor choice of > others and would have to jump through additional hoops to achieve what > should be trivial in C++? I am not a Linux expert/developer and would not > be in a position to judge. Such applications could consider static linking > as alternative or risk being dropped by the PACKAGE MANAGERS and those who > want to make their work easier. It is the responsibility of statically > linked application to fix security updates. I do acknowledge most of the > PSC/maintainers primary OS might be linux and might have their own > preferences/biases. This is not about GNU/Linux vs other packaging systems. It is about the notion that it is normal and proper to use dynamic linking and only have one copy of a library, such that it can be updated for security issues without having to update large amounts of other things. Part of the problem, perhaps most of it, is that programs written in C++ tend not have a stable ABI. With a notion of ABI stability, I think most of the objections would be less strong. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] pragma once
Paul Ramsey writes: > "non standard but widely supported" > > https://en.wikipedia.org/wiki/Pragma_once > > Includes MSVC! :) As much as I hate to depart from standards, that does look near universal. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] pragma once
Paul Ramsey writes: > As I fart around w/ header guards every time I add a new header/class, > I wonder if changing over to #pragma once would be OK with one and > all? GCC has had it 3.4, and clang has always had it, so…? Is that covered by any standards? (Presumably there is some other compiler people use on windows, too.) ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++14
"Regina Obe" writes: > I think a lot of packaging (for older systems I see) I see is still > done on gcc 4.7. Though one can argue that these older systems will > not ship newer GEOS, so might not be so much of an issue aside from > users who build their own GEOS stuck on old platforms. A good point for Linux, but in the non-Linux world (BSD, MacOS, Solaris, and the rest of the vendor unix tradition) there is usually a notion of "base system" and "packages or other stuff". So with have things like mv and the compiler in base, and then packages, the idea of wanting to build newer packages with a not bleeding edge but not ancient compiler (which describes gcc 4.8) is not really that strange. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++14
Daniel Baston writes: > Paul raised an issue yesterday about how to mark something as "deprecated" > without using the "[[deprecated]]" attribute provided in C++14. > > It made me wonder what others think about using C++14 for GEOS. I see C++14 > as mostly a "bugfix" to C++11, introducing things like std::make_unique > that were oddly omitted from C+11. Perhaps, but the real issue is deployed compiler support. > If we are going to modernize the code to use C++11, why not go straight to > C++14? Are there major platforms that support C++11 but not C++14? > > If you look at this chart, there is no release of gcc, clang, or MSVC that > supports ALL of C++11 without also supporting ALL of C++14: > https://en.cppreference.com/w/cpp/compiler_support > > In all cases, you need gcc5, clang 3.8, or MSVC 19.0. (But yes, _most_ of > C++11 is implemented in earlier releases of these.) I think moving to C++14 is premature. The real issue is that there are a lot of systems out there, with various compilers, and there's an implicit line between "too lame to cope" and "ok". Right now, enough things require C++11 that a system that can't build most C++11 is nonviable. This really means gcc 4.8 (or maybe 4.7; NetBSD went from 4.5 to 4.8 (and then to 5), so I don't know about 4.6 and 4.7). It's true that 4.8 does not fully support C++11, but it supports the parts that almost all programs use. The version that has 4.8 (7) is going to drop out of support probably over the next year. I think this is pretty typical of systems that tend to stability rather than rapid tracking, and would expect RHEL/CentOS to be the same or even more conservative in updates. If the base system compiler isn't new enough, then some gymnastics are required. This seems to be the case across a large class of systems, including the various LTS types of releases. I am starting to see more programs need C++14, but so far those are relatively few and relatively giant and tend to be leaf packages, vs things that if they don't build a very large number of packages are broken. This tends not to affect people that always update rapidly and use an OS that rapidly adopts new compilers - which tend to tbe those contributing to programs. But the user community is I think pretty different, and tends to upgrade more slowly, with larger numbers of installed systems. So I think geos and similar things should wait until one can say with a straight face "I don't understand your situation, your concerns, or your constraints, but a system without a C++14 compiler is beyond lame and therefore you don't matter". I realize that's harsh, but that's essentially what bumping compiler requirements does to people.In a year or two, enough other things will need it that people will have to cope somehow. So I guess I'm saying that geos is too foundational to be on the list of why they have to cope now. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] double double
Paul Ramsey writes: > Mats, what ever happened to: > > https://github.com/libgeos/geos/pull/40 > > I'm just coming up against some stuff in the JTS commit log that expects > double double and I see you've done this work already some years ago, but > it's not committed that I can see. JTS changed over some code to use DD > exclusively about a year ago, so this is a case where porting has caught up > to need. > > Were there any substantial problems w/ your PR? If not I'm "just" going to > try and rebase it and use it as the basis for going ahead. > > (It seems like the state-of-the-art would eventually be to use the "long > double" type, which has an implementation in GCC, but does not yet have one > in clang, in hopes that by being close to the metal we'd eventually also > start to reap performance gains as the silicon adds instructions to improve > long double calculations. ???) I don't follow this last paragraph. As I understand it, long double is a type defined by C that can be more precise than double, but doesn't have to be, and on x86 is typically 80 bits. double double is a technique to use two doubles to get roughly twice the precision. I would expect that on many CPUs, long double is the same as double. So double double is far more precise than long double always. https://en.wikipedia.org/wiki/Long_double https://en.wikipedia.org/wiki/Quadruple-precision_floating-point_format#Double-double_arithmetic ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] 3.7.1 Release
"Regina Obe" writes: > Which test was that. Might have been the one that was failing on > Clang (FreeBSD and Mac) that I shushed in 3.7.0. > > In which case it's just as well its removed. I don't think it's entirely clear that the test is wrong, vs the code, vs clang. But maybe it's clear to others and just not to me (which is ok). But, I am pretty sure this is not a regression in 3.7.1, but an old issue that is now better understood than it was. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7 - Use CMake as build system for GEOS
Paul Ramsey writes: > Or maybe I should attempt to summarize what I recall from the thread that > seem to me to be reasonable functional requests before going cmake-only: > > - make dist generates a distributable tarball > - make check > - make check runs all tests > - make check builds test binaries that can be debugged w/o an install > > More? I think there are three more things that autotools does right that need to be replicated before it's ok to drop autotools. 1) "make distcheck", which does make dist unpacks the distfile does an objdir build from the unpacked distfile runs make check (which uses the just-built libs) which shoud be easy if make disk and make check work ok. 2) cross building, where you can specify a cross toolchain and a path to where the cross includes are. This is something that has worked with very little effort with autotools. I don't know if it works with geos this minute, but I know in general it works if there aren't any cross-breaking bugs (like AC_TRY_RUN, or random code with issues in makefiles). 3) ensuring that the cmakefiles have almost no "if on this OS, do this" logic. autoconf introduced the idea of feature tests which has been greate for portability and I have in general seen things within cmake that are a step backwards. I don't know where the geos cmake build is (it fails on NetBSD, not sure why), so this may be a non-issue. But culturally this sort of ifdef SO seems acceptable in cmake where it isn't in autoconf, and I don't know why. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++ version, documentation and --std flags
Greg Troxel writes: > On the question of how linking with geos_c is supposed to work,things > look good -- the C++ library has a NEEDED elf note for libstdc++, and > the c library calls for the c++ library. Why geos_c calls for libstdc++ > directly I don't understand, but I don't see that it would cause > problems -- the idea that one owuld upgrade libstdc++ and rebuild > libgeos but not libgeos_c does not seem credible. I was confused - the geos_c library of course is implemented in C++ and thus needs libstdc++. It's only users of geos_c that don't need libstdc++. So everything I have looked at in geos seems exactly right. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++ version, documentation and --std flags
Greg Troxel writes: > The problem seems to be that libgeos.la does not specify -lstdc++ as a > dependency_lib, and the capi test is linked with cc, not c++, so that > standard C++ library isn't linked. > > Changing to using c++ instead of cc on that test makes it link, but I'm > not clear on what's right. > > A basic question is if we expect linking with the geos C library to be > doable in an invocation of the C compiler (as linker) that does not > include -lstdc++. I would think so, but I need to look further into how > this is supposed to work. Investigating further, I now believe that libtool as distributed has bugs on NetBSD, and that the pkgsrc libtool has among its changes at least a fix. Which is perhaps hard to resolve, but not a geos issue. On the question of how linking with geos_c is supposed to work,things look good -- the C++ library has a NEEDED elf note for libstdc++, and the c library calls for the c++ library. Why geos_c calls for libstdc++ directly I don't understand, but I don't see that it would cause problems -- the idea that one owuld upgrade libstdc++ and rebuild libgeos but not libgeos_c does not seem credible. $ geos-master/obj > objdump -x src/.libs/libgeos.so |egrep NEED NEEDED libstdc++.so.7 NEEDED libm.so.0 NEEDED libgcc_s.so.1 NEEDED libc.so.12 $ objdump -x capi/.libs/libgeos_c.so|egrep NEEDED NEEDED libgeos-3.7.0.so NEEDED libstdc++.so.7 NEEDED libm.so.0 NEEDED libgcc_s.so.1 NEEDED libc.so.12 ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++ version, documentation and --std flags
Here's a patch to README.md on git master. It explains the C++11
requirement, gives clearer examples for using obj/build dirs, and limits
the direction to run ldconfig to Linux.
>From abedec6b2344e2384b5c74ed6307b88231cf7fec Mon Sep 17 00:00:00 2001
From: Greg Troxel
Date: Sat, 6 Oct 2018 19:29:57 -0400
Subject: [PATCH] README.md: Clarify installation instructions
---
README.md | 19 ---
1 file changed, 12 insertions(+), 7 deletions(-)
diff --git a/README.md b/README.md
index f0032f42..a43f3314 100644
--- a/README.md
+++ b/README.md
@@ -17,22 +17,27 @@ More on: https://trac.osgeo.org/geos#BuildandInstall
### Unix
-Using Autotools:
+ Prerequisites
+
+geos requires a C++11 compiler
+
+ Using Autotools:
./autogen.sh # in ${srcdir}, if obtained from SVN or GIT
-${srcdir}/configure # in build dir
+(mkdir obj && cd obj && ../configure)
-Using CMake:
+ Using CMake:
-cmake ${srcdir} # in build dir
+(mkdir build && cd build && cmake ..)
-Now, all versions:
+ Either Autotools or CMake
make
make check
-make install # as root
-ldconfig # as root
+make install # (as root, assuming PREFIX is not writable by the build user)
+On a GNU/Linux system, if installed in a system prefix:
+ ldconfig # as root
### Microsoft Windows
--
2.19.0
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++ version, documentation and --std flags
Sandro Santilli writes: > On Thu, Oct 04, 2018 at 09:28:57AM -0400, Greg Troxel wrote: >> I'm seeing test failures in trunk, built with autotools in an objdir >> with gcc 4.8 on NetBSD 7 amd64. They are obviously C++ build issues, >> but only happen when building tests. I am not trying to ask others to >> debug these in this mail. >> >> I looked in README.md to find out what version of C++ is needed, and >> don't see any --std= flags inserted in the build. Various compiler >> versions seem to have varying default standards, and it seems best to >> declare the version being used so that builds will hard fail obviously >> if that isn't ok. >> >> In my case, I think gcc 4.8 almost entirely supports C++11, but defaults >> to C++03 without --std=c++11. > > Could it be one of those autoconf-version related issues ? Perhaps, but I have autoconf (GNU Autoconf) 2.69 automake (GNU automake) 1.15.1 which I expect is pretty up to date. The first question is what language standard is needed, and to get this in README.md, which should document prerequisites. Is it correct that it's C++11 as the language (on trunk)? > Supposedly -std=c++11 should be added by the call to > > AX_CXX_COMPILE_STDCXX > > which is found in configure.ac and defined in > macros/ax_cxx_compile_stdcxx.m4 I do not see that in configure.ac on trunk. But I realize now that's because I'm still using the svn repo, and despite the trac showing that under 'browse source', that's no longer what's official. So I suggest that if the svn isn't up to date, and the code from svn is really migrated to git, that the svn repo be made no longer accessible.e ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] C++ version, documentation and --std flags
"Regina Obe" writes: > What error are you getting? When I try to build using autotools, it also > fails too building the tests > > https://trac.osgeo.org/geos/ticket/913 > > I assume your issue is different as on mine looks like it's just > looking for a non-existent file on my system And also mixing C and C++ > constructions (like namespace) My error is different. The problem seems to be that libgeos.la does not specify -lstdc++ as a dependency_lib, and the capi test is linked with cc, not c++, so that standard C++ library isn't linked. Changing to using c++ instead of cc on that test makes it link, but I'm not clear on what's right. A basic question is if we expect linking with the geos C library to be doable in an invocation of the C compiler (as linker) that does not include -lstdc++. I would think so, but I need to look further into how this is supposed to work. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
[geos-devel] C++ version, documentation and --std flags
I'm seeing test failures in trunk, built with autotools in an objdir with gcc 4.8 on NetBSD 7 amd64. They are obviously C++ build issues, but only happen when building tests. I am not trying to ask others to debug these in this mail. I looked in README.md to find out what version of C++ is needed, and don't see any --std= flags inserted in the build. Various compiler versions seem to have varying default standards, and it seems best to declare the version being used so that builds will hard fail obviously if that isn't ok. In my case, I think gcc 4.8 almost entirely supports C++11, but defaults to C++03 without --std=c++11. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7 - Use CMake as build system for GEOS
Daniel Baston writes:
>> I'm asking if we can have a "make check" rule, generated by CMake,
>> that will run the same tests run by current "make check" rule
>> generated by autotools and with the same important condition of
>> built binaries and libraries _NOT_ moving out of the build tree.
>>
>> Also I'd like to have a "make dist" and "make distcheck" and
>> of course the other custom ones ("apidoc"/"doxygen"/"pdf",
>> "gen-ChangeLog" etc.)
>
> Can you clarify how this request relates to your proposal to drop CMake
> entirely? If this question can be answered to your satisfaction, do you still
> wish to drop CMake? (I'm hesitant to spent time investigating if you're not
> interested in the answer.)
I'm pretty sure he means:
if there is serious talk of removing autotools, then the cmake build
has to support make check/dist/distcheck, so that moving to cmake
isn't a regression
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7 - Use CMake as build system for GEOS
Sandro Santilli writes:
> On Wed, Oct 03, 2018 at 02:41:34PM -0400, Daniel Baston wrote:
>>
>> Are you asking whether the GEOS test suite can be run against
>> a non-installed copy of the library (yes), or are you referring to
>> other tests?
>
> I'm asking if we can have a "make check" rule, generated by CMake,
> that will run the same tests run by current "make check" rule
> generated by autotools and with the same important condition of
> built binaries and libraries _NOT_ moving out of the build tree.
>
> Also I'd like to have a "make dist" and "make distcheck" and
> of course the other custom ones ("apidoc"/"doxygen"/"pdf",
> "gen-ChangeLog" etc.)
Agreed that these things are necessary.
This is a key part of why there is pushback from people that don't want
to drop autotools in favor of cmake (strk, bas, and me, at least).
cmake's reason for existence is basically supporting native windows
builds, but it is a step backwards on posix platforms, lacking "make
check" (testing not installed files), "make dist", and "make distcheck"
(testing not only not installed files, but an objdir build of the
just-produced distfile). Perhaps I'm confused and all of those things
are automatically supported somehow.
And it's not clear to me that cmake supports cross builds by default.
Looking at the goes CMakeList, there are options added for gcc, and for
MS, but some of the gcc options belong for clang too (because they
aren't really gcc options). In configure.ac, flags are added if
supported, without checking for exact compiler type (and thus working
with clang).
Another place to look for simplification is to stop testing for things
that are required by POSIX, unless it's needed to accomodate windows.
An example is stdint.h and the notion of 64-bit integer types. It's
true that posix doesn't strictly require int64_t and uint64_t, but it
does say that if 64-bit types exist they have to be usable by those
names:
http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/stdint.h.html
Another source of complexity in the cmake build seems to be some mac
framework build that's doing things in a special mac-y way instead of
just using mac as posix. That is not present in the autoconf build.
I tried the cmake build on NetBSD, and it failed early with isnan
issues. (The autotools build works fine, which is no surprise since
it's been the standard approach and is well debugged.) So I wonder how
well the cmake build has been tested on other than windows, and it
seems premature to propose removing autotools.
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7 - Use CMake as build system for GEOS
Sebastiaan Couwenberg writes: > On 10/4/18 4:39 AM, Regina Obe wrote: >>> pkgsrc is using autoconf. I have had far more problems with cmake over >>> time than with autoconf. >>> >> >> But you do use CMake for some things right? >> >> I presume Debian and CentOS packagers already use CMake because they ship >> pgRouting and pgRouting only supports CMake. >> Does CGAL support autotools? I've never tried since I always went for the >> CMake. > > Debian packaging tools also support CMake. pkgsrc does too. Basically it is well more than prevalent enough that packaging systems esentially have to. > For the geos package autotools is used because that's the official > buildsystem and on Linux superior to CMake. E.g. libtool does the right > thing with library versioning. I have never tried geos cmake, but my broad experience over the years is that autotools-based systems almost entirely work correctly and cmake-based systems are more troubled. > I would prefer if geos kept autotools as the default buildsystem for > Linux, using CMake for Windows and other systems is fine with me. Seconded, except I would say default on "systems conforming to POSIX" rather than just Linux. >> When I was packaging 3.7.0 I spent 20% of my time cursing because >> there was this autotools configure thing, CMake make lists, and I >> think even NMake or some such thing >> That all needed changing just to get a stupid version number in place. Do you mean changing one number in one line in configure.ac, and one line in some cmake file? >> The problem with that thinking is that it HAS HAD low rate of building >> system changes >> This I'm pretty sure will change in 3.8. Both Dan and Vicky have huge plans >> for improving GEOS >> Which means we are going to have to add a ton more tests to the GEOS suite >> to ensure we don't break things. >> >> This will become very time consuming if we have to test against autotools >> and CMake. It seems that the downside of two is adding each test file in two places, and this seems tiny compared to writing and testing a test file. >> I'm not sure if it's true for other people, or if it's just because I'm >> working on a Handicapped platform >> But for me even when autotools WAS working GEOS compiled way faster under >> CMake than it did under autotools. Try compiling cmake too. On some systems I test on it takes hours to build cmake. >> If that is true for others, those cycles make a big difference for >> development. If you have just changed source files and rebuild, you just run make. If you are doing a full regression test, then it does more. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7 - Use CMake as build system for GEOS
pkgsrc is using autoconf. I have had far more problems with cmake over time than with autoconf. This is obviously an issue where people disagree. However, two observations where there is probably common ground: I don't understand windows native builds (because I don't use windows), but I don't understand why there is nmake and cmake both. If cmake exists to make windows builds work, then I would think nmake can go. And if nmake is how windows native builds are done, I don't really see the point of cmake. I am guessing this question would be resolved by dropping nmake. Given two systems (auto* and cmake), and the fact that geos seems to have had low rate of build system changes, I wonder if there is really a problem with both. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] RFC7 - Use CMake as build system for GEOS
Sandro Santilli writes: > On Mon, Oct 01, 2018 at 12:38:50PM -0400, Daniel Baston wrote: >> Hi All, >> >> I've posted an RFC to switch to CMake as the exclusive build system for >> GEOS. Some reasoning is in the RFC itself, but it boils down to wasted >> developer and machine effort supporting the combination of autotools, >> CMake, and NMake. >> >> https://trac.osgeo.org/geos/wiki/RFC7 >> >> Thoughts from the PSC? > > One of the reasons why I still prefer autotools is its ability > to build tester scripts which work before install (via libtool). > Does cmake allow for that ? Testing before install, while the previous version (including libraries) is installed, is to me a requirement for a build system. Also cross building. People keep telling me that cmake does everything auto* does, but I wonder. Perhaps we can drop camke and just have autotools, and native windows (vs mingw/cygwin) users can fund keeping the separate windows makefiles up to date (yes, that's mostly a joke). ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
My arm issues are likely not a GEOS bug, and definitely not new. Don't hold up on my account.___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
I have done more testing on the NetBSD/earmv7 issue. Someone else reproduced it, and also with newer gcc on NetbSD-current, compared to gcc 5.5.0 on my system. NetBSD/sparc64, also newer gcc, passed. I rebuilt with -O0 instead of -O2, and then the xmlrunner tests pass. I get a failure to create a geometry object in the unit suite on one of the inputs, and will post something more coherent about that later. (The suite is not robust about checking for null returns from GEOSGeomFromHEX_buf, it seems.) Just FYI to the list - obviously I still have things to figure out. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
Sebastiaan Couwenberg writes: > On 9/5/18 2:29 AM, Greg Troxel wrote: >> Has anyone run the geos tests on arm under Linux? > > Yes. > > [urls] Thanks, that's helpful. I ran Kahan's paranoia on my system, which passed cleanly. I will keep looking into this. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
I tried 3.6.2, and got the following test result. Has anyone run the geos tests on arm under Linux? (I think this issue should definitely not hold up the release.) == : tests/xmltester/test-suite.log == # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: testrunner terminate called after throwing an instance of 'geos::util::IllegalArgumentException' what(): IllegalArgumentException: Exponent out of bounds [1] Abort trap (core dumped) ./XMLTester -v -... ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
Greg Troxel writes: > Not related to the maybe-clang/GeometryFactory test failure, I tried to > build on NetBSD/8 evbearmv7hf-el (RPI3, running 32 bit), and got > > == > : tests/xmltester/test-suite.log > == > > # TOTAL: 1 > # PASS: 0 > # SKIP: 0 > # XFAIL: 0 > # FAIL: 1 > # XPASS: 0 > # ERROR: 0 > > .. contents:: :depth: 2 > > FAIL: testrunner > > > terminate called after throwing an instance of > 'geos::util::TopologyException' > what(): TopologyException: found non-noded intersection between > LINESTRING (-105571 939969, -102895 939993) and LINESTRING (9485.36 770763, > -102895 939993) at -102894.5562421389 939992.66927296668 > [1] Abort trap (core dumped) ./XMLTester -v -... > FAIL testrunner (exit status: 134) > > I believe this has normal IEEE754 floating point. > > So I'm curious if anyone has run this on arm, and specifically armv7. I'm still seeing this with rc2, still only on armv7. ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
Not related to the maybe-clang/GeometryFactory test failure, I tried to build on NetBSD/8 evbearmv7hf-el (RPI3, running 32 bit), and got == : tests/xmltester/test-suite.log == # TOTAL: 1 # PASS: 0 # SKIP: 0 # XFAIL: 0 # FAIL: 1 # XPASS: 0 # ERROR: 0 .. contents:: :depth: 2 FAIL: testrunner terminate called after throwing an instance of 'geos::util::TopologyException' what(): TopologyException: found non-noded intersection between LINESTRING (-105571 939969, -102895 939993) and LINESTRING (9485.36 770763, -102895 939993) at -102894.5562421389 939992.66927296668 [1] Abort trap (core dumped) ./XMLTester -v -... FAIL testrunner (exit status: 134) I believe this has normal IEEE754 floating point. So I'm curious if anyone has run this on arm, and specifically armv7. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
"Regina Obe" writes:
> https://download.osgeo.org/geos/geos-3.7.0rc1.tar.bz2
Regarding
https://trac.osgeo.org/geos/ticket/894
I don't see this on NetBSD/7 amd64, which uses gcc 4.8.
I did a build on macos 10.11, which uses clang (but a similar Intel
processor):
Apple LLVM version 8.0.0 (clang-800.0.42.1)
Target: x86_64-apple-darwin15.6.0
Thread model: posix
InstalledDir: /Library/Developer/CommandLineTools/usr/bin
and get the same failure as the bug.
Specifically, if I run test 1 in that group, it fails:
$ ./geos_unit geos::geom::CoordinateArraySequenceFactory 1
===
GEOS Test Suite Application
===
geos::geom::CoordinateArraySequenceFactory: [1=F]
---> group: geos::geom::CoordinateArraySequenceFactory, test: test<1>
problem: assertion failed
tests summary: failures:1 ok:0
but tests 2,3,4,5 all pass.
The test is in tests/unit/capi/GEOSGeomFromWKBTest.cpp in the sources,
and is doing:
// POINT(1.234 5.678)
std::string wkt("POINT (1.234 5.678)");
std::string wkb("0101005839B4C876BEF33F83C0CAA145B61640");
test_wkb(wkb, wkt);
I don't know how to get it to produce the mismatching content; the
--verbose option in --help is unrecognized, and I can't see how it would
be reading the driver source.
So I wonder if something in geos is sensitive to gcc/clang differences.
(Vastly less likely, there could be a clang bug.)
signature.asc
Description: PGP signature
___
geos-devel mailing list
geos-devel@lists.osgeo.org
https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
Jeff McKenna writes: > That was it, manually copying the missing file from svn or git, into > the release package (geos-3.7.0rc1.tar.bz2) allows GEOS to compile > with msvc 2017. It seems better to adjust the cmake stuff not to expect such a file than to put it in the release. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] NEWS comments
Sebastiaan Couwenberg writes: > I don't think it's the job of a packaging system to specify which > compiler features should be used for reverse dependencies. Stuff like > pkg-config was invented for that. The point is to document that a compiler capable of c++11 is required, so that if the current compiler isn't new enough, one can be built and used instead. But I'm not trying to push one packaging system's view on the world, just to ask that things be clear. > ldd has misleading output, objdump is more reliable: > > $ ldd /usr/lib/libgdal.so.20.1.2 | grep geos > libgeos_c.so.1 => /usr/lib/x86_64-linux-gnu/libgeos_c.so.1 > (0x7fa48c768000) > libgeos-3.5.1.so => /usr/lib/x86_64-linux-gnu/libgeos-3.5.1.so > (0x7fa47f809000) > > $ objdump -x /usr/lib/libgdal.so.20.1.2 | grep NEEDED | grep geos > NEEDED libgeos_c.so.1 > > GDAL should not be using the GEOS C++ API, see m4/geos.m4 in the GDAL > source how it detects the library to link. Thanks. objdump -x shows libgeos as NEEDED, but configure found the C API, and so far I haven't figured out where it's coming from - will keep looking. > In your case it seems that you need to tell pkgsrc that building geos > with non-C++11 compilers is not possible. Yes, it will be marked "USE_LANGUAGES+= c++11", which is normal for us. > I do wonder why those users > can get a compiler with C++11 support from pkgsrc though. It's just a > dependency issue, if you want to build the new geos, you need to update > your compiler to suitable version first. Yes, but we have a notion of base system compiler and extra compiler from pkgsrc, and thus the question is when the force the new one. > Personally I also think that the file list requirements from pkgsrc are > an unnecessary burden to packagers, causing them to request detailed > changelog entries mentioning those file changes from upstreams. Debian > packages automatically generate the list of files they include, and if > you want to see the changes there are tools like debdiff. There are pluses and minuses. I only ask when I see API withdrawals not mentioned. Often it's an omission of documentation, but sometimes things are broken. Whether I change a file or just see a diff, it's the same question. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
Sebastiaan Couwenberg writes: >> Sorry, I am not following. I dug into this harder than probably makes >> sense because I wanted to make sure there wasn't a bug in NetBSD's sed, >> in which case I would file a bug report so it is fixed. >> >> I don't see -E in POSIX's sed spec: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html > > It's documented in the sed manpage: > > " > POSIX.2 BREs should be supported, but they aren't completely because of > performance problems. The \n sequence in a regular expression matches > the newline character, and similarly for \a, \t, and other sequences. > The -E option switches to using extended regular expressions instead; > the -E option has been supported for years by GNU sed, and is now > included in POSIX. > " > > https://manpages.debian.org/stretch/sed/sed.1.en.html#REGULAR_EXPRESSIONS The Debian manpages are not authoritative for POSIX :-) It's not an issue to use -E, but I can't find in POSIX itself where it says this. But that's not an actual issue and I don't want to take up more or your time on it. >> But, in the posix spec for extended regular expressions: >> >> http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html >> >> I don't see that .*? is legal, opposed to (.*)? > > That's probably because we're thinking in Perl compatible regular > expressions, the dominant regex implementation thanks to PCRE, but POSIX > extended regular expressions don't support that feature. I am not following you. The expression in geos 3.7.0rc1 is not legal according to POSIX extended regular expression. That's all I was trying to ask, was to make it conform to posix ERE. > More specifically thinks like: > > 3.7.0alpha > 3.7.0beta1dev > > And (unlikely) cases like: > > 3.42.123beta1dev > > Once again see the discussion in the related issue: > > https://trac.osgeo.org/geos/ticket/887 > > One way or another the suffix needs to be stripped from the version > number, because it shouldn't become part of the library filename. > > Initially the suffix was matched, but later changed to match the version > to handle the dev case in particular, and any other possible suffix we > hadn't thought of. That's all totally fine, as long as .* is in parens as the ERE rules seem to require. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
Re: [geos-devel] GEOS 3.7.0rc1 release
Sebastiaan Couwenberg writes: > On 8/21/18 1:25 AM, Greg Troxel wrote: >> >> is malformed. It's the .* production that the ? applies to (present or >> not). >> >> VERSION_RELEASE=`echo "$VERSION" | sed -E >> 's/^([0-9]+\.[0-9]+\.[0-9]+)(.*)?$/\1/'` >> >> GNU sed may be allowing this as an extension, because "*?" doesn't make >> sense, since * is repetition. > > Note the -E option for extended regular expressions which came from GNU > sed but is now included in POSIX. > > The ? should make the .* expression non-greedy. Sorry, I am not following. I dug into this harder than probably makes sense because I wanted to make sure there wasn't a bug in NetBSD's sed, in which case I would file a bug report so it is fixed. I don't see -E in POSIX's sed spec: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/sed.html However, NetBSD's sed (and I suspect basically all others) does document -E for extended regular expressions. But, in the posix spec for extended regular expressions: http://pubs.opengroup.org/onlinepubs/9699919799/basedefs/V1_chap09.html I don't see that .*? is legal, opposed to (.*)? Specifically, in 9.4.6.4, it says The behavior of multiple adjacent duplication symbols ( '+', '*', '?', and intervals) produces undefined results. and it looks like this ? modifier is a perl regex thing: https://stackoverflow.com/questions/1103149/non-greedy-reluctant-regex-matching-in-sed But I don't understand why this is hard in this particular, case, since we're trying to take things like 1.2.3 3.4.5rc3 and produce 1.2.3 3.4.5 and I would think the point is to have the .* eat up everything after the third number. signature.asc Description: PGP signature ___ geos-devel mailing list geos-devel@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/geos-devel
