On Samstag 05 Januar 2008, Sergey Plis wrote:
> You are right about custom library installation, but that's my only
> option at the machines I am working. Here is what strace gives me
> when included from the inside of bigforth (I've added tilde myself).
> Note that the library it finds is 32bit:
>
> open("/usr/local/lib/liblapack.so", O_RDONLY) = -1 ENOENT (No such
> file or directory)
> open("~/soft/lib/liblapack.so", O_RDONLY) = 6
> liblapack.so Library not found!
>
> Surprisingly, it does open the right library, but declares it not
> found.
>
> If I run
> strace -e open bigforth -e "include atlas.fs"
>
> Then there is no mention of opening liblapack.so, not even mention of
> liblapack at all. It just opens atlas.fs and that's it. Why?Ok, here's the explanation: bigForth library loading is treated differently, depending whether the variable WARNINGS is set to false (during startup) or true (in interactive mode). During startup, library bindings are "lazy", i.e. they are not resolved immediately, only if the library is actually used and calls are made. Therefore, no attempt is made to find the liblapack.so. This is done to improve load speed - the delay for loading the library is shifted to the time when you first access a function in that library. If you load it interactively, with WARNINGS on, bigForth no longer uses the lazy library loading, but tries to resolve all library stuff straight away, and thereby gives you a better report what's going on. Fact is that it can't load your liblapack.so, even if it finds it. One reason could be that there's a dependent library, which needs to be loaded before. Or that something went wrong when you created the liblapack.so library, and it's actually not a "good" dynamic library. -- Bernd Paysan "If you want it done right, you have to do it yourself" http://www.jwdt.com/~paysan/
signature.asc
Description: This is a digitally signed message part.
