Since the last update, https://pkg.absolight.fr/data/10amd64-pkgng/20150720T220543Z/logs/errors/gdal-2.0.0.log In file included from ecwdataset.cpp:31: In file included from ./gdal_ecw.h:59: In file included from /usr/local/include/NCSFile.h:27: In file included from /usr/local/include/NCSJP2FileView.h:42: In file included from /usr/local/include/NCSJPCBuffer.h:27: In file included from /usr/local/include/NCSJPCRect.h:25: In file included from /usr/local/include/NCSJPCTypes.h:31: /usr/local/include/NCSMalloc.h:52:10: fatal error: 'alloca.h' file not found #include <alloca.h> ^ 1 warning and 1 error generated. ../../GDALmake.opt:576: recipe for target '../o/ecwdataset.o' failed gmake[3]: *** [../o/ecwdataset.o] Error 1
Created attachment 159043 [details] patch for graphics/libecwj2 The error is inside of graphics/libecwj2. As mentioned, in Source/include/NCSMalloc.h is an include to alloca.h, which does not exists on FreeBSD. There are examples on the net, that removing the include should be sufficient. The function alloca() is implemented in stdlib.h instead, both for glibc and non-glibc (not proofed) [1][2]. I filed a patch for graphics/libecwj2, which is meant as a replacement for the ports files/patch-Source-include-NCSMalloc.h. After rebuilding graphics/libecwj2, it should be possible to also build graphics/gdal with option ECW enabled. I hope it is ok in this special case to use a patch for another, dependend port in this PR, because of the context. Maintainer of graphics/libecwj2 CC'd. [1] https://forums.freebsd.org/threads/request-for-a-new-port.30354/ [2] https://trac.transmissionbt.com/ticket/4700
I'm test-building this change in libecwj2 against gdal right now.
The results are somewhat inconclusive. with ECW, gdal builds for 10.1i and fails for 10.1a, 9.3a. without ECW, gdal builds for 10.1i and 10.1a, and still fails for 9.3a. See http://people.freebsd.org/~pi/logs/graphics__gdal-* with graphics__gdal-10i-1437593128.txt: ECW=on: ECW image format support graphics__gdal-10i-1437600820.txt: ECW=off: ECW image format support graphics__gdal-10x-1437593128.txt: ECW=on: ECW image format support graphics__gdal-10x-1437600820.txt: ECW=off: ECW image format support graphics__gdal-93a-1437593128.txt: ECW=on: ECW image format support graphics__gdal-93a-1437600820.txt: ECW=off: ECW image format support
(In reply to Kurt Jaeger from comment #3) Looking into the logs, both 9.3-RELEASE-p18 files report about an error not beeing able to create gdaldither.o ../GDALmake.opt:582: recipe for target 'gdaldither.o' failed This seems unrelated to the ECW problem? Only graphics__gdal-10i-1437593128.txt reports about a failure of ECW. The error message is exactly like the one, generated by using an unpatched graphics/libecwj2. Did the patch for graphics/libecwj2 really apply and is gdal really using the patched version?
The problem is actually in gdal, not in libecwj2. The libecwj2 header includes alloca.h only in case of LINUX. That's why it was never a problem. Starting with new gdal version, it runs compilation with -DLINUX. gmake[4]: вход в каталог «/usr/ports/graphics/gdal/work/gdal-2.0.0/frmts/ecw» c++ -I/usr/ports/graphics/gdal/work/gdal-2.0.0/port -I/usr/ports/graphics/gdal/work/gdal-2.0.0/gcore -I/usr/ports/graphics/gdal/work/gdal-2.0.0/alg -I/usr/ports/graphics/gdal/work/gdal-2.0.0/ogr -I/usr/ports/graphics/gdal/work/gdal-2.0.0/ogr/ogrsf_frmts -O2 -pipe -fPIC -fstack-protector -fno-strict-aliasing -fPIC -Wall -DFRMT_ecw -DOGR_ENABLED -I/usr/ports/graphics/gdal/work/gdal-2.0.0/port -I/usr/local -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr/local/include -I/usr/local/include -I/usr/local -I/usr/local/include -I/usr -I/usr/include -DGDAL_COMPILATION -DLINUX -DX86 -DPOSIX -DHAVE_COMPRESS -DECW_COMPRESS_RW_SDK_VERSION -I/usr/local/include -c -o ../o/ecwdataset.o ecwdataset.cpp
The required change to fix this issue is: -ECW_CONFIGURE_ON= --with-ecw=${LOCALBASE} +ECW_CONFIGURE_ON= --with-ecw=yes However, the port also has problems with grabbing libiconv port (if one is installed), so I end up with the following patch.
Created attachment 159394 [details] patch - Use proper keyword to enable ECW. Otherwise port autodetect presence of ECW and use -DLINUX upon build. - GDAL actually depends on iconv and can't be build w/o it. Properly force system iconv instead of GNU one as described in https://www.freebsd.org/doc/en/books/porters-handbook/using-iconv.html
(In reply to Gleb Smirnoff from comment #7) I can confirm, that this patch works for me on HEAD amd64 with ECW testdata. And sorry for my misleading suggestion in comment #1 and the patch in attachment 159043 [details]. It also worked, but did not solve the real problem.
The patch fails for me on 9.3a and 10.1i with some iconv issue, see http://people.freebsd.org/~pi/graphics__gdal-10i-1438267417.txt and .../graphics__gdal-93a-1438267417.txt
Kurt, the URL is 404. :(
Sorry, it's: http://people.freebsd.org/~pi/logs/graphics__gdal-10i-1438267417.txt
The 10th failure is related to iconv, I will try to fix. On 9.3 looks like old gcc can't cope with new GDAL source.
I wonder why on your system it depends on iconv: ===> gdal-2.0.0_1 depends on file: libiconv>=1.14_8 - not found On my stable/10 with my patch it doesn't.
Even in the presence of libiconv-1.14 package installed, my gdal still is configured correctly: using ICONV_CPP_CONST="" I guess something is wrong at your stable/10 installation or the gdal port isn't properly patched.
(In reply to Gleb Smirnoff from comment #7) Thanks. I'll fix ECW first. For iconv part, it seems more tests are required.
A commit references this bug: Author: sunpoet Date: Fri Jul 31 17:17:15 UTC 2015 New revision: 393360 URL: https://svnweb.freebsd.org/changeset/ports/393360 Log: - Fix ECW option PR: 201736 Submitted by: glebius Changes: head/graphics/gdal/Makefile
It still is broken on 9amd64: gdaldither.cpp: In function 'int FindNearestColor(int, int*, int, int, int)': gdaldither.cpp:534: note: use -flax-vector-conversions to permit conversions between vectors with differing element types or numbers of subparts gdaldither.cpp:534: error: cannot convert 'int __vector__' to 'long long int __vector__' for argument '1' to 'long long int __vector__ __builtin_ia32_psrlqi128(long long int __vector__, int)' gdaldither.cpp:539: error: cannot convert 'int __vector__' to 'long long int __vector__' for argument '1' to 'long long int __vector__ __builtin_ia32_psrlqi128(long long int __vector__, int)' ../GDALmake.opt:582: recipe for target 'gdaldither.o' failed gmake[1]: *** [gdaldither.o] Error 1 https://pkg.absolight.fr/data/9amd64-pkgng/20150901T021801Z/logs/errors/gdal-2.0.0_1.log
(In reply to Mathieu Arnold from comment #17) Confirmed still broken, http://builder.miwibox.org/data/93amd64-m-miwi/2016-01-08_15h23m02s/logs/errors/gdal-2.0.1_1.log
Should be fixed now.
If it's fixed, why does it fail on 11a ? http://people.freebsd.org/~pi/logs/gdal-2.0.1_3.log Any ideas ?
I think your problem is a different one. This PR is about ECW option and your problem seems to be about NETCDF option (nc_*). Regarding your case, I've committed a patch to science/netcdf which adds pkg-config as runtime dependency. Please try again if it fixes the linking problem.
(In reply to Sunpoet Po-Chuan Hsieh from comment #22) Yes, this works now. Thanks!
(In reply to Kurt Jaeger from comment #23) Thank you for pointing out the netcdf problem. :)