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).
