IRC channel logs

<jralls>I'm having a problem bundling Guile-2.0.11 in GnuCash for OSX. Everything works fine as long as guile can find its original installation. Once those are moved out of the way, or the App bundle is installed on another machine, Guile quits with the following error: guile: uncaught throw to system-error: (open-file ~A: ~S (No such file or directory Gnucash.app/Contents/Resources/share/guile/2.0/ice-9/Gnucash.app/Contents/Resour

<jralls>ces/share/guile/2.0/ice-9/r6rs-libraries.scm) (2))

<jralls>GUILE_LOAD_PATH=Gnucash.app/Contents/Resources/share/guile/2.0 and GUILE_LOAD_COMPILED_PATH is unset, though it doesn't matter if it's set to Gnucash.app/Contents/Resources/lib/guile/2.0/ccache.

<jralls>Gnucash.app/Contents/Resources/share/guile/2.0/ice-9/r6rs-libraries.scm exists, the path with the doubled entry path obviously doesn't.

<jralls>Any ideas on why Guile might be munging the path?

<mark_weaver>jralls: so Gnucash.app is in the current working directory during guile initialization?

<mark_weaver>does it work if you set GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH to absolute paths?

<jralls>mark_weaver: wait one.

<mark_weaver>IMO, setting them to absolute paths is the right thing. otherwise on-demand module loading is dependent on the CWD.

<jralls>mark_weaver: That might be when running from the command line. Not sure it's the case when launching from Finder, which doesn't have a pwd. Unfortunately on OSX also eats stdout/stderr so it's impossible to tell what's going on.

<mark_weaver>Guile does not automatically know how to find itself, except to look in compiled-in absolute paths. To make a movable application bundle on OS X, you'll need to find out where the bundle is and set the aforementioned environment variables before initializing Guile.

<jralls>mark_weaver: Does Guile pay no attention to LD_LIBRARY_PATH and friends?

<mark_weaver>LD_LIBRARY_PATH doesn't seem relevant to the problem you're having, at least not based on what you've written.

<jralls>mark_weaver: And I guess it's asking too much for it to know about @executable_path or @loader_path.

<mark_weaver>LD_LIBRARY_PATH is used by the dynamic loader before guile code is run.

<mark_weaver>when you load C extension libraries from guile, it uses libltdl and leaves the consultation of those variables to libltdl.

<jralls>What about *after* Guile is running? If one loads a module that depends on a compiled C library, what mechanism does Guile use to find that library and its dependencies?

<mark_weaver>it uses libltdl.

<mark_weaver>and what libltdl consults is platform dependent.

<mark_weaver>iirc, on most unix-like systems, it consults LD_LIBRARY_PATH and LTDL_LIBRARY_PATH and also some hardcoded paths depending on the system

<mark_weaver>but I don't know off hand what it looks at on OS X

<mark_weaver>I could dig into the libltdl to find out if it's important, but it doesn't seem germane to the problem you're having at the moment.

<mark_weaver>do you have a tool analogous to strace to trace system calls and find out what it's doing?

<jralls>Actually, it's the next problem that comes up after getting the absolute path set for GUILE_LOAD_PATH.

<mark_weaver>okay :)

<jralls>The strace equiv is dtruss, but I've never used it. However, ltdl was a clue: There's LTDL_LIBRARY_PATH, which I'll try first.

<mark_weaver>okay

<mark_weaver>jralls: libltdl also provides an API to add elements to its search path, without setting an environment variable.

<mark_weaver>see lt_dladdsearchdir and lt_dlinsertsearchdir in the libtool manual

<mark_weaver>if you use those, make sure to initialize libltdl first, using lt_dlinit

<jralls>mark_weaver: I actually suspect that the problem is getting the linked paths right. IOW, I suspect that ltdl is finding e.g. libgnc-module.dylib, but that's not finding libgnc-qof.dylib. If you're not familiar with OSX linking the explanation of why not would take a lot of explanation.

<mark_weaver>one advantage to 'lt_dlinsertsearchdir' is that it is platform independent.

<jralls>To the extent that ltdl correctly understands the platform, yes.

<jralls>In theory, LTDL_LIBRARY_PATH should do the same thing that lt_dlinsertsearchdir does.

<mark_weaver>in the libltdl source code, the name of that variable is configurable, although I can't say whether that configurability is used in practice.

<mark_weaver>near the top of ltdl.c:

<mark_weaver>/* Standard libltdl search path environment variable name */

<mark_weaver>#undef LTDL_SEARCHPATH_VAR

<mark_weaver>#define LTDL_SEARCHPATH_VAR"LTDL_LIBRARY_PATH"

<jralls>I'm using unmodified source from ftp.gnu.org.

<mark_weaver>(a tab got eaten)

<mark_weaver>okay

<mark_weaver>one hint: if libltdl fails to load a shared library for any reason at all, the error message is something like "not found".

<mark_weaver>not ideal, obviously :-/

<mark_weaver>but the error wouldn't look like it was coming from 'open-file'.

<mark_weaver>unfortunately, lt_dlopen doesn't provide any information about what went wrong, it just returns NULL for any error at all.

<jralls>Yes, I know, which is why I think that the problem is finding dependencies rather than the library ltdl is looking for.

<jralls>Another bit that I should have mentioned earlier: The "not found" is occurring when guile is trying to compile a scheme module that loads the dylib in question. Two questions arise:

<jralls>First, what's the executable when guile is compiling? Is it still the original exe that linked libguile?

<mark_weaver>yes

<jralls>Second, because the module is already compiled and in the bundle, is how detailed does the GUILE_LOAD_COMPILED_PATH have to be?

<mark_weaver>actually, I may not have fully understood your first question. "when guile is compiling" is too vague. if you run "guild compile" when your package is being built, that will use the guile executable that comes with guile.

<mark_weaver>if the compilation happens because you load a .scm file from your libguile-using-app that doesn't have a fresh .go, then the compilation is done in the executable of your libguile-using-app.

<jralls>OK, it's the second case.

<mark_weaver>as for GUILE_LOAD_COMPILED_PATH, it is an absolute requirement that it include some core modules like ice-9/boot-9.og0

<mark_weaver>s/og0/go/

<jralls>Yeah, that part is working. What it's not finding is gnucash scheme modules that are compiled. The compiled_path points to ...gnucash/ccache/2.0, but the files aren't all at that level, some are in subdirectories. Do all of the subdirs need to be included in the path?

<mark_weaver>DIR/ice-9/boot-9.go must exist for some DIR in GUILE_LOAD_PATH, if not in the compile-time constant guile installation dirctory.

<mark_weaver>guile

<jralls>Isn't it boot-9.go needs to be on GUILE_LOAD_COMPILED_PATH or boot-9.scm needs to be on GUILE_LOAD_PATH?

<mark_weaver>to load module (foo bar), guile will look in DIR/foo/bar.scm for every DIR in %load-path

<mark_weaver>and it will look for DIR/foo/bar.go for every DIR in %load-compiled-path

<mark_weaver>during guile initialization, those variables are initialized based on the values of GUILE_LOAD_PATH and GUILE_LOAD_COMPILED_PATH

<mark_weaver>sorry, you're right, my mistake.

<mark_weaver>I meant that DIR/ice-9/boot-9.go must exist for some DIR in GUILE_LOAD_COMPILED_PATH.

<jralls>Right. All of which is working.

<mark_weaver>what is the name of a gnucash module that is failing to load?

<jralls>All of them. But I found a new clue. The OSX dynamic linker has an env-var that makes it print out all of the calls to it, and it's failing to find the libs because the names have the version number in them, e.g libgnc-modules.0.dylib, but it's trying to load libgnc-modules.dylib.

<mark_weaver>the only error message I've seen so far is a failure to load r6rs-libraries.scm, and that's a core guile module.

<mark_weaver>the "dlopened modules" section of the libtool manual might be worth looking at.

<mark_weaver>e.g. section 10.1 (Building modules to dlopen) mentions a "-module" flag thats supposed to be passed to libtool when linking the module.

<jralls>That's from the relative path. At the top of Gnucash, change tmp="$0" to tmp="`pwd`/$0".

<mark_weaver>on GNU/Linux, there are typically symbolic links from libfoo.so -> libfoo.so.1.0

<jralls>There's also a tweak to GUILE_LOAD_COMPILED_PATH, add ${bundle_data}/gnucash/scm/ccache/2.0 to the path.

<mark_weaver>perhaps libltdl is expecting a similar setup where libgnc-modules.dylib -> libgnc-modules.0.dylib

<jralls>It needs help to know that. I just rebuilt the bundle to include the .la files for gnucash. That got it to launch once, but the second try fails with

<mark_weaver>in GNU/Linux, we can use libltdl to load any shared library, but the docs suggest that modules must be built specially to be loading using libltdl.

<jralls>[scm-error misc-error #f "~A ~S" ("no such language" tree-il) #f]

<mark_weaver>so maybe on OS X it's important to build the module in a certain way with libtool.

<mark_weaver>jralls: that error suggests that guile is trying to compile something and is unable to find its compiler modules.

<mark_weaver>specifically the .go files.

<mark_weaver>does DIR/language/tree-il/spec.go exist for some DIR in GUILE_LOAD_COMPILED_PATH ?

<jralls>OK. The first time, it reported

<jralls>;;; WARNING: compilation of /Users/john/Gnucash.app/Contents/Resources/share/guile/2.0/system/vm/objcode.scm failed:

<jralls>;;; ERROR: no such language objcode

<jralls>but kept going.

<jralls>I'm summoned for dinner, so I'll have to lay off until tomorrow. G'night.

<mark_weaver>okay, g'night!

<cky>jralls: I don't know about GnuCash, but I do have a fully-working version of Guile (stable-2.0) that passes all tests on Yosemite.

<cky>I haven't "make install"ed yet (and won't, until I track down the TLS (thread-local storage, not transport layer security :-)) issue with clang and have my patch be integrated into stable-2.0), but meta/guile works well for me and I use it frequently.

<tadni_>Howdy, slucx.

<tadni_>cky: 2.0 or 2.x?

<tadni_>ZombieChicken: It's a PoultryGeist!

<ZombieChicken>you are one clucky amatuer to make such a pun

<ZombieChicken>Is there a library for parsing YAML for guile?

<tadni_>I think it was a nice little nugget.

<tadni_>Um, not sure really. If so, it's not anywhere obvious that I can find immediately.

<tadni_>I know Racket has decent YAML manipulation.

<ZombieChicken>I havn't made up my mind if I'm going to use YAML, XML, or just make my own markup

<ZombieChicken>I'm not doing anything that complicated

<tadni_>ZombieChicken: What's the project, in short?

<ZombieChicken>desktop wiki

<ZombieChicken>mostly a note program

<tadni_>ZombieChicken: You could probably bugger around with Skribilo then.

<tadni_>Just have a GUI write to Skribilo and too, that can be used to generate other files.

<tadni_>civodul: o/

<civodul>Hello Guilers!

<ZombieChicken>I'm about 90% sure I'll just make something up myself at this point. I'm not planning on doing anything overly complicated (mostly just storing a taglist, modification time, and maybe the page name)

<tadni_>ZombieChicken: Ah, okay.

<ZombieChicken>one thing I'm aiming for it to have a file format that is pretty much painless to modify without the frontend

<tadni_>ZombieChicken: I mean, org-mode. :^P

<ZombieChicken>except I despite emacs more than I do Unity and Windows 8

<tadni_>We were kinda talking about this a little earlier in #emacs, how it's a shame that org-mode really isn't that portable though.

<tadni_>ZombieChicken: Emacs is kinda irrelevant for org-mode, besides it being a transport vehicle for it.

<ZombieChicken>I recall digging into org-mode once before and not seeing anything that is really interesting in it

<tadni_>It's nested in nature is one big one.

<tadni_>Which is especially useful if one is wanting to do a structured document like a week.

<tadni_>wiki*

<ZombieChicken>except I'd have to use emacs to work with it

<ZombieChicken>Get me a version of it that doesn't require emacs to interact with, and I'll give it a shot

<tadni_>ZombieChicken: Yeah, that's why I'm saying it's a bummer that Emacs isn't slimmed down for it.

<ZombieChicken>There are a few things they got right with emacs

<ZombieChicken>sadly, the UI wasn't part of it

<tadni_>Nah, UI is one of my favorite bits.

<tadni_>Keybindings probably needs a little work.

<ZombieChicken>Way close to the bottom of my TODO list is to write my own editor

<ZombieChicken>I'm a fan of modal editing

<ZombieChicken>I think half the problem with the keybindings is that emacs was written for a keyboard that no longer exist

<tadni_>On non-qwerty the bindings are really not that bad.

<ijp>the keybindings aren't based on position, but mnemonic

<tadni_>I've used both Dvorak and Colemak, and it's a much nicer experience.

<ZombieChicken>ijp: which is why I've never been able to remember they keybinding to exit, right?

<ijp>why would you ever leave?

<tadni_>ijp: Well yeah, which is preferable I think. Vim falls apart, when you're not using Qwerty or using some special mod.

<tadni_>ZombieChicken: C-x C-c.

<ijp>by making it hard to remember, emacs is leading you down the right path :)

<tadni_>Most global bindings, do make a lot of sense.

<ZombieChicken>I'd rather use ed

<tadni_>Mode-specific, is hit and miss.

<ijp>anyway, I can't think of a less interesting way to spend a sunday morning, so ...

<tadni_>ijp: Doing backflips?

<ZombieChicken>ijp: you could download and try out Inferno

<ijp>tadni_: nah, that's really fun

<tadni_>ijp: Not when you just fall over.

<ijp>so don't fall over

<tadni_>I've never been able to convience my body to do any kind of flip.

<ijp>it's not your body you have to convince, it's your mind

<tadni_>ijp: It's both.

<tadni_>Is Skribilo being actively developed anymore?

<ijp>stilts are fun too

<tadni_>One commit this year, and it was a very minor one to get it working with Emacs 24.4

<civodul>tadni_: it's not very active, indeed :-)

<civodul>but feel free to chime in

<tadni_>civodul: I'm certainly interested in Skribilo , so I might poke around eventually there.

<tadni_>That one-l thing in the name is driving me nuts, though. I always defualt to Skribillo.

<civodul>:-)

<tadni_>So Skribilo is based on Skribe, via actual code or just in spirit?

<tadni_>Yeah, it looks to be based on Skribe directly from how I read it.

<civodul>yes, via actual code

<civodul>it started as a "port" of Skribe to Guile

*tadni_ is kinda shocked he hasn't seen more similar projects in the Lisp world of stuff like this.

<tadni_>Okay, it's about 6am -- need to get 2-3 hours of sleep. o/

IRC channel logs

2014-12-21.log