See atached poudriere log file
(In reply to Philip Homburg from comment #0) There is no attached file. Can you resend it please?
Created attachment 208973 [details] poudriere log
(I had to trim the log a bit)
I just experienced this too whilst I was rebuilding all of my ports after I upgraded to 12.1-RELEASE.
Has anyone had any luck working around this bug? I note that "graphics/gdal" was updated on 18/11/2019 to add build dependencies but unfortunately this hasn't solved the problem for me. I am still unable to build "graphics/gdal", which means that I cannot build "graphics/py-gdal", which means that I cannot build "graphics/py-cartopy" with the "PLOTTING" option enabled. Any help would be greatly appreciated, thank you!
PS: A bit of Googling informs me that "EVP_MD_CTX_create" is part of SSL. If it is relevant, I have tried compiling with both "DEFAULT_VERSIONS+= ssl=libressl" (my new default) and "DEFAULT_VERSIONS+= ssl=openssl" (my old default) in my "/etc/make.conf" and it made no difference either way - it still fails to build with the following two lines: ld: error: /usr/ports/graphics/gdal/work/gdal-2.4.2/libgdal.so: undefined reference to EVP_MD_CTX_create ld: error: /usr/ports/graphics/gdal/work/gdal-2.4.2/libgdal.so: undefined reference to EVP_MD_CTX_destroy PPS: I further note that in the build log the following macro is defined during compilation: "-DHAVE_OPENSSL_CRYPTO". Now, this technically isn't true (as I said, I now use "libressl"). In my opinion, this raises wider concerns: "graphics/gdal" does not list any SSL provider as a dependency anywhere yet it lists "ssl" as part of the "USES" section. I am a stranger to the FreeBSD port Makefiles, but is this correct behaviour? How does it know where to look for SSL? Could something have changed with the SSL paths in FreeBSD 12.1 that has broken "graphics/gdal"? Is "graphics/gdal" looking for SSL in a hard-coded fashion? I really don't know - any thoughts? PPPS: Final thought, are we seeing a FreeBSD version of this Gentoo bug? https://bugs.gentoo.org/669302
OK, I think that I have it: * FreeBSD 12.1 updated OpenSSL to 1.1.1d, see https://www.freebsd.org/releases/12.1R/relnotes.html * According to an answer on StackOverflow, version 1.1 of OpenSSL replaced EVP_MD_CTX_create() with EVP_MD_CTX_new() and replaced EVP_MD_CTX_destroy() with EVP_MD_CTX_free(), see https://stackoverflow.com/a/46769674 * If you look at the line that fails in the attached build log you will see that "graphics/gdal" tried to link to "libcrypto", see the "-lcrypto" part Is the 2.4.x branch of GDAL forever pinned to OpenSSL 1.0.x? Would updating "graphics/gdal" to the 3.0.x branch of GDAL allow it to be built against the base SSL that is now included in FreeBSD 12.1 (as opposed to 12.0)? I am trying to find a definitive list of build dependencies on its GitHub (https://github.com/OSGeo/gdal) but I am failing miserably.
(This is my final comment for the day, I swear) I am attempting to build "graphics/gdal" with default options, i.e., only "JASPER" is on. Crucially, "CURL" is off. So why does GDAL want to use SSL functions in the first place? The only file in the whole source that calls "EVP_MD_CTX_create()" is "cpl_sha256.cpp" (see https://github.com/OSGeo/gdal/blob/master/gdal/port/cpl_sha256.cpp). Why is "HAVE_OPENSSL_CRYPTO" being defined by the compiler? Is it truly required? If the macro was not defined then the offending part of "cpl_sha256.cpp" would not get compiled and then the link error would never occur.
Is there any update on this bug? I am still experiencing it 6 months later.
(In reply to Thomas Guymer from comment #9) Still true with gdal 3?
Hi, Yes, I have just tried to build "gdal-3.0.4_3" right now and it failed with the same message. The log file is more than 1000 KiB so I cannot attach it to this comment. I have instead uploaded it to GitHub and you can view it here: https://gist.github.com/Guymer/5c08afcce93281d680def73e79253c3c Thanks
(In reply to Thomas Guymer from comment #11) I've encountered a similar issue in FreeBSD 11.3-RELEASE-p9 with openssl-1.1.1g,1 installed from ports, DEFAULT_VERSIONS+=ssl=openssl, and gdal-3.1.0. I've tried enabling curl support through gdal's make config as a workaround. In this case the build succeeded, with a bunch of warnings like the following: "/usr/bin/ld: warning: libcrypto.so.11, needed by /usr/local/lib/libcurl.so, may conflict with libcrypto.so.8" The newly installed binaries seem to work fine though.
Hi everyone, I have just managed, for the first time in almost a year, to compile gdal. I was able to install "gdal-3.1.0_6" with "DEFAULT_VERSIONS+= ssl=libressl" in my "/etc/make.conf" file with the following options set (on FreeBSD 12.1-RELEASE-p9): CURL GEOS JASPER Previously I had tried JASPER and JASPER+CURL but it still failed (even this morning), I have no idea why adding GEOS made the SSL symbols "EVP_MD_CTX_create" and "EVP_MD_CTX_create" available, but hey, I am not complaining!