| Summary: | dev-lisp/cl-sql-5.0.3 cannot load clsql_uffi.so | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Carlos Konstanski <ckonstanski> |
| Component: | [OLD] Development | Assignee: | Common Lisp Bugs <common-lisp> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | ||
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | AMD64 | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Bug Depends on: | |||
| Bug Blocks: | 337963 | ||
clsql was updated to 5.0.4 this morning, and the bug remains. I am going to build clsql manually when I get the chance to see if the problem exists with the makefiles, or if it's the ebuild that is at fault. I tried a manual clsql installation. The file clsql_uffi64.so was properly built. I suspect the ebuild simply fails to copy the file to /usr/lib64/clsql/. This should be an easy fix. Just use the same methodology in src_install() as you use in install_clsql_pkg() for discovering all .so files to be copied. Or even use a kludge like: cp clsql_uffi*.so /usr/lib64/clsql/ I've included this fix in -r2, please try it OK, this is an improvement. Both clsql_uffi.so and clsql_uffi64.so make it into /usr/lib/clsql. But clsql_mysql.so fails because of this: ld -shared -soname=clsql_mysql clsql_mysql.o -L/lib32 -L/usr/lib32 -melf_i386 -lmysqlclient -lz -lc -o clsql_mysql.so ld: skipping incompatible /usr/lib/libmysqlclient.so when searching for -lmysqlclient ld: cannot find -lmysqlclient make: [clsql_mysql.so] Fehler 1 (ignoriert) Why are we looking for a 32 bit mysql build? This is bad; it'll never work on an amd64 system. It appears that this happens in the clsql makefile in db-mysql. Looks like the makefile tries to build both 64 and 32 bit libraries. The uffi makefile does this too. The difference is that the uffi makefile does not define LDFLAGS32 with "-L/lib32 -L/usr/lib32 -melf_i386", so the i386 build succeeds. Not sure why clsql builds 32 bit libraries on a 64 bit system anyway. At any rate, this looks like their bug, not yours. RESOLVED, WONTFIX. Package removed from the main tree. For more information, please see bug #337963 . |
When trying to load a database backend that requires clsql_uffi.so (such as 'clsql-oracle), I get an error that says clsql_uffi could not be found. Yet the file exists, and CLSQL-SYS:*FOREIGN-LIBRARY-SEARCH-PATHS* includes the path to it. Except I'm not sure what the clsql_uffi64.so stuff is all about. Is there supposed to be another .so for amd64 systems? Not tested on x86; I don't own one. debugger invoked on a SIMPLE-ERROR in thread #<THREAD "initial thread" RUNNING {1002AC1011}>: Couldn't load foreign libraries "clsql_uffi64", "clsql_uffi". (searched CLSQL-SYS:*FOREIGN-LIBRARY-SEARCH-PATHS*) Type HELP for debugger help, or (SB-EXT:QUIT) to exit from SBCL. restarts (invokable by number or by possibly-abbreviated name): 0: [RETRY ] Retry performing #<ASDF:LOAD-OP NIL {10037CB0B1}> on #<ASDF:CL-SOURCE-FILE "clsql-uffi-loader" {1004A09271}>. 1: [ACCEPT] Continue, treating #<ASDF:LOAD-OP NIL {10037CB0B1}> on #<ASDF:CL-SOURCE-FILE "clsql-uffi-loader" {1004A09271}> as having been successful. 2: [ABORT ] Exit debugger, returning to top level. (FIND-AND-LOAD-FOREIGN-LIBRARY ("clsql_uffi64" "clsql_uffi"))[:EXTERNAL] 0] CLSQL-SYS:*FOREIGN-LIBRARY-SEARCH-PATHS* (#P"/usr/share/common-lisp/source/clsql/uffi/" #P"/usr/lib64/clsql/" #P"/usr/lib64/") 0] 2 ; ; compilation unit aborted ; caught 1 fatal ERROR condition * (quit) root@sphinktop:/usr/lib64/clsql# ll insgesamt 8 -rwxr-xr-x 1 root root 4660 12. Feb 08:32 clsql_uffi.so