Tomas Volf <~@wolfsden.cz> writes: > Ludovic Courtès <l...@gnu.org> writes: > >> Hi, >> >> Tomas Volf <~@wolfsden.cz> skribis: >> >>> The documentation for `with-extensions' says: >>> >>>> In the same vein, sometimes you want to import not just pure-Scheme >>>> modules, but also “extensions” such as Guile bindings to C libraries >>>> or other “full-blown” packages. >> >> It’s not just bindings but also pure Scheme libraries like Guile-JSON. > > True, and for those it works well. However the text documentation > explicitly mentions "bindings to C libraries" as one of the use > cases. :) > >> >>> However it does not actually add those C libraries into >>> (guile-extensions-path), which means that trying to actually use a >>> library imported this way will lead to an error. >> >> [...] >> >>> 190:25 1 (load-foreign-library _ #:extensions _ >>> #:search-ltdl-library-path? _ # _ # _ # …) >>> In unknown file: >>> 0 (dlopen "libguile-yamlpp.so" 1) >>> >>> ERROR: In procedure dlopen: >>> In procedure dlopen: file "libguile-yamlpp.so", message >>> "libguile-yamlpp.so: cannot open shared object file: No such file or >>> directory" >> >> Usually, packages like these (guile-gnutls, guile-git, guile-ssh, etc.) >> have their .so absolute file name hard-coded, which sidesteps this >> problem entirely. I recommend doing that for guile-yamlpp as well. > > How it that usually done? I cannot do that *before* build, because then > tests would not run (the library is not yet installed into the absolute > path), and I cannot do it after, because I would need to rebuild the .go > files after patching the source code.
you can use substitute* to adjust source.
e.g.
(or (false-if-exception (load-extension "/path/to/lib-some-object-file.so"))
(load-extension "lib-some-object-file.so"))
>
> Assuming I have a guile library that creates a new .so library during
> the build, and the .so library must be loadable by the other modules in
> the library during the build (and for the tests), how should I approach
> that?
>
> I am pretty sure I cannot just patch the source code, since the library
> would not be installed into the absolute path yet during the build.
>
> Honestly, setting GUILE_EXTENSIONS_PATH via pre-inst-env seemed like
> fairly elegant solution.
>
>>
>> That said, it would probably make sense to arrange for ‘with-extensions’
>> to set GUILE_EXTENSIONS_PATH.
>
> That would be great. My current work-around is
>
> (with-extensions (list guile-wolfsden)
> (program-file
> "audio-cycle-sinks"
> #~(begin
> ;; Bug 74532: Native extensions are not added to the load path.
> (eval-when (expand load eval)
> (let ((ext-path (@ (system foreign-library)
> guile-extensions-path)))
> ;; Just a temporary hack, we can live with duplicates in the
> path.
> (ext-path (cons #$(file-append guile-wolfsden
> "/lib/guile/3.0/extensions")
> (ext-path)))))
> ...)))
>
> which is anything but elegant.
>
>>
>> Ludo’.
>>
>> PS: Your MUA sets “Mail-Followup-To: bug-guix@gnu.org”, which is kinda
>> annoying because that’s the wrong address when replying to a bug.
>> :-)
>
> Thanks for letting me know, I was not aware of that. After reading
> (message)Mailing Lists bit more carefully, adjusting the Posting Styles
> and sending a bug fix to the Emacs' bug tracker, I believe it should not
> happen anymore. Sorry for the annoyance.
signature.asc
Description: PGP signature
