Re: [PATCH 1/1] configure.ac: attempt mysql_config to find the MySQL headers.

[Michael Orlitzky]

On 3/6/20 5:39 PM, Heinrich Schuchardt wrote:
> 
> Thanks for your suggestion.
> 
> Should we only use 'mysql_config --include' or the more comprehensive
> 'mysql_config --cflags'?

The --cflags option will output the flags that were used to compile the
MySQL client library. Usually that's not what we want. For example, if
clang was used to compile MySQL and if GCC is being used to compile
glpk, there could be flags in $(mysql_config --cflags) that crash GCC.


> In the scenario that you describe wouldn't the library also be installed
> in a user path. So would we have to consider 'mysql_config --libs'?

If you were linking directly to the MySQL client library, and if you
were to locate it at build time, then yes; we would need to tell the
linker where to look for the library as well. But in glpk, the library
is xdlopen()ed at runtime, bypassing the compile-time link phase.

That doesn't make the problem go away, but the solution is less obvious
to me. In the following lines (taken from multiple files), a relative
path is passed to xdlopen:

  LIBMYSQL="libmysqlclient.so"
  AC_DEFINE_UNQUOTED([MYSQL_DLNAME], ["$LIBMYSQL"], [N/A])
  #define libmysql MYSQL_DLNAME
  h_mysql = xdlopen(libmysql);

The xdlopen() function in turn calls lt_dlopen(), whose documentation
says that it will search three locations for a library named by a
relative path:

 1. user-defined search path
 2. libltdl's search path
 3. system library search path

In other words, whoever is going to run glpk needs to put the MySQL
client library in one of those places. That already works on Gentoo,
because our local "prefix" installations modify LD_LIBRARY_PATH.

To be honest, I haven't spent much time thinking about how calls to
dlopen() should be designed to work in these local installations. I
would hesitate to "fix" it without understanding the problem better (if
there even is a problem).