Hi Robert,
well, the 32/64 bit thing would indeed be a good addition to that .asd. Primarily, I wonder if this is a problem of the .asd or of asdf. I think it definately highlights an incompatibility between the old regime and the new one...
Let me try to cook up an example that does not die from portability issues.
Regards, Mario.
Robert Goldman rpgoldman@sift.info writes:
On 4/11/10 Apr 11 -12:45 PM, Mario S. Mommer wrote:
Hi Robert,
Robert Goldman rpgoldman@sift.info writes:
Do you think you could publish a version of this that is loadable on ACL?
The current version has sb-alien:: package hard-coded into the .asd file....
the only line wehere sb-alien is used is on line 102 of matlispbug.asd. If you comment out that line (and close parentheses appropriately) and it should "work" everywhere. Up to stuff in the actual files to be loaded.
Tried this, putting #+sbcl in front of the sb-alien call and #+allegro (load ...) in, since ACL docs say to load .so files with LOAD.
This crashes for me for a reason we discussed earlier --- ASDF tries to find the .so file in the cache created by asdf-output-translations, rather than where-ever it should be....
This may be my fault for using ACL/problem with the fortran compilation. With ACL, because of the punitive pricing on 64-bit versions, you can't count on the user having a 64-bit lisp on his/her 64-bit OS. So on ACL at least (possibly other lisps, as well?) need to ask the lisp if it's 32 or 64-bit and then compile the fortran accordingly. Is that right?
I'm old, but not old enough ever to have used fortran ;-)
r