I've checked out the most recent theano snapshot and have tried to run
the nosetests, however I notice that it isn't finding my (custom-
built) ATLAS libraries in an odd location (/opt/sw/ATLAS). Setting
LD_LIBRARY_PATH, or LDFLAGS hasn't helped, and putting the relevant -L
in the blas.ldflags setting in .theanorc only yields an error message
about how that is not allowed (d'oh! ;).
Any hints on how to tell theano where to find ATLAS? I should note
that NumPy already knows where it is and uses it quite successfully.
Thanks,
David
The passing of -L flags to blas.ldflags is not implemented (yet).
I expect it to work for you if you add the /opt/sw/ATLAS to you
LD_LIBRARY_PATH, because in that case it should take the -l options
from numpy and compile correctly.
If that fails, please email the list because it's a bug (well... it's
basically already a bug that -L options are not allowed...). In that
case I would also be curious what happens when you add that directory
to LD_LIBRARY_PATH *and* add the small-l flags to blas.ldflags.
Sorry there are still some wrinkles around the libpaths with blas...
but your feedback would be appreciated.
Just a note: I may be wrong, but as far as I know gcc uses
LIBRARY_PATH to figure out where to find libraries (besides the -L
option), so that would be the place to add it for the link to work.
LD_LIBRARY_PATH is what is used at runtime.
--
Olivier
On Mar 12, 10:50 am, James Bergstra <james.bergs...@gmail.com> wrote:
>
> I expect it to work for you if you add the /opt/sw/ATLAS to you
> LD_LIBRARY_PATH, because in that case it should take the -l options
> from numpy and compile correctly.
>
> If that fails, please email the list because it's a bug (well... it's
> basically already a bug that -L options are not allowed...). In that
> case I would also be curious what happens when you add that directory
> to LD_LIBRARY_PATH *and* add the small-l flags to blas.ldflags.
Sadly that does seem to be the case. I still get the same errors. Is
it a problem that I only have the static libraries?
dwf@mirage:~$ ls /opt/sw/ATLAS/lib
libatlas.a libcblas.a libf77blas.a liblapack.a libptcblas.a
libptf77blas.a
> Sorry there are still some wrinkles around the libpaths with blas...
> but your feedback would be appreciated.
No problem, I'm happy to help straighten them out if I can.
David
A-ha. I'm a little shaky on that sort of stuff, but I think that
might be a problem.
Theano tries to compile and load those [dynamic] modules. Is that in
any way compatible with static libs?
On Mar 12, 11:29 am, Olivier Delalleau <olivier.delall...@gmail.com>
wrote:
Okay, so something is definitely different between using LIBRARY_PATH
and not using it, namely I just get 'E' in the nosetests output but it
doesn't spit out generated code like it does when I run it without
LIBRARY_PATH. Using LIBRARY_PATH I get errors like:
======================================================================
ERROR: test_size_changes
(theano.compile.tests.test_builders.T_OpFromGraph)
----------------------------------------------------------------------
...
...
ImportError: /home/dwf/.theano/compiledir_Linux-2.6.31-20-generic-
x86_64-with-Ubuntu-9.10-karmic-/tmpOvaDLu/
307958ac90fd17f9948dc4775cda0bcf.so: undefined symbol: ATL_dgemm
Without it,
I get
./usr/bin/ld: cannot find -latlas
collect2: ld returned 1 exit status
and the aforementioned code dump.
any ideas?
David
In your case, I'm suspicious of the static libs not being available to
the dlopen'd module.
There may be workarounds like using LD_PRELOAD, but I'm totally guessing.
On Fri, Mar 12, 2010 at 2:22 PM, David Warde-Farley <d...@cs.toronto.edu> wrote:
>
>
Yeah, it should be fine. The ATLAS routines should get linked in and
included in the object code of every dynamic library built against
them... I think.
I'll try recompiling ATLAS (I've been meaning to do that recently
anyway, to upgrade since we isolated a bug in ATLAS 3.9.17). I'll
build the dynamic versions too and see what I come up with.
David
Doesn't the static lib at least need to be compiled with PIC ?
> Doesn't the static lib at least need to be compiled with PIC ?
Yep, my ATLAS is compiled with -fPIC however.
David
So the first one is better because at least it found libatlas. But
there are undefined references which means you need to add some more -
lsomething on the command line. I'm not sure what you need but try to
add more libraries found in the ATLAS lib dir.
--
Olivier
> o the first one is better because at least it found libatlas. But
> there are undefined references which means you need to add some more -
> lsomething on the command line. I'm not sure what you need but try to
> add more libraries found in the ATLAS lib dir.
No luck with any combination of -lptcblas, -lptf77blas, -lcblas, -
lf77blas... I think I'll just try recompiling ATLAS dynamically.
David
Good luck on that :) It turns out I just had a similar issue (not
Theano-related) and I gave up with ATLAS, now trying to get it to link
with MKL....
--
Olivier
> In your case, I'm suspicious of the static libs not being available to
> the dlopen'd module.
For the record, building ATLAS with --dylibs solved it (combined with
your earlier suggestion of LIBRARY_PATH). Apparently theano doesn't
like linking against static ATLAS, for whatever reason. :)
Thanks,
David
> any thoughts from anyone on how to improve theano with this
> information?
> - print a warning at some point if some blas.ldflags token ends
> with .a ?
> - add something to the documentation about static libs?
Both!
> - do nothing and wait?
No!
-- Yoshua
> - print a warning at some point if some blas.ldflags token ends
> with .a ?
Only if the corresponding .so doesn't exist -- ATLAS will typically
build/include both unless you explicitly disable static libs.
David
Yep. Only after I implemented this did I realize that when you say
-latlas, the token has no info about static vs. dynamic. I added a
note to installation docs, but that's it.
Besides that, I think it'd be nice to have some test that ensure BLAS
is working properly. It seems like it is one major issue people are
facing when installing Theano (and it's typically one with PLearn
too ;)), because of the many different BLAS libraries floating around.
It would be cool if there was a test you could run which, on failure,
would hopefully give you some hints as to what may be not working
properly for you (this is wishful thinking since we are unlikely to
ever be able to cover all situations, but if we could get the most
common ones, that would be already quite helpful).
--
Olivier
Brilliant. Not a nose-test, but a little diagnostic program with
mailing-list-friendly output... I like the idea, and I think we
should consider one for the GPU too.
Besides that, I think it'd be nice to have some test that ensure BLAS
is working properly. It seems like it is one major issue people are
facing when installing Theano (and it's typically one with PLearn
too ;)), because of the many different BLAS libraries floating around.
It would be cool if there was a test you could run which, on failure,
would hopefully give you some hints as to what may be not working
properly for you (this is wishful thinking since we are unlikely to
ever be able to cover all situations, but if we could get the most
common ones, that would be already quite helpful).
Brilliant. Not a nose-test, but a little diagnostic program with
mailing-list-friendly output... I like the idea, and I think we
should consider one for the GPU too.
I have little experience with numpy stuff, but yes, it sounds like a
good idea to me if it works well. I just remember, a rather long time
ago, trying to install numpy with BLAS and eventually giving up,
installing it without it. Could have been my fault though, been a
while ;)
--
Olivier
> PS: Should we simply run whatever configuration tests numpy runs
> when it
> installs and make it mailing-list friendly?
The thing I usually ask people for on the NumPy/SciPy mailing list is
the output of numpy.show_config().
A theano.show_config() could spit out this plus theano specifics? :)
David