Bug 241799 - graphics/gdal: version 2.4.2_3 fails to compile on 12.1 with undefined reference to EVP_MD_CTX_create
Summary: graphics/gdal: version 2.4.2_3 fails to compile on 12.1 with undefined refere...
Status: New
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Sunpoet Po-Chuan Hsieh
URL:
Keywords:
Depends on:
Blocks:
 
Reported: 2019-11-08 09:26 UTC by Philip Homburg
Modified: 2020-05-20 09:12 UTC (History)
3 users (show)

See Also:
bugzilla: maintainer-feedback? (sunpoet)


Attachments
poudriere log (918.20 KB, text/plain)
2019-11-08 14:09 UTC, Philip Homburg
no flags Details

Note You need to log in before you can comment on or make changes to this bug.
Description Philip Homburg 2019-11-08 09:26:52 UTC
See atached poudriere log file
Comment 1 Loïc Bartoletti freebsd_committer 2019-11-08 10:21:06 UTC
(In reply to Philip Homburg from comment #0)

There is no attached file. Can you resend it please?
Comment 2 Philip Homburg 2019-11-08 14:09:41 UTC
Created attachment 208973 [details]
poudriere log
Comment 3 Philip Homburg 2019-11-08 14:10:02 UTC
(I had to trim the log a bit)
Comment 4 Thomas Guymer 2019-11-16 08:00:30 UTC
I just experienced this too whilst I was rebuilding all of my ports after I upgraded to 12.1-RELEASE.
Comment 5 Thomas Guymer 2019-12-08 13:40:39 UTC
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!
Comment 6 Thomas Guymer 2019-12-08 14:04:29 UTC
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
Comment 7 Thomas Guymer 2019-12-08 14:14:52 UTC
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.
Comment 8 Thomas Guymer 2019-12-08 14:24:41 UTC
(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.
Comment 9 Thomas Guymer 2020-05-02 08:01:40 UTC
Is there any update on this bug? I am still experiencing it 6 months later.
Comment 10 Loïc Bartoletti freebsd_committer 2020-05-02 11:40:08 UTC
(In reply to Thomas Guymer from comment #9)
Still true with gdal 3?
Comment 11 Thomas Guymer 2020-05-02 14:52:59 UTC
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
Comment 12 Vedrin Jeliazkov 2020-05-20 09:12:54 UTC
(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.