Fix compatibility with ClozureCL. #11

lockie commented 2019年11月18日 11:29:34 +01:00

Hello.
I've tried using deploy with ClozureCL and got the following error:

Error: The value #<SHLIB liballegro_audio.so.5.2 #x3020024F40CD> is not of the expected type (OR PATHNAME STREAM STRING).

with the following backtrace (truncated for clarity):

 (7FF883E25A20) : 0 (PATHNAME #<SHLIB liballegro_audio.so.5.2 #x3020024F403D>) 341
 (7FF883E25A38) : 1 (MERGE-PATHNAMES #P"liballegro_audio.so.5.2" #<SHLIB liballegro_audio.so.5.2 #x3020024F403D> :NEWEST) 285
 (7FF883E25A90) : 2 (FUNCALL #'#<#<STANDARD-METHOD DEPLOY:FIND-SOURCE-FILE (DEPLOY:LIBRARY)>> #<LIBRARY LIBALLEGRO-AUDIO>) 229

Upon investingating I found out that cffi:foreign-library-handle returns the PATHNAME object in SBCL, but under CCL it returns SHLIB object. I've tried replacing the call to cffi:foreign-library-handle with cffi:foreign-library-pathname, and it seemingly does the right thing - I was able to build my project using both SBCL and CCL.

Hello. I've tried using deploy with ClozureCL and got the following error: ``` Error: The value #<SHLIB liballegro_audio.so.5.2 #x3020024F40CD> is not of the expected type (OR PATHNAME STREAM STRING). ``` with the following backtrace (truncated for clarity): ``` (7FF883E25A20) : 0 (PATHNAME #<SHLIB liballegro_audio.so.5.2 #x3020024F403D>) 341 (7FF883E25A38) : 1 (MERGE-PATHNAMES #P"liballegro_audio.so.5.2" #<SHLIB liballegro_audio.so.5.2 #x3020024F403D> :NEWEST) 285 (7FF883E25A90) : 2 (FUNCALL #'#<#<STANDARD-METHOD DEPLOY:FIND-SOURCE-FILE (DEPLOY:LIBRARY)>> #<LIBRARY LIBALLEGRO-AUDIO>) 229 ``` Upon investingating I found out that `cffi:foreign-library-handle` returns the PATHNAME object in SBCL, but under CCL it returns SHLIB object. I've tried replacing the call to `cffi:foreign-library-handle` with `cffi:foreign-library-pathname`, and it seemingly does the right thing - I was able to build my project using both SBCL and CCL.

Shinmera commented 2019年11月18日 13:34:37 +01:00 (Migrated from github.com)

I believe the reason I used handle is because pathname is not always populated, specifically in cases where the library is coming from the system linker, rather than from CFFI's own resolution mechanism.

I'm not sure what the best fix would be in this case. Probably a mechanism that tries pathname, then falls back on implementation-dependent resolution based on the handle. For CCL there might be a function to get the pathname out of an SHLIB.

I believe the reason I used handle is because pathname is not always populated, specifically in cases where the library is coming from the system linker, rather than from CFFI's own resolution mechanism. I'm not sure what the best fix would be in this case. Probably a mechanism that tries pathname, then falls back on implementation-dependent resolution based on the handle. For CCL there might be a function to get the pathname out of an SHLIB.

lockie commented 2019年11月18日 13:40:33 +01:00

Oh, all right, thanks for clarification.

For CCL there might be a function to get the pathname out of an SHLIB.

I'll search for one and change this PR using conditional macro for CCL later then.

Oh, all right, thanks for clarification. > For CCL there might be a function to get the pathname out of an SHLIB. I'll search for one and change this PR using conditional macro for CCL later then.

lockie commented 2019年11月19日 05:52:03 +01:00

I've pushed commit that properly converts SHLIB to PATHNAME when on ClozureCL. Looks better?

I've pushed commit that properly converts SHLIB to PATHNAME when on ClozureCL. Looks better?

Shinmera commented 2019年11月19日 08:03:40 +01:00 (Migrated from github.com)

If it works for you, then yes, looks alright.

If it works for you, then yes, looks alright.

lockie commented 2019年11月19日 09:06:17 +01:00

Sure, I've tested it with both SBCL and CCL.
Thanks!

Sure, I've tested it with both SBCL and CCL. Thanks!