On Sat, May 04, 2019, viktor drobot wrote:
>
>For the sake of convenience I'm creating package with AmberTools
>software so it can be easily built everywhere. The problem is that some
>software inside AmberTools package hardcodes libraries inside final
>executables. For example, yesterday I noticed that ambpdb utility can't
>be run because of missing library (even after loading AmberTools
>modulefile which sets up proper LD_LIBRARY_PATH). ldd gives the
>following for this binary:
>
>[viktor.desolve-lab /opt/ambertools/bin]$ ldd ambpdb
> linux-vdso.so.1 (0x00007ffc33795000)
>/opt/buildcache/makepkg/ambertools/src/amber18/lib/libcpptraj.so => not
>found
Query, mainly for Dan: why don't we create a libcpptraj.a and link
ambpdb to that? That seems safest.
> ambpdb: $(AMBPDB_OBJECTS) $(LIBCPPTRAJ)
> .echo "[AMBPDB] CXX $."
>- $(VB)$(CXX) -o ambpdb$(SFX) $(AMBPDB_OBJECTS) $(LIBCPPTRAJ) $(LDFLAGS)
>+ $(VB)$(CXX) -o ambpdb$(SFX) $(AMBPDB_OBJECTS) $(LDFLAGS)
>-L"/home/viktor/build/src/amber18/lib" -lcpptraj
Above probably also works, but still involves shared libraries where
they are not needed.
>Also I can say that there are some other programs which hardcodes
>library names inside their binaries - makepkg checks if final package
>files include absolute paths to buildroot environment (in my case
>/opt/buildcache/makepkg) and throws a warning. I can list all cases if
>you need it.
Would help to see that. As you can tell, we have always assumed that
users would build Amber from source, and not try to move the
distribution afterwards. So portability has not been high on the list,
(and, in fact, the "-static" option doesn't completely work.)
>
>What can we do to workaround that bug?
Seems to me that you aleady have a workaround: am I missing something?
Thanks for the report....dac
_______________________________________________
AMBER mailing list
AMBER.ambermd.org
http://lists.ambermd.org/mailman/listinfo/amber
Received on Sat May 04 2019 - 19:30:02 PDT
