One of our build variants is a fully-static (or as-static-as-possible) done
on CentOS 7 for old-Linux compatibility.
In reverse-dependency order we have static builds of
SQLite 3450100
Expat 2.5.0
KML 1.2.0
HDF5 1.12.1
NetCDF 4.8.1
TIFF 4.5.1
Proj 9.3.0
GeoTIFF 1.7.1
LittleCMS 2.15
WebP 1.3.2
Zst
ild
that doesn't fail.
Like I said, the frustrating part is that a simple test program (attached)
compiled against the same set of static libs works fine.
S
On Tue, Feb 20, 2024 at 12:33 PM Robert Coup
wrote:
> Hi Simon,
>
> On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <
&
e set of static libs works fine.
>
> S
>
> On Tue, Feb 20, 2024 at 12:33 PM Robert Coup
> wrote:
>
>> Hi Simon,
>>
>> On Tue, 20 Feb 2024 at 18:58, Simon Eves via gdal-dev <
>> gdal-dev@lists.osgeo.org> wrote:
>>
>>> We still have one VERY st
at 0x61900062cf70 thread T0
>>
>> ...but it's still not obvious what exactly is going wrong. The code and
>> data flow makes perfect sense when you step through it in a dynamic build
>> that doesn't fail.
>>
>> Like I said, the frustrating part is tha
Thank you, Robert, for the RR tip. I shall try it.
I have new findings to report, however.
First of all, I confirmed that a build against GDAL 3.4.1 (the version we
were on before) still works. I also confirmed that builds against 3.7.3 and
3.8.4 still failed even with no additional library depen
I was able to create a fork of 3.7.3 with just the *flatbuffers* replaced
with the pre-3.6.x version (2.0.0).
This seemed to only require changes to the version asserts and adding an
*align* parameter to *Table::VerifyField()* to match the newer API.
https://github.com/heavyai/gdal/tree/simon.eve
I'm also testing a build that uses the latest *flatbuffers* 23.5.26, which
is a drop-in replacement and does not require the *VerifyField* change,
just in case the issue has been fixed since 2.0.6.
___
gdal-dev mailing list
gdal-dev@lists.osgeo.org
https:
t; cause might be obvious if a single culptrit commit can be exhibited
> (perhaps some subtle C++ undefined behaviour triggered? also it is a bit
> mysterious that it hits only for static builds), or otherwise raise to the
> upstream flatbuffers project to ask for their expertise
>
>
lso it is a bit
>> mysterious that it hits only for static builds), or otherwise raise to the
>> upstream flatbuffers project to ask for their expertise
>>
>> Even
>> Le 23/02/2024 à 23:54, Simon Eves via gdal-dev a écrit :
>>
>> I was able to create a fork of 3.7
t;> (admitedly rather tedious) option would be to do a git bisect on the
>>> flatbuffers code to identify the culprit commit. With some luck, the root
>>> cause might be obvious if a single culptrit commit can be exhibited
>>> (perhaps some subtle C++ undefine
solve the issue ? If that worked, that would be the best way forward...
>>>>
>>>> Otherwise if the issue persists with the latest flatbuffers release, a
>>>> (admitedly rather tedious) option would be to do a git bisect on the
>>>> flatbuffers code to identi
t; Agreed on the rest.
>>>>
>>>> On Fri, Feb 23, 2024 at 3:42 PM Even Rouault <
>>>> even.roua...@spatialys.com> wrote:
>>>>
>>>>> Simon,
>>>>>
>>>>> did you try to update to the latest
>>>>
As we're not ready to upgrade Arrow just yet, I also did the namespace
change as a pre-build code patch on the regular 3.7.3 bundle.
Apologies to Bjorn and anyone else on that team for any inference that this
was a flatbuffers bug. Not my intention. Glad we worked it out.
Simon
On Sun, Feb 25, 2
So we are trying to optimize our raster import process, and particularly
the steps to derive the final WGS84/4326 bounding box for a raster file or
tile thereof.
Obviously in the general case, the transform is from integer pixel
coordinate through the Affine Transformation matrix and then whatever
Javier Jimenez Shaw
wrote:
> Maybe I don't understand your question, but in gdalinfo you have the four
> corners as lat-lon
>
> On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, <
> gdal-dev@lists.osgeo.org> wrote:
>
>> So we are trying to optimize our raste
wrote:
> The bbox is created using the xmin,ymin,xmax,ymax found in the geometry.
> Assuming every pixel can be represented as a geometry, that's your bbox.
>
> On 5/3/24 13:18, Simon Eves via gdal-dev wrote:
> > Yes, but that's just the corners.
> >
> >
ers.
>>
>> On Fri, May 3, 2024 at 1:09 PM Javier Jimenez Shaw
>> wrote:
>>
>>> Maybe I don't understand your question, but in gdalinfo you have the
>>> four corners as lat-lon
>>>
>>> On Fri, 3 May 2024, 21:46 Simon Eves via gdal-dev, <
ResampleAlgdPK15GDALWarpOptions)
> to EPSG:4326 and just take the extent of the warped VRT.
> Le 03/05/2024 à 23:25, Simon Eves via gdal-dev a écrit :
>
> I like it.
>
> On Fri, May 3, 2024 at 2:24 PM Javier Jimenez Shaw
> wrote:
>
>> Now I think I understand what you m
Dear List,
We are in the process of creating an ARM build of our system, and we have
discovered some differences in GDAL behavior between the two.
One is the declared block size of a simple RGB PNG image, which we use for
some raster import tests. The image is 320x225 and gdalinfo on x86 reports
Thank you, Even.
Does that whole-image optimization only apply to PNG? I mean, obviously
that particular build option is PNG-specific, but are there other formats
which might exhibit similar differences in presented block size? If it's
just PNG, I'm not worried, as there aren't many geospatial PNG
Understood. Thank you.
On Fri, Aug 30, 2024 at 2:54 PM Even Rouault
wrote:
> I can't think of other formats with similar behavior right now, but you
> shouldn't trust my memory. That said, reported block sizes might very well
> change with versions. Like in JPEG2000 drivers where heuristics to
>
21 matches
Mail list logo
