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.mor...@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 <rune...@gmail.com> > *Sent:* 11 November 2020 09:18 > *To:* Jon Morris <jon.mor...@jbarisk.com> > *Cc:* gdal-dev@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.mor...@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 && > 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.* > > > > [image: 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 > > [image: Visit our website] <http://www.jbarisk.com/> > <https://www.linkedin.com/in/jon-morris-a2897b4/> [image: 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@lists.osgeo.org > https://lists.osgeo.org/mailman/listinfo/gdal-dev > > [image: 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> >
_______________________________________________ gdal-dev mailing list gdal-dev@lists.osgeo.org https://lists.osgeo.org/mailman/listinfo/gdal-dev