#65304 closed defect (fixed)
mariadb-10.3 @10.3.34_0: configure fails without GnuTLS
| Reported by: | jmroot (Joshua Root) | Owned by: | michaelld (Michael Dickens) |
|---|---|---|---|
| Priority: | Normal | Milestone: | |
| Component: | ports | Version: | |
| Keywords: | Cc: | ||
| Port: | mariadb-10.3 mariadb-10.2 |
Description
The port declares a dependency on openssl and configures with -DWITH_SSL:STRING=yes. Apparently this isn't sufficient to stop some part of the build system from looking for gnutls instead.
Attachments (1)
Change History (13)
Changed 23 months ago by jmroot (Joshua Root)
| Attachment: | mariadb.log added |
|---|
comment:1 Changed 23 months ago by jmroot (Joshua Root)
| Port: | mariadb-10.2 added |
|---|---|
| Summary: | mariadb-10.3 @10.3.34_0: configure looks for GnuTLS → mariadb-10.3 @10.3.34_0: configure fails without GnuTLS |
comment:2 follow-up: 3 Changed 23 months ago by michaelld (Michael Dickens)
Guessing 10.4 shows the same issue, since it is configured in the same way. Testing an alternative configuration setting
comment:3 Changed 23 months ago by jmroot (Joshua Root)
Replying to michaelld:
Guessing 10.4 shows the same issue, since it is configured in the same way.
It doesn't, interestingly. It fails on a couple of older OS versions, but not for this reason: https://ports.macports.org/port/mariadb-10.4/details/
comment:4 Changed 23 months ago by michaelld (Michael Dickens)
Interesting. Whatever I'm fixing 10.4 as well. Requires a tweak to the CMake arguments as well as some minor CMakeLists fixes to get the includes ordering correct (enough). Will be committing later today after a little more testing.
comment:5 Changed 23 months ago by michaelld (Michael Dickens)
comment:6 Changed 23 months ago by michaelld (Michael Dickens)
comment:7 Changed 23 months ago by michaelld (Michael Dickens)
Let's see if those fixes work as desired. They do locally with lots of MP ports installed ... who knows if they work on the buildbots!?
comment:8 Changed 23 months ago by jmroot (Joshua Root)
| Resolution: | → fixed |
|---|---|
| Status: | assigned → closed |
Looks good; these versions now built successfully on almost all platforms, same as the newer versions. (The remaining failures are the PCRE_STACK_SIZE_OK check failing on 10.7, and __atomic_fetch_add_8 missing on i386.)
comment:9 Changed 23 months ago by michaelld (Michael Dickens)
Great! I will some day get back to those older OSX versions & try to get these issues fixed up ... but, for today: progress!
comment:10 Changed 23 months ago by kencu (Ken)
the i386 atomic thing has to do with picking a clang that has had the atomics added back into the compiler_rt (I did most of them).
comment:11 Changed 23 months ago by michaelld (Michael Dickens)
@kencu: is there a Portfile example of how to blacklist or whitelist the correct Clang? that would make this task nice and simple ...
comment:12 Changed 23 months ago by kencu (Ken)
I fixed up the remaining macports-clang-* versions here, so once they all rebuild, all of the macports-clangs should be good to go.
https://github.com/macports/macports-ports/commit/0820f79ced5cea2e8439188fa582def05f6807b2
I don't actually recall which Xcode clangs do or don't have i386 atomic support enabled in compiler_rt at the moment, if I ever knew. I rarely use Xcode clang for anything on any but the very newest systems any longer. I would not trust it to supply i386 atomics, anyway, but perhaps some do.
10.2 is doing the same thing after the recent update.