Open triplq opened 5 months ago
I have the same problem trying to build xeus-sql 0.2.1 with soci 4.0.3
[ 25%] Building CXX object CMakeFiles/xeus-sql.dir/src/xeus_sql_interpreter.cpp.o
/usr/bin/g++ -DGUID_LIBUUID -DUSE_MYSQL=1 -DUSE_POSTGRE_SQL=1 -DUSE_SQLITE3=1 -DXEUS_SQL_EXPORTS -DXVEGA_EXPORTS -Dxeus_sql_EXPORTS -I/builddir/build/BUILD/xeus-sql-0.2.1/include -O2 -g -pipe -Wformat -Werror=format-security -Wp,-U_FORTIFY_SOURCE,-D_FORTIFY_SOURCE=3 -specs=/usr/lib/rpm/redhat/redhat-hardened-cc1 -fstack-protector-strong -m64 -fasynchronous-unwind-tables -fstack-clash-protection -fcf-protection=full -DNDEBUG -fPIC -Wunused-parameter -Wextra -Wreorder -march=native -MD -MT CMakeFiles/xeus-sql.dir/src/xeus_sql_interpreter.cpp.o -MF CMakeFiles/xeus-sql.dir/src/xeus_sql_interpreter.cpp.o.d -o CMakeFiles/xeus-sql.dir/src/xeus_sql_interpreter.cpp.o -c /builddir/build/BUILD/xeus-sql-0.2.1/src/xeus_sql_interpreter.cpp
In file included from /builddir/build/BUILD/xeus-sql-0.2.1/src/xeus_sql_interpreter.cpp:33:
/usr/include/soci/mysql/soci-mysql.h:24:10: fatal error: mysql.h: No such file or directory
24 | #include <mysql.h> // MySQL Client
| ^~~~~~~~~
compilation terminated.
This seems rather different because I'd expect mysql.h
to exist in /opt/homebrew/include
, which is used for the include files search in the original report, while in your case there doesn't seem any appropriate -I
option at all.
You will need to check how/where does CMake find this header.
This seems rather different because I'd expect
mysql.h
to exist in/opt/homebrew/include
, which is used for the include files search in the original report, while in your case there doesn't seem any appropriate-I
option at all.You will need to check how/where does CMake find this header.
Yes, you're right. I don't know how this instruction is coming for you and not for me. https://github.com/jupyter-xeus/xeus-sql/blob/main/CMakeLists.txt
This is likely an issue with the SOCI-provided FindMySQL
module (https://github.com/SOCI/soci/blob/master/cmake/modules/FindMySQL.cmake)
In #1118 I have improved the find-module. @papoteur-mga would you be able to test whether the issue keeps appearing when building SOCI from the branch of my PR? (Until proven otherwise, I'll assume the issue to be resolved in my revamped cmake version)
In #1118 I have improved the find-module. @papoteur-mga would you be able to test whether the issue keeps appearing when building SOCI from the branch of my PR? (Until proven otherwise, I'll assume the issue to be resolved in my revamped cmake version)
Hi @Krzmbrzl Thanks for you work. I tried to build soci from your repo. I encounter a problem that libraries are installed in /usr/lib64/soci/ directory, when they was previously in /usr/lib64/
Build instruction was:
/usr/bin/cmake -Wno-dev -S . -B build -DCMAKE_CXX_FLAGS_RELWITHDEBINFO:STRING=-DNDEBUG -DCMAKE_C_FLAGS_RELWITHDEBINFO:STRING=-DNDEBUG -DCMAKE_CXX_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_C_FLAGS_RELEASE:STRING=-DNDEBUG -DCMAKE_INSTALL_DO_STRIP:BOOL=OFF -DCMAKE_INSTALL_LIBDIR:PATH=lib64 -DCMAKE_INSTALL_LIBEXECDIR:PATH=libexec -DCMAKE_INSTALL_PREFIX:PATH=/usr -DCMAKE_INSTALL_RUNSTATEDIR:PATH=/run -DCMAKE_INSTALL_SYSCONFDIR:PATH=/etc -DINCLUDE_INSTALL_DIR:PATH=/usr/include -DLIB_INSTALL_DIR:PATH=/usr/lib64 -DSYSCONF_INSTALL_DIR:PATH=/etc -DSHARE_INSTALL_PREFIX:PATH=/usr/share -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLIB_SUFFIX=64 -DCMAKE_VERBOSE_MAKEFILE:BOOL=ON '-DCMAKE_MODULE_LINKER_FLAGS=-Wl,--as-needed -Wl,-z,relro -Wl,-z,now -Wl,-O1 -Wl,--build-id=sha1 -Wl,--enable-new-dtags -specs=/usr/lib/rpm/redhat/redhat-hardened-ld' -DBUILD_SHARED_LIBS:BOOL=ON -DBUILD_STATIC_LIBS:BOOL=OFF -GNinja -DSOCI_STATIC=OFF -DSOCI_SHARED=ON -DSOCI_CXX11=ON -DSOCI_ASAN=OFF -DSOCI_EMPTY=ON -DSOCI_SQLITE3=ON -DSOCI_POSTGRESQL=ON -DSOCI_MYSQL=ON -DSOCI_ODBC=ON -DWITH_ORACLE=OFF -DBUILD_TESTS=NONE
Another problem is that /usr/lib64/libsoci_mysql.so is the library instead of being a link to the library, which have to be /usr/lib64/libsoci_mysql.so.4.1.0
I encounter a problem that libraries are installed in /usr/lib64/soci/ directory, when they was previously in /usr/lib64/
why is this a problem?
Another problem is that /usr/lib64/libsoci_mysql.so is the library instead of being a link to the library, which have to be /usr/lib64/libsoci_mysql.so.4.1.0
Yeah, I can reproduce that. It seems that this only affects MySQL though - I get
└── soci
├── libsoci_core.so -> libsoci_core.so.4
├── libsoci_core.so.4 -> libsoci_core.so.4.1.0
├── libsoci_core.so.4.1.0
├── libsoci_empty.so -> libsoci_empty.so.4
├── libsoci_empty.so.4 -> libsoci_empty.so.4.1.0
├── libsoci_empty.so.4.1.0
├── libsoci_firebird.so -> libsoci_firebird.so.4
├── libsoci_firebird.so.4 -> libsoci_firebird.so.4.1.0
├── libsoci_firebird.so.4.1.0
├── libsoci_mysql.so
├── libsoci_odbc.so -> libsoci_odbc.so.4
├── libsoci_odbc.so.4 -> libsoci_odbc.so.4.1.0
├── libsoci_odbc.so.4.1.0
├── libsoci_postgresql.so -> libsoci_postgresql.so.4
├── libsoci_postgresql.so.4 -> libsoci_postgresql.so.4.1.0
├── libsoci_postgresql.so.4.1.0
├── libsoci_sqlite3.so -> libsoci_sqlite3.so.4
├── libsoci_sqlite3.so.4 -> libsoci_sqlite3.so.4.1.0
└── libsoci_sqlite3.so.4.1.0
so for the other backends things seem to work as expected. I'll look into that
Okay that was easy. It's fixed already:
└── soci
├── libsoci_core.so -> libsoci_core.so.4
├── libsoci_core.so.4 -> libsoci_core.so.4.1.0
├── libsoci_core.so.4.1.0
├── libsoci_empty.so -> libsoci_empty.so.4
├── libsoci_empty.so.4 -> libsoci_empty.so.4.1.0
├── libsoci_empty.so.4.1.0
├── libsoci_firebird.so -> libsoci_firebird.so.4
├── libsoci_firebird.so.4 -> libsoci_firebird.so.4.1.0
├── libsoci_firebird.so.4.1.0
├── libsoci_mysql.so -> libsoci_mysql.so.4
├── libsoci_mysql.so.4 -> libsoci_mysql.so.4.1.0
├── libsoci_mysql.so.4.1.0
├── libsoci_odbc.so -> libsoci_odbc.so.4
├── libsoci_odbc.so.4 -> libsoci_odbc.so.4.1.0
├── libsoci_odbc.so.4.1.0
├── libsoci_postgresql.so -> libsoci_postgresql.so.4
├── libsoci_postgresql.so.4 -> libsoci_postgresql.so.4.1.0
├── libsoci_postgresql.so.4.1.0
├── libsoci_sqlite3.so -> libsoci_sqlite3.so.4
├── libsoci_sqlite3.so.4 -> libsoci_sqlite3.so.4.1.0
└── libsoci_sqlite3.so.4.1.0
(not that I force-pushed my PR branch, so you'd have to do a hard reset to get the latest changes without merge conflicts)
Okay that was easy. It's fixed already:
Fine, this is fixed.
Now I'm facing another problem. Header files are installed in /usr/include/soci/soci
. I don't think it is expected.
I encounter a problem that libraries are installed in /usr/lib64/soci/ directory, when they was previously in /usr/lib64/
why is this a problem?
I don't know yet, but I wonder if the change is wanted, and why.
Now I'm facing another problem. Header files are installed in /usr/include/soci/soci. I don't think it is expected.
Oh, right. :eyes: Should be fixed with my next commit.
I don't know yet, but I wonder if the change is wanted, and why.
I made this choice deliberately because I think it's more organized than every project just blindly installing into /usr/lib64/
directly and looking in that directory on my system, there doesn't seem to be any standard to which one should conform :shrug:
After applying your last fix, I think not all header files are installed. This was already the case before the fix.
fatal error: soci/is-detected.h: No such file or directory
I had previously header files in soci/empty/
soci/sqlite3/
soci/mysql/
soci/postgresql/
soci/odbc/
soci/oracle/
, but this is no more the case.
Indeed. I missed the is-detected.h
one and also forgot to declare the backend-specific headers. Both issues should be remedied now.
I have now these header files:
/usr/include/soci/mysql/soci-mysql.h
/usr/include/soci/odbc/soci-odbc.h
/usr/include/soci/postgresql/soci-postgresql.h
/usr/include/soci/sqlite3/soci-sqlite3.h
The bad news is that xeus-sql doesn't recognize SOCI.
CMake Error at /usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:233 (message):
Could NOT find Soci (missing: SOCI_LIBRARY)
Call Stack (most recent call first):
/usr/share/cmake/Modules/FindPackageHandleStandardArgs.cmake:603 (_FPHSA_FAILURE_MESSAGE)
cmake/FindSoci.cmake:97 (FIND_PACKAGE_HANDLE_STANDARD_ARGS)
CMakeLists.txt:69 (find_package)
Now I'm facing another problem. Header files are installed in /usr/include/soci/soci. I don't think it is expected.
Oh, right. 👀 Should be fixed with my next commit.
I don't know yet, but I wonder if the change is wanted, and why.
I made this choice deliberately because I think it's more organized than every project just blindly installing into
/usr/lib64/
directly and looking in that directory on my system, there doesn't seem to be any standard to which one should conform 🤷
Now, I have an argument for the "why not": The change breaks the detection of soci
in xeus-sql.
See https://github.com/jupyter-xeus/xeus-sql/blob/4189a98992195f7021aab9bc07aeb9227d8b8a33/cmake/FindSoci.cmake#L47-L52 and https://github.com/jupyter-xeus/xeus-sql/blob/4189a98992195f7021aab9bc07aeb9227d8b8a33/cmake/FindSoci.cmake#L65-L70
And I still have this:
usr/include/soci/mysql/soci-mysql.h:21:10: fatal error: private/soci-trivial-blob-backend.h: No such file or directory
And I still have this: usr/include/soci/mysql/soci-mysql.h:21:10: fatal error: private/soci-trivial-blob-backend.h: No such file or directory
That is addressed in a different PR
Now, I have an argument for the "why not": The change breaks the detection of soci in xeus-sql.
You shouldn't be using a FindSOCI
module anymore. With the cmake revamp, SOCI supports cmake natively (that is, you can search for it in config mode of find_package
).
And I still have this: usr/include/soci/mysql/soci-mysql.h:21:10: fatal error: private/soci-trivial-blob-backend.h: No such file or directory
That is addressed in a different PR
But trivial-blob-backend.h
is not listed here: https://github.com/SOCI/soci/blob/6b6db13fc99ce838fe8929708d786a2333e0533f/src/core/CMakeLists.txt#L47-L98
Now, I have an argument for the "why not": The change breaks the detection of soci in xeus-sql.
You shouldn't be using a
FindSOCI
module anymore. With the cmake revamp, SOCI supports cmake natively (that is, you can search for it in config mode offind_package
).
I will try that.
But trivial-blob-backend.h is not listed here: https://github.com/SOCI/soci/blob/6b6db13fc99ce838fe8929708d786a2333e0533f/src/core/CMakeLists.txt#L47-L98
Yes, because it is currently a private header (which it shouldn't be). I'll add it once the PR putting it into the private includes is merged.
You shouldn't be using a
FindSOCI
module anymore. With the cmake revamp, SOCI supports cmake natively (that is, you can search for it in config mode offind_package
).
OK, I removed FindSOCI, used find_package(SOCI REQUIRED)
in CMakeLists.txt of xeus-sql.
It now takes SOCIConfigSOCI.make from SOCI project, but fails.
CMake Error at CMakeLists.txt:69 (find_package):
Found package configuration file:
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake
but it set SOCI_FOUND to FALSE so package "SOCI" is considered to be NOT
FOUND. Reason given by package:
Unmet dependency 'MySQL' for SOCI component 'MySQL'
Note that previously package to find was Soci
, but I have to use SOCI
in upper case.
Hm. Maybe we have to install the FindMySQL module along with SOCI in order for it to find that 🤔
Note that previously package to find was Soci, but I have to use SOCI in upper case.
Yeah, SOCI is the correct name and case-sensitive filesystems this becomes important. This was an oversight of the previous cmake implementation.
OK, I removed FindSOCI, used
find_package(SOCI REQUIRED)
in CMakeLists.txt of xeus-sql. It now takes SOCIConfigSOCI.make from SOCI project, but fails.
Hello, I try again, now with adding some verbosity:
-- Found Boost: /usr/lib64/cmake/Boost-1.86.0/BoostConfig.cmake (found version "1.86.0") found components: date_time
-- Found MySQL: /usr/lib64/libmysqlclient.so
-- Found ODBC: /usr/lib64/libodbc.so
-- Found PostgreSQL: /usr/lib64/libpq.so (found version "17.0")
-- Found SQLite3: /usr/include (found version "3.46.1")
[...]
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(98): if(TARGET MySQL::MySQL )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(100): else()
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(101): set(__already_found OFF )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(102): break()
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(106): if(__already_found )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(110): if(__components )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(114): if(SOCI_FIND_QUIETLY )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(116): else()
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(117): set(__quiet )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(120): find_package(MySQL )
-- Found MySQL: /usr/lib64/libmysqlclient.so
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(126): if(NOT MySQL_FOUND )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(127): if(__required )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(128): set(SOCI_FOUND FALSE )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(129): set(SOCI_NOT_FOUND_MESSAGE Unmet dependency 'MySQL' for SOCI component 'MySQL' )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(130): set(__skip_dependency TRUE )
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake(132): continue()
[...]
CMake Error at CMakeLists.txt:69 (find_package):
Found package configuration file:
/usr/lib64/cmake/soci-4.1.0/SOCIConfig.cmake
but it set SOCI_FOUND to FALSE so package "SOCI" is considered to be NOT
FOUND. Reason given by package:
Unmet dependency 'MySQL' for SOCI component 'MySQL'
MySQL is said found, but the variable MySQL_FOUND is false or not set.
clone soci into
/Users/alexey/CLionProjects/untitled1/lib/soci
with terminalgit clone
and write a CMakeLists.txt as inexample/subdir-include/CMakeLists.txt
Here is my CMakeLists.txt:
Here is my error: