NetBSD 6.1, gcc 4.5.3, readline-6.2

Looking at cmake/readline.cmake, HAVE_HIST_ENTRY is set only if following code compiles.
CHECK_CXX_SOURCE_COMPILES("
#include <stdio.h>
#include <readline/readline.h>
int main(int argc, char **argv)

"
HAVE_HIST_ENTRY)

In other words, including <readline/readline.h> alone must be sufficient for HIST_ENTRY to be found (at least the test is written is this way)

I presume that there is some kind of conflict between system header and the header in cmd-line-utils/readline.h. Would it be possible for you to find out which one gets included during compilation? Could you also attach CMakeCache.txt from the build directory , for diagnostics ?
Thanks!

Here's the cmake what's it. I'll look in the other part shortly.

There are two readlines it appears:

/usr/include/readline/readline.h

which defines HIST_ENTRY directly, and

/usr/pkg/include/readline/readline.h

installed by the package system (pkgin, similar to apt/yum) probably as a dependency with other packages. My cmake configure command was:

cmake -DCMAKE_C_FLAGS="-Wno-char-subscripts -I/usr/pkg/include" -DCMAKE_EXE_LINKER_FLAGS=-L/usr/pkg/lib .

I suspect that your readline test does not include the extra -I and -L paths when testing and so picks up the system readline.h instead of the package installed one.

If you also set -DREADLINE_INCLUDE_DIR=/usr/pkg/include , and rebuild, will this work? to me it looks like it should

Can you also tell why are you using you actually /usr/pkg/include, if you have the header already installed in standard place? Also is this necessary to use /usr/pkg/lib, rather than /usr/lib ? I
Are those more standard places in NetBSD that the usual /usr/include and /usr/lib ? then you probably need to talk to gcc folks to set the default header path on that platform (or CMake folks.. I cannot imagine every program would need to add -I and -L flags to workaround cmake and gcc)

All the extra packages that get installed, similar to what rpm, apt, or yum do, go under the /usr/pkg tree, which is a standard location for NetBSD packages. I didn't know that NetBSD already included readline in the stock installation and the package one was added as a dependency, and by force of habit I include /usr/pkg. I'm currently trying a build without using /usr/pkg, if that fails I'll try with your suggested change for readline directory.

BTW these warnings also appear during compile:

[ 13%] Building C object mysys/CMakeFiles/mysys.dir/my_gethwaddr.c.o
/usr/local/src/mariadb-5.5.31/mysys/my_gethwaddr.c:26:16: warning: 'memcpy_and_test' defined but not used

[ 61%] Building C object sql/CMakeFiles/sql.dir/__/sql-common/client_plugin.c.o
/usr/local/src/mariadb-5.5.31/sql-common/client_plugin.c: In function 'mysql_client_register_plugin':
/usr/local/src/mariadb-5.5.31/sql-common/client_plugin.c:327:11: warning: 'unused' may be used uninitialized in this function
/usr/local/src/mariadb-5.5.31/sql-common/client_plugin.c: In function 'mysql_client_plugin_init':
/usr/local/src/mariadb-5.5.31/sql-common/client_plugin.c:263:15: warning: 'unused' may be used uninitialized in this function

[ 67%] Building CXX object sql/CMakeFiles/sql.dir/sql_test.cc.o
/usr/local/src/mariadb-5.5.31/sql/sql_test.cc: In function 'void mysql_print_status()':
/usr/local/src/mariadb-5.5.31/sql/sql_test.cc:630:29: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'time_t'
/usr/local/src/mariadb-5.5.31/sql/sql_test.cc:630:29: warning: format '%lu' expects type 'long unsigned int', but argument 4 has type 'time_t'

Without explicit reference to /usr/pkg, cmake appears to discover /usr/pkg/include/readline/readline.h, but still fails to build. With explicit reference using -I and -L to /usr/pkg, it fails to build. Applying my patch, rectifies the issue.

If you require, I can create a user account on my NetBSD file server for you to conduct your own build experiments. Contact me directly by email for details.

Anthony,
If you would like to contribute a machine to MariaDB's buildbot, it is described in "Volunteering to run a build slave" section in https://kb.askmonty.org/en/about-buildbot/.
The basic requirement for slave is that it needs to be online (have prerequisites for the build installed of course, too)

PS. This is followup to mail exchange, you mail server seems to reject montyprogram.com mails now