[gdal-dev] GDAL conda build

Fri Nov 13 00:29:29 PST 2020

Hi Paul,

You are right - we need FileGDB write support, so openfilegdb is not suitable for us. I can't believe it is this difficult to be able to write FileGDB on Windows (our linux wheels work perfectly), there must be a better way.

I have tried to modify the conda-forge recipe to include FileGDB and have almost got it working, so I think I'll persist with that for now.
(I also tried https://github.com/osgeo-forge/libgdal-filegdb-feedstock, which looked promising, but kept getting build errors).

If I'm missing something and anyone has better ideas, please let me know.

Thanks,

Jon

From: Paul Harwood <runette at gmail.com>
Sent: 11 November 2020 13:36
To: Jon Morris <Jon.Morris at jbarisk.com>
Cc: gdal-dev at lists.osgeo.org
Subject: Re: [gdal-dev] GDAL conda build

The documents are horrendously out of date - I know :)

I am assuming that you have seen this and that it does not meet your reqs
https://gdal.org/drivers/vector/openfilegdb.html#vector-openfilegdb

Building with an additional driver could, I guess, easily make a difference.

I am wondering if you have tried a vanilla build first - to see if it is all working

Personally - I would do this :

- Clone the gdal-feedstock repo onto my local machine
- cd gdal-feedstock                           // cd into the gdal-feedstock dir
- conda create --name gdal              // the actual name does not matter - as long as it does not exist yet
- conda activate gdal
- conda build recipe

That *should* I think work since that is more or less what conda-forge does in the azure pipeline - but I am no special expert on that recipe.

If that works - then you are probably going to have to change the meta.yml to include fileGDB and probably change set_bld_opts.bat to change the build options. And then run 'conda build recipe` again.

On Wed, 11 Nov 2020 at 13:00, Jon Morris <Jon.Morris at jbarisk.com<mailto:Jon.Morris at jbarisk.com>> wrote:
Hi Paul,

Thanks for your reply. The only reason we're trying to build locally is to add FileGDB support - if there is a better way to add FileGDB write support to conda-forge GDAL, I'd love to hear it! The GDAL docs are very out of date when it comes to building on Windows - the "GDAL Windows Building example for Plugins" links to https://trac.osgeo.org/gdal/wiki/BuildingOnWindows.

The only reason I'm building 3.1.4 is because when I started, 3.2.0 wasn't out yet...

Thanks,

Jon

From: Paul Harwood <runette at gmail.com<mailto:runette at gmail.com>>
Sent: 11 November 2020 09:18
To: Jon Morris <Jon.Morris at jbarisk.com<mailto:Jon.Morris at jbarisk.com>>
Cc: gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
Subject: Re: [gdal-dev] GDAL conda build

I think we can be fairly certain that gdal-feedstock works, since it has passed in a clean container environment.

The most obvious question is - I am assuming that you are using conda build - are you working in a clean conda env?

Create a totally new conda env, activate that and then try again.

I have very occasional noticed conda getting confused about versions in its package cache. You can also try `conda clean --all` to clear out the package cache.

I am also curious. Sometimes I see messages go by and I think "why". I assume that you know your business much better than me but I do wonder what you are going to get from building the conda recipe locally that is not already built into the conda package? What have I missed?

I am also curious - given you are going through the effort of creating the build - why 3.1.4 and not 3.2.0? Surely, you risk just building in a legacy problem?

On Tue, 10 Nov 2020 at 08:12, Jon Morris <Jon.Morris at jbarisk.com<mailto:Jon.Morris at jbarisk.com>> wrote:
I've been trying to build a Windows conda package for GDAL 3.1.4, but am having problems with the poppler headers. I'm using the conda-forge recipe, which includes a line in the build script to detect the poppler version.

FOR /F "tokens=1,2 delims=." %%a IN ("%poppler%") DO (
  set POPPLER_MAJOR_VERSION=%%a
  set POPPLER_MINOR_VERSION=%%b
)
https://github.com/conda-forge/gdal-feedstock/commit/320e66064c1288d582a3cadd8b573c863af654d6#diff-6f4a4b77035617ba53fd8a4d15347c44bb89f09d8086a0ffc1a5fca230ae2ed5R16

This doesn't seem to be working, as when we get to compiling the pdf driver, the headers are missing.

(gdal314) %SRC_DIR%\frmts>cd pdf   && nmake /nologo /f makefile.vc<http://makefile.vc>   && cd ..   || exit 1
        cl   /nologo /MP4 /MD /EHsc /Ox /FC /D_CRT_SECURE_NO_DEPRECATE /D_CRT_NONSTDC_NO_DEPRECATE /DNDEBUG /W4 /wd4127 /wd4251 /wd4275 /wd4786 /wd4100 /wd4245 /wd4206 /wd4351 /wd4611  /DHAVE_SSE_AT_COMPILE_TIME /DHAVE_SSSE3_AT_COMPILE_TIME -I..\..\port -I..\..\ogr -I..\..\gcore  -I..\..\alg -I..\..\ogr\ogrsf_frmts  -I..\..\gnm -I..\..\gnm\gnm_frmts -I..\..\apps /DHAVE_AVX_AT_COMPILE_TIME -I..\vrt -I..\mem -I..\..\ogr\ogrsf_frmts\mem  -DPOPPLER_MAJOR_VERSION=0 -DPOPPLER_MINOR_VERSION=23 -DHAVE_POPPLER    -DGNM_ENABLED  -DGDAL_COMPILATION -DNOMINMAX /c pdfdataset.cpp pdfio.cpp pdfobject.cpp pdfcreatecopy.cpp ogrpdflayer.cpp pdfwritabledataset.cpp pdfreadvectors.cpp pdfcreatefromcomposition.cpp
pdfdataset.cpp
pdfio.cpp
pdfobject.cpp
pdfcreatecopy.cpp
c:\bin\anaconda3\conda-bld\gdal_1604943770331\work\frmts\pdf\pdfsdk_headers.h(54): fatal error C1083: Cannot open include file: 'goo/gtypes.h': No such file or directory (compiling source file pdfdataset.cpp)

In pdfsdkheaders.h we can see it's the wrong poppler version that's causing the error:

#if !(POPPLER_MAJOR_VERSION >= 1 || POPPLER_MINOR_VERSION >= 73)
#include <goo/gtypes.h>
#else
typedef unsigned char Guchar;
#endif

The installed version of poppler is 20.11.0, so I don't know why I'm getting major version set to 0 and minor version set to 23.

I'll also ask over at conda as this is most likely a conda build problem, but I thought I would also ask here if anyone has successfully built a conda package and knows how to get this recipe working.

Many thanks!

Jon

Jon Morris
Software Developer

COVID-19. During the current outbreak JBA remains open for business and we continue to deliver our services. However, we have adopted flexible/remote working as required. I will be receiving and reading email as normal but I may not always be available on the office number.

[JBA COVID-19 statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>

T +44 (0) 1756 799919
www.jbarisk.com<http://www.jbarisk.com>

[Visit our website]<http://www.jbarisk.com/> [http://www.jbagroup.co.uk/imgstore/JBA-Email-Sig-Icons-LINKEDIN.png] <https://www.linkedin.com/in/jon-morris-a2897b4/>  [Follow us on Twitter] <https://twitter.com/jbarisk>

Find out more about us here: www.jbarisk.com<http://www.jbarisk.com/> and follow us on Twitter @JBARisk<http://twitter.com/JBARisk> and LinkedIn<https://www.linkedin.com/company/2370847?trk=tyah&trkInfo=clickedVertical%3Acompany%2CclickedEntityId%3A2370847%2Cidx%3A2-1-2%2CtarId%3A1447414259786%2Ctas%3AJBA%20RISK%20MANAGEMENT>

The JBA Group supports the JBA Trust.

All JBA Risk Management's email messages contain confidential information and are intended only for the individual(s) named. If you are not the named addressee you should not disseminate, distribute or copy this e-mail.
Please notify the sender immediately by email if you have received this email by mistake and delete this email from your system.

JBA Risk Management Limited is registered in England, company number 07732946, 1 Broughton Park, Old Lane North, Broughton, Skipton, North Yorkshire, BD23 3FD, Telephone: +441756799919

_______________________________________________
gdal-dev mailing list
gdal-dev at lists.osgeo.org<mailto:gdal-dev at lists.osgeo.org>
https://lists.osgeo.org/mailman/listinfo/gdal-dev

[JBA COVID-19 statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>

[JBA COVID-19 statement]<https://www.jbagroup.co.uk/sites/www.jbagroup.co.uk/files/documents/15-030%20JBA%20Business%20Continuity%20Briefing%20-%20Latest.pdf>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.osgeo.org/pipermail/gdal-dev/attachments/20201113/d494ae37/attachment-0001.html>