freenode/#clasp - IRC Chatlog
Search
15:29:05
robink
drmeister: ...besides that fact that it was compiled from an ebuild and run as the usual user (me)?
15:29:34
robink
drmeister: I can try compiling w/o Portage in the mix to see if that behaves any differently.
15:32:52
drmeister
Do you have the output from the build that you can paste? I don't have much to go on.
15:34:22
drmeister
The build system runs cclasp a couple of times at the end to build asdf and serve-event libraries. I don't understand how they could build but you can't run cclasp.
15:36:06
robink
drmeister: I didn't get any build errors at the tail end, but I no longer have the build log.
15:36:40
robink
drmeister: I can rebuild using Portage (and the ebuild) and keep/upload the log, and/or I can compile it as me w/o a package management build framework and upload that log.
15:38:13
robink
drmeister: It doesn't; I assumed everything was compiled down to native code and linked in.
15:38:37
robink
drmeister: No no, if that's how Clasp is intended to be installed on OS X, I don't see why Linux should be different.
15:39:12
drmeister
Currently compilation to a single stand-alone executable is broken because of a bug in llvm.
15:44:20
drmeister
So that's the first thing. Currently, 'cclasp' is a symbolic link to iclasp-boehm - this is an executable compiled from just the clasp C++ code. When it starts up it looks for a fasl file that includes all of the compiled Common Lisp code.
15:45:16
drmeister
Regardless, when cclasp or iclasp-boehm starts up they still need other files to run.
15:46:04
robink
drmeister: No immediate rush, in the short term the most drastic thing I'd do would be tweak the build rules to have iclasp-cboehm to look elsewhere for the FASL file.
15:46:24
drmeister
They need a couple of bitcode files that they use to inline code and to link code.
15:46:54
drmeister
Right - so how does one inform an executable where to look for other files on linux?
15:47:18
robink
drmeister: Presumably in the source, or (depending on implementation) an environment variable?
15:47:57
drmeister
Ok - but when you install it - you will want to move those files around - won't you?
15:48:24
robink
drmeister: Oh, right. I get it. It's going to need to expect the FASL file in one location during build, and then (if it gets moved elsewhere) in another.
15:49:33
robink
drmeister: Erm, you could use LD_LIBRARY_PATH as a search path, and set it to include the build/boehm/fasl while compiling...
15:50:18
robink
drmeister: I mean technically if the FASL file is in a form that ld.so would have no clue what to do with...
15:50:29
robink
drmeister: You could have a FASL_PATH environment variable with one or two hard-coded search locations.
15:51:14
drmeister
I can change that - but I haven't moved in this direction because I don't know what the best way to do this is
15:52:29
robink
drmeister: Nor do I; I have some sense of "what's normal", and although it borders on uncommon, there are packages that'll stow a lot of non-ELF cruft in the various libdirs, so throwing an ELF in that Clasp uses natively isn't going to throw things off, I don't think.
15:52:33
drmeister
Ok, so that's an idea. Look through a list of standard lib directories for a clasp/** directory and use that ie: /usr/local/lib/clasp/** is that acceptable?
15:56:45
drmeister
Currently clasp crawls up from the executable's directory looking for 'clasp' and if it finds it - it uses that. That doesn't work when you move the executable to /usr/local/bin/cclasp
15:58:07
drmeister
On OS X, applications are stored in a bundle of files, along with their ancillary files - that is what I'm doing now. That is not the traditional Linux/Unix way.
15:59:17
robink
drmeister: Actually, the ebuild (since this is a package-manager-managed thing) is putting clasp in /usr/bin
16:00:23
robink
drmeister: I mean if you're *really* worried about something that isn't going to be linked into other packages by ld.so living in a libdir, there's always /usr(/local)/share.
16:01:57
robink
drmeister: but since this is a runtime library in ELF format, I cannot see any reason to put it anywhere but /usr/(local/)lib/clasp.
16:02:21
robink
drmeister: The ./clasp suffix to the libdir makes it clear it's probably most useful to Clasp.
16:02:41
drmeister
It's not just this file though - clasp needs bitcode files - there are also header files and source files that can be included.
16:03:03
drmeister
Also, this is not a standard library file - it's loaded with dlopen and not linked in with ld
16:03:46
robink
drmeister: Ah, shows you how familiar I am with LLVM's various representational formats.
16:04:43
robink
drmeister: OK, so maybe (if this isn't buried in the build system somewhere) a list of all the nessecary support files would be good.
16:17:10
drmeister
I think all it really needs are the files in here: clasp/Contents/Resources/lib/fasl/