← Back to team overview

maria-developers team mailing list archive

Re: Shared plugin library build question

 


> -----Original Message-----
> From: Steve Ellcey [mailto:sje@xxxxxxxxxx]
> Sent: Mittwoch, 9. November 2011 01:53
> To: Vladislav Vaintroub
> Cc: 'Sergei Golubchik'; maria-developers@xxxxxxxxxxxxxxxxxxx
> Subject: Re: [Maria-developers] Shared plugin library build question
> 
> On Wed, 2011-11-09 at 00:54 +0100, Vladislav Vaintroub wrote:
> 
> > If you stuck, a simple way to fix it  might be  to add -D_REENTRANT to
> cmake/os/HP-UX.cmake ,
> > so everything is compiled with it.
> > The line
> > ADD_DEFINITIONS(-D_REENTRANT)
> >
> > would do the trick.
> 
> I added 'ADD_DEFINITIONS(-pthread)' instead, the -pthread flag causes
> the compiler to define _REENTRANT.  I don't see any cmake configure code
> that tries to determine if -pthread is needed when compiling or linking
> and I don't see its use in any of the other cmake files, I find this
> surprising.  The Mariadb 5.3.2 configure script certainly has code to
> see if -pthread (or -mt or -threads) should be used or not.


> I am also not sure if this is all I need for linking since we want to
> use -pthread to link in the libpthread library.  Do flags added with
> ADD_DEFINITIONS get used on a link line or is there another rule I
> should use in addition to ADD_DEFINITIONS?

The flags here are added to compile flags. If compiler is also the linker, you'll get them in the link line too. Use 
make VERBOSE=1
to see the full command line, or you can find  the full link line in the CMakeFiles/<target>.dir/link.txt , as described here http://forge.mysql.com/wiki/CMake#Tips_for_developers 

You should not use any other rule for threads, it is taken care automatically by FIND_PACKAGE(Threads) and LINK_LIBRARIES(${CMAKE_THREAD_LIBS_INIT}) inside configure.cmake.  The documentation on FIND_PACKAGE and different modules  for might not be a strongest point of CMake, but if you googling for  CMAKE_THREAD_LIBS_INIT brings good hits.


> I now die when compiling client/mysql.cc.  HIST_ENTRY does not seem to
> be defined but HAVE_HIST_ENTRY is.  This might be another include file
> issue, I am not sure yet.

Oh, this is libedit vs readline. It is the most complicated stuff in  current cmake setup (cmake/readline.cmake), that unfortunately got ported  1-1 from autotools, and the code in autotools was already bad originally and it has not got prettier with CMake , and it was my very first CMake code , and it remained as ugly as it was at the start.

 But to the problem

There are different possibilities to use system readline, system libedit,  bundled readline,  bundled libedit , the default is bundled libedit (frankly I've got no clue why we or MySQL have a choice of 2 almost equivalent libs, but anyway)

The cmake flags that enable one or another are
-DWITH_READLINE={1,0} 
 -DWITH_LIBEDIT={1,0}

If none is set (equivalent to both are 0), system library is searched, with readline preference, and libedit backoff. I have to admit , I do not understand the logic in cmake/readline.cmake fully, so this is also from my memory mostly. One of those libs should be new otherwise there are problems with header files, and HIST_ENTRY might well be  this problem.

What you can definitely  do right now, is  to remove CMakeCache.txt and rerun 
cmake <path-to-source> -DWITH_LIBEDIT=0 -DWITH_READLINE=0 

and rebuild mysql client with "make mysql"

If that fails,  try the cmake <path-to-source>  -DWITH_LIBEDIT=0 -DWITH_READLINE=1  . 
Once we find the variant that works on HPUX, I'd prefer to hardcode that in cmake/os/HP-UX.cmake  (if memory serves me right, only readline is workable on HPUX, not libedit, but it has been some time since I have compiled 5.5 on HPUX )

> Steve Ellcey
> sje@xxxxxxxxxx




Follow ups

References