How does install-lib know all the correct auxiliary libs to copy into
Like src/STUBS/libmpi_stubs.so or lib/atc/libatc.so ? Or your libfftw.so
or libjpeg.so if you installed them locally, and they are thus not
already in your LD_LIBRARY_PATH?
steve, why did you make .so files out of all those libraries?
why not just add -fPIC to the compilation flags and you can
use the .a files for both cases, the regular lammps executable
and the shared object. *much* less headache and less files
to keep track of.
there is a little fun to be had to make the cuda compiler
accept -fPIC, but that is a different story.
And sudo has its own problems,
esp if you have multiple Pythons installed (is root's Python the
same as yours?, where is that hidden site-package directory anyway?).
installing libraries that are not controlled by a package manager
into a system location is a *very* bad idea. as is the "sudo-prefixing".
i could go into an endless rant about how bad this is...
OK, go ahead and push back - I don't think editing env variables is ideal
either, but it is a one-time task, requires no root, is conceptually
simple to get right,
and doesn't touch Python itself.
Any other Python + LAMMPS users out there who want to weigh in?
Axel must have an opinion ...
yeah, i am not a big fan of environment variables either.
in a shared environment, using environment modules,
this is the way to go, but for personal installations
i prefer encoding the search path into the shared object
this actually allows me to have multiple concurrent
versions of different packages installed and have
executables "magically" pick up the right path.
as for non-root installs. i thought that the build tools
of recent python versions would automatically handle
this by having a "shadow" tree for site-packages in
the user's home directory, e.g. for python 2.7 in:
p.s.: i *rarely* use python, so it is quite amusing that
lammps is now the second project (after VMD), where
people as me for my view on how to do python stuff.