Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Foreign library dependencies #10

Closed
lockie opened this issue Oct 30, 2019 · 5 comments
Closed

Foreign library dependencies #10

lockie opened this issue Oct 30, 2019 · 5 comments

Comments

@lockie
Copy link
Contributor

lockie commented Oct 30, 2019

Hey.
Thanks for the wonderful library, I absolutely enjoy using it :)
However, I have a small problem with my particular setup.
I'm writing a library that uses bodge-nuklear, a wrapper around C library called nuklear. The problem is that for some reason it depends on two .so libraries, libnuklear.so.bodged and libglad.so.bodged (no idea why .bodged prefix, but that's not important), and the former depends on latter:

$ ldd src/bin/libnuklear.so.bodged
        linux-vdso.so.1 (0x00007fffe47a1000)
        libglad.so.bodged => not found
        libc.so.6 => /lib64/libc.so.6 (0x00007fd657396000)
        /lib64/ld-linux-x86-64.so.2 (0x00007fd65781b000)

Now, deploy perfectly detects both libraries and copies them in bin/ directory, but when I launch the resulting executable, it crashes because it can't find the libglad.so.bodged library (because obviously LD_LIBRARY_PATH on unices does not include current directory unlike on windows):

 ==> Reloading foreign libraries.
   -> Loading foreign library #<LIBRARY LIBNUKLEAR.SO.BODGED-631>.
 ==> Encountered unhandled error: Unable to load foreign library (LIBNUKLEAR.SO.BODGED-631).
  Error opening shared object "/path/redacted/bin/libnuklear.so.bodged":
  libglad.so.bodged: cannot open shared object file: No such file or directory.

Of course I can workaround that by writing simple shell script that sets up LD_LIBRARY_PATH properly, but can it be done purely by lisp code means? I'm thinking maybe some sort of :depends keyword in deploy:define-library or something.

@Shinmera
Copy link
Owner

You can define a build hook that sorts *foreign-libraries-to-reload* to the proper order. It's true that a dependency system would be much more convenient, but I'd have to add that feature first.

@lockie
Copy link
Contributor Author

lockie commented Oct 30, 2019

All right, thanks, I'll try that.

@lockie
Copy link
Contributor Author

lockie commented Oct 30, 2019

Sorry for noobish question, I'm still new to CL ecosystem. While trying the workaround you've suggested, I'm getting either
The symbol "*FOREIGN-LIBRARIES-TO-RELOAD*" is not external in the DEPLOY package. or The variable MY-PACKAGE::*FOREIGN-LIBRARIES-TO-RELOAD* is unbound. errors. Seems like it has to do with that variable not being exported from deploy. How can I fix that?..

@Shinmera
Copy link
Owner

deploy::*foreign-libraries-to-reload*

@lockie
Copy link
Contributor Author

lockie commented Oct 30, 2019

Thanks a lot!

@lockie lockie closed this as completed Nov 26, 2021
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

2 participants