[geos-devel] NEWS comments

[Sebastiaan Couwenberg]

On 8/21/18 3:38 PM, Greg Troxel wrote:
> 
> Sebastiaan Couwenberg <sebastic at xs4all.nl> writes:
> 
>> On 8/21/18 3:04 PM, Regina Obe wrote:
>>> gdt said
> 
>>>>   The C++11 description is not entirely clear to me, and I think it
>>>>   should be extra loud up front.  It's a big deal as many systems have
>>>>   default compilers that are too old for C++11 (but this is a widespread
>>>>   issue with the combination of C++ and gcc).
>>> [Regina Obe] 
>>> Agreed will bring to the top of the news
>>
>> C++11 is being adopted by other major components in the geospatial
>> ecosystem, GDAL most notably. This just means that people stuck with
>> compilers that don't support C++11 cannot build those new releases of
>> the projects in question. That's not much different than requiring
>> features of recent Qt5 releases for example, if you systems cannot
>> provide that, you're stuck with older releases.
> 
> True, and note that I did not complain that C++11 was being required,
> just that the explanation of what that meant was not clear enough.
> 
> Specifically, i wondered whether I needed to put a "force c++11" line in
> the pkgsrc control file that's used when other packages link against
> geos.

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.

>>>>   Presumably there is no requirement to use C++11 anything to link
>>>>   against geos_c.   Perhaps that should be stated, even though it would
>>>>   be bizarre otherwise, given the amount of trouble that the C++/gcc
>>>>   siutation has caused.
>>> [Regina Obe] 
>>> I would think not.  Can someone else confirm this question?
>>
>> Projects shouldn't use the GEOS C++ API, if they do, they get to deal
>> with the consequences (I'm looking at you OSSIM).
> 
> I have a note that gdal uses the GEOS C++ API as well, and my gdal 2.2.4
> installation broke after updating geos (and not rebuilding gdal yet):
> 
> $ldd /usr/pkg/lib/libgdal.so|grep geos
>         -lgeos_c.1 => /usr/pkg/lib/libgeos_c.so.1
>         -lgeos-3.7.0 => /usr/pkg/lib/libgeos-3.7.0.so
>         -lgeos-3.6.2 => not found
> 
> (which I think is depending on the c lib, and then the c++)

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
(0x00007fa48c768000)
        libgeos-3.5.1.so => /usr/lib/x86_64-linux-gnu/libgeos-3.5.1.so
(0x00007fa47f809000)

$ 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.

>> All projects, except ossim, in Debian that build on GEOS use the stable
>> C API which is not affected by the C++11 compiler requirements.
> 
> That is as I epxected, but I just find this situation often more tricky
> than expected.
> 
>> From what I've seen of C++11, you probably want to adopt it for your C++
>> project anyhow, so if GEOS requiring it pushes that issue to the
>> forefront that's a good thing.
> 
> That's a separate issue.  I'm coming at this from the point of view of
> packaging many things each of which has their own requirements,
> sometimes conflicting.  While I get your point about C++ needing to move
> to C++11, pkgsrc is also enabling people to build the non-C++11 subset
> of the world on systems with older compilers.  So I'm just trying to
> encode what's required, and I really did not mean to complain about how
> things are, just to ask that it be really clear in NEWS.

In your case it seems that you need to tell pkgsrc that building geos
with non-C++11 compilers is not possible. 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.

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.

Kind Regards,

Bas


-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: OpenPGP digital signature
URL: <http://lists.osgeo.org/pipermail/geos-devel/attachments/20180821/90017edf/attachment.sig>