The reason is — configure.cmake doesn't have the code to detect libnuma.
The fix should consist of:
- adding missing checks to configure.cmake or (preferrably) to storage/{xtradb,innobase}/CMakeLists.txt
- forcing numa from cmake/build_configurations/mysql_release.cmake
- installing libnuma as needed, if the build fails
- updating debian/control to mention the new build dependency
Note, new dependency means that we cannot do it in 10.0 or 10.1, and even in 10.2 it's barely possible.
Also, the question is — should we really impose this new dependency unconditionally on all users?
In 10.0 and 10.1 we can do 1. and 3. and force numa to be disabled in release builds. That is, no new dependency, but numa can be enabled in custom builds.
10.0/10.1 appears broken in the same way as below - no call to MYSQL_CHECK_NUMA()
10.2 specific break:
Broken in 3a3b3d8ba8d8f32feb7cf6c2609639635ddb53b5
debian/control has numa-dev (broken) and ${shlibs:Depends} will pick up on this.
Adding this dependency - its a 40-68k shared library depending on architecture and we've got other small compression libraries that aren't always used.
part 1. https://github.com/MariaDB/server/pull/399 (thanks jplindst for the merge in 10.2)
Same problem with RHEL7 RPMs.
Ok now I realize it does work in 10.2 and 10.3 just fine already. As long as the builder has numa library installed (libnuma-dev, libnuma-devel ...) That's one thing, to ensure builders have the library.
Question: is it okay to have 10.0 and 10.1 as-is?
Having the numa library optional, looks like a deliberate choice originally, so the dependency is not enforced. Feels somehow natural.
I wonder if it should be enforced or not.
For enforcing, there could be something like:
storage/innobase/innodb.cmake
|
|
|
IF(HAVE_LIBNUMA)
|
message( STATUS "The mandatory numa library found" )
|
ELSE()
|
message( FATAL_ERROR "You need to install numa library" )
|
ENDIF()
|
Yes, it should be optional. But if you can introduce WITH_NUMA option with possible values YES/NO/AUTO (the default being AUTO) — we have a bunch of these YES/NO/AUTO options, so WITH_NUMA behavior will be quite consistent with existing options.
When it's AUTO, it'll behave as now, with YES it'll abort when libnuma isn't found with NO it won't link with libnuma.
commit: 2fe025c45a47054d42703970d8d608642a535357
https://github.com/mariadb/server/commit/2fe025c45a47054d42703970d8
Hi serg ,
I have tested the pentve patch it works accordingly.
Is it okay to push ?
1. Did you test it with -DWITH_NUMA=OFF ? I'm not sure that
IF(NOT WITH_NUMA)
|
works for a string variable having the value of "OFF" (as a string).
2. It seems like an invalid value for WITH_NUMA is treated as "ON"
otherwise looks ok
I have tested with -DWITH_NUMA=OFF , it works
2. I think you are right , Invalid value is treated as on
http://lists.askmonty.org/pipermail/commits/2018-April/012410.html
Looks ok, thanks.
But please, fix the commit comment before pushing 