Re: uffi and clsql-mysql and AMD_64

Whee!  We got past that problem.  Thanks for the debian vs. gentoo
path tip.  The box that worked off the shelf was, in addition to being
a 32 bit machine, also a debian build.  The 64 bit machine is gentoo.
It wasn't a 64 bit problem; it was more a gentoo problem.  Here's
looking at the file compiling properly this time:

; compiling file "/usr/share/common-lisp/source/clsql-uffi/uffi/clsql-uffi-loader.lisp"
(written 28 AUG 2005 07:38:55 PM):
; compiling (IN-PACKAGE #:CLSQL-UFFI)
; compiling (DEFUN FIND-AND-LOAD-FOREIGN-LIBRARY ...)
; compiling (DEFVAR *CLSQL-UFFI-LIBRARY-FILENAMES* ...)
; compiling (DEFVAR *CLSQL-UFFI-SUPPORTING-LIBRARIES* ...)
; compiling (DEFVAR *UFFI-LIBRARY-LOADED* ...)
; compiling (DEFUN LOAD-UFFI-FOREIGN-LIBRARY ...)
; compiling (LOAD-UFFI-FOREIGN-LIBRARY)

; /var/cache/common-lisp-controller/ckonstan/sbcl/clsql-uffi/uffi/clsql-uffi-loader.fasl written
; compilation finished in 0:00:00

On the roll with gentoo problems, now I'm getting a missing makefile.
This file does not exist on the debian machine either, however.  If it
did, I would have been tempted to copy it over.  Is it a temporarily
written and deleted file?  Seems unlikely, given the location (owned
by root).  Incidentally, I'm running sbcl as root in all these cases
to be sure of avoiding such pitfalls in this debugging session.

; $ cd /usr/share/common-lisp/source/clsql-mysql/db-mysql/; make
make: *** No targets specified and no makefile found.  Stop.

debugger invoked on a ASDF:OPERATION-ERROR:
   erred while invoking #<COMPILE-OP NIL {10016D9581}> on
   #<CLSQL-MYSQL-SOURCE-FILE "mysql" {10016D9E21}>

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:COMPILE-OP NIL {10016D9581}> on
               #<CLSQL-MYSQL-SYSTEM::CLSQL-MYSQL-SOURCE-FILE "mysql" {10016D9E21}>.
   1: [ACCEPT] Continue, treating #<ASDF:COMPILE-OP NIL {10016D9581}> on
               #<CLSQL-MYSQL-SYSTEM::CLSQL-MYSQL-SOURCE-FILE "mysql" {10016D9E21}>
               as having been successful.
   2: [ABORT ] Exit debugger, returning to top level.

((SB-PCL::FAST-METHOD ASDF:PERFORM
                       (ASDF:COMPILE-OP
                        CLSQL-MYSQL-SYSTEM::CLSQL-MYSQL-SOURCE-FILE))
  #<unavailable argument>
  #<unavailable argument>
  #<ASDF:COMPILE-OP NIL {10016D9581}>
  #<CLSQL-MYSQL-SYSTEM::CLSQL-MYSQL-SOURCE-FILE "mysql" {10016D9E21}>)

Debian box:

root <at> homeserv:/usr/share/common-lisp/source/clsql-mysql/db-mysql# ll
total 72
-rw-r--r--  1 root root 18982 Dec  3  2004 mysql-api.lisp
-rw-r--r--  1 root root  1673 Sep 15  2004 mysql-client-info.lisp
-rw-r--r--  1 root root  2757 Jan 28  2005 mysql-loader.lisp
-rw-r--r--  1 root root  2066 Oct  1  2004 mysql-objects.lisp
-rw-r--r--  1 root root  4125 Sep 15  2004 mysql-package.lisp
-rw-r--r--  1 root root 28099 Apr  6 08:58 mysql-sql.lisp
-rw-r--r--  1 root root  3486 Oct 19  2004 mysql.c

Gentoo box:

root <at> sphinktoo:/usr/share/common-lisp/source/clsql-mysql/db-mysql# ll
total 72
-rw-r--r--  1 root root  3492 Aug 28 19:38 clsql_mysql.c
-rw-r--r--  1 root root 18982 Aug 28 19:38 mysql-api.lisp
-rw-r--r--  1 root root  1673 Aug 28 19:38 mysql-client-info.lisp
-rw-r--r--  1 root root  2365 Aug 28 19:38 mysql-loader.lisp
-rw-r--r--  1 root root  2066 Aug 28 19:38 mysql-objects.lisp
-rw-r--r--  1 root root  4125 Aug 28 19:38 mysql-package.lisp
-rw-r--r--  1 root root 28388 Aug 28 19:38 mysql-sql.lisp

Neither have the makefile.  I went back and verified that the debian box
can build from scratch by deleting everything in
/var/cache/common-lisp-controller/.  So how does the debian box work?
My guess is that both these directories look right, and the problem lies
elsewhere.  But where?

It doesn't help that mysql.c is differently named on the gentoo box.
creating a symlink to mysql.c does nothing for the problem.

I'm running a big grep right now to see if I can find any references to
mysql.c on the debian box.

Carlos

On Sun, 28 Aug 2005, Kevin Rosenberg wrote:

> Date: Sun, 28 Aug 2005 20:13:06 -0600
> From: Kevin Rosenberg <kevin@...>
> To: Carlos Konstanski <ckonstan@...>
> Cc: clsql mailing list <clsql-help@...>
> Subject: Re: [CLSQL-Help] uffi and clsql-mysql and AMD_64
> 
> Carlos Konstanski wrote:
>> Here's the end of compilation and the error dump:
>
> Looks like your shared library wasn't built. Or it is was, CLSQL is
> not finding it. It looks like your using common-lisp-controller. Is
> this on Debian? Because the Debian CLSQL package automatically
> installs the shared libraries and adds /etc/clsql-init.lisp file with
> the following:
>  (clsql:push-library-path #p"/usr/lib/")
>  (clsql:push-library-path #p"/usr/lib/clsql/")
>
>> root <at> sphinktoo:/# ls -l /usr/lib/clsql/clsql_uffi.so
>> -rwxr-xr-x  1 root root 2528 Aug 28 18:19 /usr/lib/clsql/clsql_uffi.so
>>
>> Now we know that at least the one .so file is there.
>
> Yep, you can use an /etc/clsql-init.lisp file to add that path like
> the above.
>
>> /usr/share/common/lisp/source/clsql-uffi/uffi/.  Maybe I am once
>
> That's from the common lisp controller.
>
> Is this a gentoo package your trying to build. If so, it's not
> correctly made.
>
>> misinterpreting things, but it seems to be saying it wants to find the
>> .so files there.
>
> You are correct.
>
>> * clsql-uffi-system::*library-file-dir*
>> (:ABSOLUTE "usr" "share" "common-lisp" "source" "clsql-uffi" "uffi")
>> which is the path to the asdf packages, not the .so files.  So this path
>> is probably not the issue, and it's not supposed to be the path to the
>> .so files.  Dead end.
>
> That's the path to the CLSQL source.
>
>> I did attempt to cripple the 64 bit part, with the result that I got a
>> nearly identical backtrace to the one shown above, but it only
>> complained about clsql_uffi rather than both libraries.  Which brings up
>> a point - this debug trace is complaining about both libraries, though
>> one of them is present on the filesystem.
>
> But not found in a standard place. You need the clsql-init.lisp file
> to tell CLSQL where the shared library is.
>
>> Also, creating the symlink clsql_uffi64.so -> clsql_uffi.so has no effect.
>
> That's right. clsql_uffi.so is all you need. Don't worry about the
> *64.so file.
>
>> Is there a path somewhere that points to the .so files that I can check?
>> Maybe we're looking in the wrong place entirely for the libraries, using
>> a path that isn't reported in the debug trace.
>
> No, that was ripped out in the recent reworking of library file
> searchs. Now, the correct way is to place the library file in a system
> location (like /usr/lib), so push a path for CLSQL to search in the
> /etc/clsql-init.lisp file.
>
> Kevin
>