[MDEV-15778] Build issues on macOS 10.13.4 Created: 2018-04-04 Updated: 2018-07-03 Resolved: 2018-07-03 |
|
| Status: | Closed |
| Project: | MariaDB Server |
| Component/s: | Storage Engine - InnoDB, Storage Engine - RocksDB, Storage Engine - TokuDB |
| Affects Version/s: | 10.3 |
| Fix Version/s: | 5.5.62, 10.0.37, 10.3.9 |
| Type: | Bug | Priority: | Major |
| Reporter: | Teodor Mircea Ionita (Inactive) | Assignee: | Teodor Mircea Ionita (Inactive) |
| Resolution: | Fixed | Votes: | 0 |
| Labels: | None | ||
| Environment: |
macOS 10.13.4 |
||
| Issue Links: |
|
||||||||||||
| Description |
|
This is a master issue used to track all the build issues on latest macOS 10.13.4, which fails in multiple storage engines. Steps for building followed from MariaDB.org Attaching individual errors bellow: Inno
RocksDB
Was missing lib to dbug lib. TokuDBTokuDB especially is in a bad shape on macOS, maybe it didn't receive much attention in that regard.
Needs proper %ll format specifier.
ZERO_COND_INITIALIZER is using wrong toku_cond_t struct initializer for first member of type pthread_cond_t and not considering the TOKU_PTHREAD_DEBUG case which has one extra struct member of type pfs_key_t.
This issue can be fixed by doing chmod +x for install-sh script. It is being discussed on the mailing list.
pthread_mutex_timedlock() is not available in pthreads for Mac, as it's not part of the POSIX pthreads spec, I need a suggestion on how to proceed.The encompassing event_t::wait() method seems to be unused. Could be removed? Otherwise rewrite without timedlock.
This is happening because omt_ classes are declared as packed and clang has -Waddress-of-packed-member when passing the address of a packed member, a legit concern on different architectures. The easiest way to get rid of the errors is to remove the packed attribute from said structs. Also reported
Was missing link to dbug lib.
Not sure what's happening here, I see that opt_debug_sync_timeout is declared as extern, however no immediate definition is available. It is used to inform the compiler via __builtin_expect branch prediction on line toku_debug_sync.h:66:
|
| Comments |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-04-10 ] |
|
|
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-04-26 ] |
|
Worth mentioning is that some, or all, of the fixes reported here are impairing the Travis macOS builds also. Builds were last done 16 days ago. https://travis-ci.org/MariaDB/server/jobs/364437601 |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-05-10 ] |
|
I've split all fixes in PR#691 into smaller branch specific PRs based on when the issue first originated, to the best of my ability. Sadly, I think I'm out of the merge window this time, but still do proceed and review the fixes at: https://github.com/MariaDB/server/pull/750 |
| Comment by Sergei Petrunia [ 2018-05-15 ] |
|
Merged the PR that relates to MyRocks: https://github.com/MariaDB/server/pull/753 |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-05-15 ] |
|
Attaching a sample macOS build of 10.3 with all my fixes in, featuring 100% completion: http://buildbot.askmonty.org/buildbot/grid?category=main&branch=tm-10.3-macfixes |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-05-15 ] |
|
psergey I see that you reverted the change in innobase, can I have the failure output? |
| Comment by Sergei Petrunia [ 2018-05-16 ] |
|
teodor, yes. Was just going to make a note about this: http://lists.askmonty.org/pipermail/commits/2018-May/012548.html Unfortunately I don't have the output, and it seems difficult to get it out the buildbot. The complaints about failing build were from Marko (I assume x64 linux) and Wlad (re windows). I think you can observe the compile failures by pushing the patch into a bb-* branch. |
| Comment by Sergei Petrunia [ 2018-05-16 ] |
|
Oh, and now the buildbot page is finally loaded: |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-05-21 ] |
|
Hmm, that's interesting. Looks like MSVC complains that it can't reinterpret_cast from DWORD (32b unsigned) which is returned by GetCurrentThreadId() to ULINT size_t ULONG_PTR (64b unsigned on on x64) [1]. However, on macOS the complaint is that you cannot convert from opaque type returned by pthread to size_t (only fixable via reinterpret_cast)... Maybe needs more consideration to not use cast after all. I would be curious about the Linux error too, not sure how to dig up the buildbot builds for that specific commit though. wlad Do you have that at hand in any way? [1] https://msdn.microsoft.com/en-us/library/windows/desktop/aa383751(v=vs.85).aspx |
| Comment by Vladislav Vaintroub [ 2018-05-21 ] |
|
I only look at windows builds. Everyone else notices Linux failures. Since there was no noise about broken buildbot, and just marko complained, I'd assume it was 32bit. |
| Comment by Marko Mäkelä [ 2018-05-23 ] |
|
Yes, at least one 32-bit Linux build failed as well. |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-07-03 ] |
|
Review done with cvicentiu. |
| Comment by Teodor Mircea Ionita (Inactive) [ 2018-07-03 ] |
|
All main branches build properly with default CMake args now on macOS 10.13.5 with Apple LLVM version 9.1.0 (clang-902.0.39.2). |