maria-developers team mailing list archive

["Vladislav Vaintroub" <wlad@xxxxxxxxxxxxxxxx>]

> -----Original Message-----
> From: Steve Ellcey [mailto:sje@xxxxxxxxxx]
> Sent: Dienstag, 8. November 2011 22:51
> To: Sergei Golubchik
> Cc: Vladislav Vaintroub; maria-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Maria-developers] Shared plugin library build question
> 
> On Sun, 2011-11-06 at 15:45 +0100, Sergei Golubchik wrote:
> 
<skip>

> I have downloaded these sources and done a trial build.  I have run into
> a couple of problems so far.  When compiling 5.5/mysys/base64.c I get an
> error because it is including <base64.h> and
> finding /usr/local/include/base64.h before 5.5/include/base64.h.  This
> causes an error because the base64_encode in that header does not match
> the one in mariadb.  I assume we are using the wrong base64.h because
> mysys/CMakeFiles/CMakeDirectoryInformation.cmake
> has:
> 
> SET(CMAKE_C_INCLUDE_PATH
>   "include"
>   "/usr/local/include"
>   "/wsp/sje/mariadb/bazaar/repo/5.5/include"
>   "/wsp/sje/mariadb/bazaar/repo/5.5/mysys"
>   )
> 
> where /usr/local/include is listed before the 5.5/include and 5.5/mysys
> directories.  Unfortunately, CMakeDirectoryInformation.cmake is
> generated by Cmake and I am not sure where it gets its information from
> about the order of the include files. 

Include directories in cmake are manipulated by INCLUDE_DIRECTORIES directive http://www.cmake.org/cmake/help/cmake-2-8-docs.html#command:include_directories  . It has an option for appending , prepending and an for SYSTEM  headers( I'm not sure about  exact effect  of this one) 

mysys/CMakeLists.txt has at the very top of the file 
INCLUDE_DIRECTORIES(${ZLIB_INCLUDE_DIR} ${CMAKE_SOURCE_DIR}/include ${CMAKE_SOURCE_DIR}/mysys)

I assume ZLIB_INCLUDE_DIR is /usr/local/include, since we use system zlib if it is available. You can try to change order here and for example move ${CMAKE_SOURCE_DIR}/include to the start of the list.


I think the best option for MySQL, and for MariaDB is to rename own base64.h and function prototypes in a way that it does not conflict with system headers on any system it is meant to be run on. Relying on the include order is fragile,  I also do not see how it would not solve the problem with same function name different prototypes - how can we  always reliably force  use our base64_encode rather than system one ?

 FYI: I am building in an object
> directory that is separate from the source directory, I don't know if
> that is related to the problem or not.

It should not be a problem.