On 4/9/10 Apr 9 -1:31 PM, Mario S. Mommer wrote:
Hi,
what follows is, as far as I am concerned, an observation, and not a bug report. Maybe it is an interesting issue to keep in mind.
So I upgraded to the new asdf, and observed the following. When I load matlisp with the .asd attached, I get an error that goes like this
/usr/bin/ld: cannot open output file /home/mommer/.cache/common-lisp/sbcl-1.0.37-linux-x86-64/home/mommer/dev/matlisp/lib/libmatlisp.so: No such file or directory collect2: ld returned 1 exit status
The reason for the ld error is that that ^.*/lib/.* does not exist, and again the reason seems to be this: (slightly edited)
[...]
(defsystem :matlisp :components ((:unix-dso "alien code" :pathname "" :dso-name "lib/libmatlisp" ;; barf :components ((:alien-module "BLAS" :pathname "LAPACK/BLAS/SRC/" [...]
I presume one can defend the new asdf here, and I can fix it for me by removing the "lib/" as it does not matter one iota. But I also would expect this to come up again.
I would, too. But I guess I'm a little surprised that this worked before. ASDF-BINARY-LOCATIONS didn't necessarily play well with either data files (often found through use of *load-truename*) or foreign libraries. Such foreign libraries often were generated using make...
best, r