coot
coot copied to clipboard
pemsley
Official Debian package
There's the intent to package at https://bugs.debian.org/897673 and the current public state: https://salsa.debian.org/science-team/coot and then there's some success on a local machine that builds 1.1.07 and if software builds successfully, it's likely to also work and be packagable... (Using this place to keep track of the history of building the package)
correction: almost success
[100%] Linking CXX executable test-molecules-container
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssm.so: undefined reference to `mmdb::Atom::Transform(double (&) [4][4])'
/usr/bin/ld: /usr/lib/x86_64-linux-gnu/libssm.so: undefined reference to `mmdb::Mat4Copy(double (&) [4][4], double (&) [4][4])'
collect2: error: ld returned 1 exit status
Just to see where we are: https://repology.org/project/coot/versions (comparisons are bad, Paul Watzlawik, Situation is Hopeless, But Not Serious, The Pursuit of Unhappiness)
Hello @alexmyczko. I was unware of this effort - or had forgotten about it. I would like this to be a thing and am happy to put some hours in to help make it happen. I have seen the linking error you mention above some years ago. I don't recall at the moment how to fix it. I will have a look and a think.
So, it looks like you are using CMake to build the project. Is that the case?
The CMake system (at the moment only) builds up to libcootapi and chapi (the nanobind-based python coot_headless_api). To build the Coot binary and Layla you will need to use configure (at the moment).
You may find build-it-3-3 useful.
Which version of mmdb (and clipper) are you using/linking against?
What does CMakeCache.txt say about MMDB?
Can you compile with VERBOSE=1 ?
Interesting news.
which is due to be installed in the Debian FTP archive
What is the timescale for this? Hours or months?
Yes, RDKit is now a hard dependency.
With the move to GTK4 (in Coot 1.1) the dependency on a canvas has been removed.
Is there a way to check for lack of copyright assignment?
It was like sub-hour, package already fixed in sid, webpage outdated, i got it from incoming.debian.org and building to test... thanks for clarifying it is a hard dependency.
I usually postpone the really hard things like debian/copyright. first it builds, then it works, and so on...
BUT let me assure you, there's interest from many sides, and I am now equipped with a new vortex m0110 keyboard which encourages me to type alot ;)
At the moment nothing, I had problems building rdkit src deb pkg, but now it's built installing it from the archive (sid, amd64) and continuing trying, this is very appreciated your help. No worries, I sure will have questions...
99% of the problems of installing Coot is installing the dependencies.
Which version of GTK4 are you going to use?
here's the cmake . output
cmake .
CMake Warning (dev) at CMakeLists.txt:2 (project):
cmake_minimum_required() should be called prior to this top-level project()
call. Please see the cmake-commands(7) manual for usage documentation of
both commands.
This warning is for project developers. Use -Wno-dev to suppress it.
-- Looking for mmdb2/mmdb_defs.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libmmdb2.so
-- Looking for ssm/ssm_vxedge.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libssm.so
-- Looking for clipper/clipper.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-core.so
-- FFTW2 libraries - /usr/lib/libsfftw.so
-- - /usr/lib/libsrfftw.so
-- FFTW2 header directory - /usr/include
-- Looking for clipper/clipper-mmdb.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-mmdb.so
-- Looking for clipper/clipper-ccp4.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so
-- Looking for clipper/clipper-contrib.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-contrib.so
-- Looking for clipper/clipper-minimol.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-minimol.so
-- Looking for clipper/clipper-cif.h - /usr/include
-- Found CCP4: /usr/lib/x86_64-linux-gnu/libclipper-cif.so
-- CCP4 include directory: /usr/include
-- Found gemmi version 0.6.4
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found suitable version "1.83.0", minimum required is "1.83.0")
-- Found Boost: /usr/lib/x86_64-linux-gnu/cmake/Boost-1.83.0/BoostConfig.cmake (found version "1.83.0") found components: iostreams system python regex thread serialization
-- Configuring done (0.6s)
-- Generating done (0.5s)
-- Build files have been written to: /var/www/debian/coot/2024/coot-Release-1.1.07
GTK4 looks like:
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# dpkg -l |grep gtk4
ii gir1.2-xdpgtk4-1.0:amd64 0.7.1-5 amd64 Flatpak portal library - introspection data for GTK 4
ii libportal-gtk4-1:amd64 0.7.1-5 amd64 Flatpak portal library for GTK 4 GUIs
ii libportal-gtk4-dev:amd64 0.7.1-5 amd64 Flatpak portal library (development files for GTK 4)
ii libvte-2.91-gtk4-0:amd64 0.75.91-2 amd64 Terminal emulator widget for GTK 4 - runtime files
ii libvte-2.91-gtk4-dev:amd64 0.75.91-2 amd64 Terminal emulator widget for GTK 4 - development files
ii python3-wxgtk4.0 4.2.1+dfsg-3 amd64 Python 3 interface to the wxWidgets Cross-platform C++ GUI toolkit
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# dpkg -l |grep gtk-4
ii gir1.2-gtk-4.0:amd64 4.12.5+ds-3 amd64 GTK graphical user interface library -- gir bindings
ii gir1.2-javascriptcoregtk-4.0:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - GObject introspection data
ii gir1.2-javascriptcoregtk-4.1:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - GObject introspection data
ii libgtk-4-1:amd64 4.12.5+ds-3 amd64 GTK graphical user interface library
ii libgtk-4-bin 4.12.5+ds-3 amd64 programs for the GTK graphical user interface library
ii libgtk-4-common 4.12.5+ds-3 all common files for the GTK graphical user interface library
ii libgtk-4-dev:amd64 4.12.5+ds-3 amd64 development files for the GTK library
ii libgtk-4-media-gstreamer 4.12.5+ds-3 amd64 GStreamer media backend for the GTK graphical user interface library
ii libjavascriptcoregtk-4.0-18:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK
ii libjavascriptcoregtk-4.0-dev:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - development files
ii libjavascriptcoregtk-4.1-0:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK
ii libjavascriptcoregtk-4.1-dev:amd64 2.42.5-1 amd64 JavaScript engine library from WebKitGTK - development files
ii libswt-gtk-4-java 4.26.0-2 amd64 Standard Widget Toolkit for GTK+ Java library
ii libswt-gtk-4-jni 4.26.0-2 amd64 Standard Widget Toolkit for GTK+ JNI library
ii libwebkit2gtk-4.0-37:amd64 2.42.5-1 amd64 Web content engine library for GTK
ii libwebkit2gtk-4.0-dev:amd64 2.42.5-1 amd64 Web content engine library for GTK - development files
ii libwebkit2gtk-4.1-0:amd64 2.42.5-1 amd64 Web content engine library for GTK
ii libwebkit2gtk-4.1-dev:amd64 2.42.5-1 amd64 Web content engine library for GTK - development files
I have lead you astray, it seems.
The CMake build system builds (only) libcootapi and chapi - which are fine things to have but they are not coot.
Use configure to build coot. Read build-it-3-3 to see how I use coot's
configure
so i'll need configure AND cmake, or configure also builds libcootapi/chapi?
so i'll need configure AND cmake, or configure also builds libcootapi/chapi?
Ask me that now and I will say "Yes, both." They should build different libraries and not step on each other's toes.
This answer may change in the future as I get to like and understand CMake more.
You will also build Layla - which is a useful stand-alone chemisry application.
that's fine, i've seen projects that have much worse build systems or well lacking them completey :)
FWIW, libcootapi is the core library behind Moorhen (https://moorhen.org)
https://github.com/moorhen-coot/Moorhen
ok the cmake part looks good
[100%] Linking CXX executable test-molecules-container
/usr/bin/cmake -E cmake_link_script CMakeFiles/test-molecules-container.dir/link.txt --verbose=1
/usr/bin/c++ -O3 -DNDEBUG "CMakeFiles/test-molecules-container.dir/api/test_molecules_container.cc.o" "CMakeFiles/test-molecules-container.dir/api/filo-tests.cc.o" -o test-molecules-container -Wl,-rpath,/var/www/debian/coot/2024/coot-Release-1.1.07 libcootapi.so /usr/lib/x86_64-linux-gnu/libssm.so /usr/lib/x86_64-linux-gnu/libclipper-minimol.so /usr/lib/x86_64-linux-gnu/libclipper-mmdb.so /usr/lib/x86_64-linux-gnu/libclipper-cif.so /usr/lib/x86_64-linux-gnu/libclipper-core.so /usr/lib/x86_64-linux-gnu/libclipper-ccp4.so /usr/lib/x86_64-linux-gnu/libclipper-contrib.so /usr/lib/libsfftw.so /usr/lib/libsrfftw.so /usr/lib/x86_64-linux-gnu/libmmdb2.so /usr/lib/x86_64-linux-gnu/libz.so /usr/lib/x86_64-linux-gnu/libgsl.so /usr/lib/x86_64-linux-gnu/libgslcblas.so /usr/lib/x86_64-linux-gnu/libpng.so /usr/lib/x86_64-linux-gnu/libboost_iostreams.so.1.83.0 /usr/lib/x86_64-linux-gnu/libboost_system.so.1.83.0
make[2]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07'
[100%] Built target test-molecules-container
make[1]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07'
/usr/bin/cmake -E cmake_progress_start /var/www/debian/coot/2024/coot-Release-1.1.07/CMakeFiles 0
so on to configure, aha no configure, let me guess which parts of this i need (witout reading the manual)
libtoolize --force
aclocal
autoheader
automake --force-missing --add-missing
autoconf
./configure
i have a note about autoreconf -vif but i don't remember why...
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# libtoolize --force
libtoolize: putting auxiliary files in '.'.
libtoolize: linking file './ltmain.sh'
libtoolize: putting macros in AC_CONFIG_MACRO_DIRS, 'macros'.
libtoolize: linking file 'macros/libtool.m4'
libtoolize: linking file 'macros/ltoptions.m4'
libtoolize: linking file 'macros/ltsugar.m4'
libtoolize: linking file 'macros/ltversion.m4'
libtoolize: linking file 'macros/lt~obsolete.m4'
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# aclocal
configure.ac:35: warning: macro 'AM_ACLOCAL_INCLUDE' not found in library
configure.ac:112: warning: macro 'AM_MINGW_WINDOWS' not found in library
configure.ac:115: warning: macro 'AM_PATH_GLOB' not found in library
configure.ac:133: warning: macro 'AM_PATH_SQLITE3' not found in library
configure.ac:184: warning: macro 'AM_PATH_MMDB2' not found in library
configure.ac:186: warning: macro 'AM_WITH_SSM' not found in library
configure.ac:191: warning: macro 'AM_SINGLE_FFTW2' not found in library
configure.ac:195: warning: macro 'AM_PATH_CLIPPER' not found in library
configure.ac:411: warning: macro 'AM_COOT_SYS_BUILD_TYPE' not found in library
configure.ac:433: warning: macro 'AM_WITH_MYSQL_DATABASE' not found in library
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# autoheader
autoheader: warning: WARNING: Using auxiliary files such as 'acconfig.h', 'config.h.bot'
autoheader: WARNING: and 'config.h.top', to define templates for 'config.h.in'
autoheader: WARNING: is deprecated and discouraged.
autoheader:
autoheader: WARNING: Using the third argument of 'AC_DEFINE_UNQUOTED' and
autoheader: WARNING: 'AC_DEFINE' allows one to define a template without
autoheader: WARNING: 'acconfig.h':
autoheader:
autoheader: WARNING: AC_DEFINE([NEED_FUNC_MAIN], 1,
autoheader: [Define if a function 'main' is needed.])
autoheader:
autoheader: WARNING: More sophisticated templates can also be produced, see the
autoheader: WARNING: documentation.
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
autoheader: error: error: AC_CONFIG_HEADERS not found in configure.ac
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# automake --force-missing --add-missing
configure.ac:42: installing './compile'
configure.ac:32: installing './missing'
MoleculesToTriangles/CXXClasses/Makefile.am: installing './depcomp'
api/Makefile.am:89: installing './py-compile'
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# autoconf
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
fatal: not a git repository (or any parent up to mount point /var/www)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
root@phd-sid:/var/www/debian/coot/2024/coot-Release-1.1.07# ./configure
checking for a BSD-compatible install... /usr/bin/install -c
checking whether build environment is sane... yes
checking for a race-free mkdir -p... /usr/bin/mkdir -p
checking for gawk... gawk
checking whether make sets $(MAKE)... yes
checking whether make supports nested variables... yes
checking for g++... g++
checking whether the C++ compiler works... yes
checking for C++ compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C++... yes
checking whether g++ accepts -g... yes
checking for g++ option to enable C++11 features... none needed
checking whether make supports the include directive... yes (GNU style)
checking dependency style of g++... gcc3
checking build system type... x86_64-pc-linux-gnu
checking host system type... x86_64-pc-linux-gnu
checking how to print strings... printf
checking for gcc... gcc
checking whether the compiler supports GNU C... yes
checking whether gcc accepts -g... yes
checking for gcc option to enable C11 features... none needed
checking whether gcc understands -c and -o together... yes
checking dependency style of gcc... gcc3
checking for a sed that does not truncate output... /usr/bin/sed
checking for grep that handles long lines and -e... /usr/bin/grep
checking for egrep... /usr/bin/grep -E
checking for fgrep... /usr/bin/grep -F
checking for ld used by gcc... /usr/bin/ld
checking if the linker (/usr/bin/ld) is GNU ld... yes
checking for BSD- or MS-compatible name lister (nm)... /usr/bin/nm -B
checking the name lister (/usr/bin/nm -B) interface... BSD nm
checking whether ln -s works... yes
checking the maximum length of command line arguments... 1572864
checking how to convert x86_64-pc-linux-gnu file names to x86_64-pc-linux-gnu format... func_convert_file_noop
checking how to convert x86_64-pc-linux-gnu file names to toolchain format... func_convert_file_noop
checking for /usr/bin/ld option to reload object files... -r
checking for file... file
checking for objdump... objdump
checking how to recognize dependent libraries... pass_all
checking for dlltool... no
checking how to associate runtime and link libraries... printf %s\n
checking for ar... ar
checking for archiver @FILE support... @
checking for strip... strip
checking for ranlib... ranlib
checking command to parse /usr/bin/nm -B output from gcc object... ok
checking for sysroot... no
checking for a working dd... /usr/bin/dd
checking how to truncate binary pipes... /usr/bin/dd bs=4096 count=1
checking for mt... mt
checking if mt is a manifest tool... no
checking for stdio.h... yes
checking for stdlib.h... yes
checking for string.h... yes
checking for inttypes.h... yes
checking for stdint.h... yes
checking for strings.h... yes
checking for sys/stat.h... yes
checking for sys/types.h... yes
checking for unistd.h... yes
checking for dlfcn.h... yes
checking for objdir... .libs
checking if gcc supports -fno-rtti -fno-exceptions... no
checking for gcc option to produce PIC... -fPIC -DPIC
checking if gcc PIC flag -fPIC -DPIC works... yes
checking if gcc static flag -static works... yes
checking if gcc supports -c -o file.o... yes
checking if gcc supports -c -o file.o... (cached) yes
checking whether the gcc linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking whether -lc should be explicitly linked in... no
checking dynamic linker characteristics... GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking whether stripping libraries is possible... yes
checking if libtool supports shared libraries... yes
checking whether to build shared libraries... yes
checking whether to build static libraries... yes
checking how to run the C++ preprocessor... g++ -E
checking for ld used by g++... /usr/bin/ld -m elf_x86_64
checking if the linker (/usr/bin/ld -m elf_x86_64) is GNU ld... yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking for g++ option to produce PIC... -fPIC -DPIC
checking if g++ PIC flag -fPIC -DPIC works... yes
checking if g++ static flag -static works... yes
checking if g++ supports -c -o file.o... yes
checking if g++ supports -c -o file.o... (cached) yes
checking whether the g++ linker (/usr/bin/ld -m elf_x86_64) supports shared libraries... yes
checking dynamic linker characteristics... (cached) GNU/Linux ld.so
checking how to hardcode library paths into programs... immediate
checking which libtool initialization strategy to adopt... AC-PROG-LIBTOOL
checking what warning flags to pass to the C compiler... -Wall -Wunused
checking what language compliance flags to pass to the C compiler...
checking what warning flags to pass to the C++ compiler... -Wall -Wno-unused
checking what language compliance flags to pass to the C++ compiler...
checking for sys/stdtypes.h... no
checking for OpenMP flag of C compiler... -fopenmp
checking whether g++ supports C++11 features by default... yes
checking for std::thread in thread... yes
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... yes
checking for glib-2.0... yes
checking if this is MINGW on Windows... no
checking if this is msys2 windows 64... no
checking for libpng >= 1.2... yes
checking for cairo >= 1.14... yes
checking for SQLite3... yes
checking for mmdb2... yes
checking for ssm... yes
checking for non-prefixed single-precision FFTW2 (fftw.h)... no
yes
checking for Clipper... yes
checking for gsl-config... /usr/bin/gsl-config
checking for GSL - version >= 1.3... yes
checking for glm >= 0.9.9... yes
checking for gtk4 >= 4.4... yes
checking for epoxy >= 1.5... yes
checking for a Python interpreter with version >= 3.7... python3
checking for python3... /usr/bin/python3
checking for python3 version... 3.11
checking for python3 platform... linux
checking for python3 script directory... ${prefix}/lib/python3/dist-packages
checking for python3 extension module directory... ${exec_prefix}/lib/python3/dist-packages
checking for python3.11... (cached) /usr/bin/python3
checking for a version of Python >= '2.1.0'... yes
checking for the distutils Python package... yes
checking for Python include path... -I/usr/include/python3.11
checking for Python library path... -L/usr/lib/x86_64-linux-gnu -lpython3.11
checking for Python site-packages path... /usr/lib/python3/dist-packages
checking python extra libraries... -ldl -lm
checking python extra linking flags... -Xlinker -export-dynamic -Wl,-O1 -Wl,-Bsymbolic-functions
checking consistency of all components of python development environment... yes
checking python3 module: requests... yes
checking for pygobject-3.0 >= 3.36... yes
checking for boostlib >= (102000)... yes
checking whether the Boost::Thread library is available... yes
checking for exit in -lboost_thread... yes
checking whether the Boost::Python library is available... yes
checking whether boost_python is the correct library... no
checking whether boost_python311 is the correct library... yes
checking for RDKit in NONE
Configuration error. No, bad... we do not have necessary RDKIT
aclocal -I macros
You can take a look at autogen.sh - that was written presuming that the dependencies are installed in the user's directories (by the build script). You are at about line 4544 of the build-it-3-3
If you prefer, you can build from a tarball release:
https://www2.mrc-lmb.cam.ac.uk/personal/pemsley/coot/source/releases/coot-1.1.07.tar.gz
i do have the tarball release (ah but selfmade git checkout without configure, now i get it), i guess i'll help it find rdkit:
# grep -i rdkit configure
RDKIT_LIBS
RDKIT_CXXFLAGS
with_rdkit_prefix
--with-rdkit-prefix location of the RDKit package
# Boost-Python is needed for RDKit interface.
# Check whether --with-rdkit-prefix was given.
if test ${with_rdkit_prefix+y}
withval=$with_rdkit_prefix; rdkit_prefix="$withval"
rdkit_prefix=false
if test x$rdkit_prefix = xfalse ; then
echo checking for RDKit in $prefix
if test -x $prefix/include/rdkit ; then
echo OK, good we found RDKit in $prefix
rdkit_install_dir=$prefix
RDKIT_CXXFLAGS="-I$rdkit_install_dir/include/rdkit -DRDKIT_HAS_CAIRO_SUPPORT"
RDKIT_LIBS="-L$rdkit_install_dir/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitcoordgen -lRDKitMolChemicalFeatures -lRDKitPartialCharges -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitRingDecomposerLib -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -l$BOOST_PYTHON_LIB $pl"
echo Configuration error. No, bad... we do not have necessary RDKIT
rdkit_install_dir="$withval"
# better RDKit linking I hope
RDKIT_CXXFLAGS="-I$rdkit_install_dir/include/rdkit -DRDKIT_HAS_CAIRO_SUPPORT"
RDKIT_LIBS="-L$rdkit_install_dir/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitcoordgen -lRDKitMolChemicalFeatures -lRDKitPartialCharges -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitRingDecomposerLib -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -l$BOOST_PYTHON_LIB $pl"
configure was successfull with just --with-rdkit-prefix= so waiting for make
--with-rdkit-prefix=$install_top_dir where $install_top_dir is /usr I guess
/usr/bin/ld: cannot find -lRDKitcoordgen: No such file or directory
/usr/bin/ld: cannot find -lRDKitRingDecomposerLib: No such file or directory
hm they don't come with
$ dpkg -L librdkit1
<alot>
$ dpkg -L librdkit1|grep RDKitcoordgen
$ dpkg -L librdkit1|grep RDKitRingDec
<allempty>
Looking into https://salsa.debian.org/debichem-team/rdkit/-/blob/master/debian/rules?ref_type=heads
Coordgen is a Schrödinger library.
https://github.com/schrodinger/coordgenlibs
I guess if it is not installed then the RDKit can't make a wrapper library.
You could try removing RDKitcoordgen and RDKitRingDecomposerLib from configure.ac
Coot doesn't directly use functions from either library.
this would not do it?
sed -i s,-lRDKitcoordgen,,g configure
sed -i s,-lRDKitRingDecomposerLib,,g configure
ended with:
libtool: link: g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crti.o /usr/lib/gcc/x86_64-linux-gnu/13/crtbeginS.o .libs/layla_embedded.o .libs/generators.o .libs/notifier.o .libs/signals.o .libs/state.o .libs/ui.o .libs/utils.o ligand_editor_canvas/.libs/core.o .libs/ligand_editor_canvas.o ligand_editor_canvas/.libs/model.o ligand_editor_canvas/.libs/tools.o ligand_editor_canvas/.libs/render.o .libs/python_utils.o -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/geometry/.libs -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/lidia-core/.libs -Wl,-rpath -Wl,/var/www/debian/coot/2024/coot-Release-1.1.07/utils/.libs ../geometry/.libs/libcoot-geometry.so ../lidia-core/.libs/libcoot-lidia-core.so ../utils/.libs/libcoot-utils.so -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -L/usr/lib -lRDKitMolDraw2D -lRDKitForceFieldHelpers -lRDKitDescriptors -lRDKitForceField -lRDKitSubstructMatch -lRDKitOptimizer -lRDKitDistGeomHelpers -lRDKitDistGeometry -lRDKitChemReactions -lRDKitAlignment -lRDKitEigenSolvers -lRDKitDepictor -lRDKitMolChemicalFeatures -lRDKitFileParsers -lRDKitRDGeometryLib -lRDKitGraphMol -lRDKitShapeHelpers -lRDKitFingerprints -lRDKitMolAlign -lRDKitMolTransforms -lRDKitChemTransforms -lRDKitSmilesParse -lRDKitGenericGroups -lRDKitFilterCatalog -lRDKitCatalogs -lRDKitSubgraphs -lRDKitPartialCharges -lRDKitRDGeneral -lRDKitDataStructs -lboost_serialization -lboost_iostreams -lboost_python311 -L/usr/lib/x86_64-linux-gnu -lpython3.11 -lcurl -lpthread -L/usr/lib/gcc/x86_64-linux-gnu/13 -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu -L/usr/lib/gcc/x86_64-linux-gnu/13/../../../../lib -L/lib/x86_64-linux-gnu -L/lib/../lib -L/usr/lib/../lib -L/usr/lib/gcc/x86_64-linux-gnu/13/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-linux-gnu/13/crtendS.o /usr/lib/gcc/x86_64-linux-gnu/13/../../../x86_64-linux-gnu/crtn.o -g -O2 -Wl,-soname -Wl,libcoot-layla.so.0 -o .libs/libcoot-layla.so.0.0.0
libtool: link: (cd ".libs" && rm -f "libcoot-layla.so.0" && ln -s "libcoot-layla.so.0.0.0" "libcoot-layla.so.0")
libtool: link: (cd ".libs" && rm -f "libcoot-layla.so" && ln -s "libcoot-layla.so.0.0.0" "libcoot-layla.so")
libtool: link: ar cr .libs/libcoot-layla.a layla_embedded.o generators.o notifier.o signals.o state.o ui.o utils.o ligand_editor_canvas/core.o ligand_editor_canvas.o ligand_editor_canvas/model.o ligand_editor_canvas/tools.o ligand_editor_canvas/render.o python_utils.o
libtool: link: ranlib .libs/libcoot-layla.a
libtool: link: ( cd ".libs" && rm -f "libcoot-layla.la" && ln -s "../libcoot-layla.la" "libcoot-layla.la" )
/bin/bash ../libtool --tag=CXX --mode=link g++ -DPKGDATADIR='"/usr/local/share/coot"' -DUSE_SQLITE3 -lcurl -DUSE_LIBPNG=1 -I/usr/include/libpng16 -g -O2 -Wall -Wno-unused -std=c++17 -o layla main.o libcoot-layla.la ../utils/libcoot-utils.la -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0 -lglib-2.0
libtool: link: g++ -DPKGDATADIR=\"/usr/local/share/coot\" -DUSE_SQLITE3 -DUSE_LIBPNG=1 -I/usr/include/libpng16 -g -O2 -Wall -Wno-unused -std=c++17 -o .libs/layla main.o -lcurl ./.libs/libcoot-layla.so ../utils/.libs/libcoot-utils.so -lgtk-4 -lpangocairo-1.0 -lpango-1.0 -lharfbuzz -lgdk_pixbuf-2.0 -lcairo-gobject -lcairo -lgraphene-1.0 -lgio-2.0 -lgobject-2.0 -lglib-2.0
/usr/bin/ld: ./.libs/libcoot-layla.so: undefined reference to `coot::rdkit_mol(coot::dictionary_residue_restraints_t const&)'
collect2: error: ld returned 1 exit status
make[1]: *** [Makefile:684: layla] Error 1
make[1]: Leaving directory '/var/www/debian/coot/2024/coot-Release-1.1.07/layla'
make: *** [Makefile:745: all-recursive] Error 1
need make VERBOSE=1?
This looks like a source-code bug.
Layla uses rdkit. Check the use of the #define USE_RDKIT - coot::rdkit_mol() should have been added to libcoot-lidia-core and libcoot-lidia-core should have been linked into libcoot-layla.
I have to go to work now - hiatus.
@hgonomeg do you have thoughts about this?
I thought that the libraries with which a target is linked should be specified on the command line after the target. This seems to specify libcoot-lidia-core.so before -o libcoot-layla.so
@alexmyczko
What does this say?
nm --demangle lidia-core/.libs/libcoot-lidia-core.so | grep rdkit_mol
Very happy to see this development! I have attempted to build a Debian package for coot some years ago, with varying level of success, but did not follow through the whole process.
I am puzzled to see RDKitcoordgen and RDKitRingDecomposerLib, RDKit does not seem to have them in Debian. Most likely this is due to version difference, Debian has RDKit 202309.3.
I recall I had to patch lbg/Makefile.am to get rid of undefined reference messages:
--- a/lbg/Makefile.am
+++ b/lbg/Makefile.am
@@ -80,7 +80,7 @@
# (if that is annoying, then remove it and expand it by hand)
#
lidia_LDADD = \
- ./libcoot-lidia.la $(GLOB_LIBS) $(RDKIT_LIBS) $(L_BOOST_PYTHON)
+ ./libcoot-lidia.la ../lidia-core/.libs/libcoot-lidia-core.la $(GLOB_LIBS) $(RDKIT_LIBS) $(MMDB_LIBS) $(GTK_LIBS) $(PYTHON_LIBS) $(L_BOOST_PYTHON)
# not needed: linked by dependency libs
# $(CLIPPER_LIBS) $(MMDB_LIBS) $(GSL_LIBS)
@alexmyczko have you pushed your packaging attempt somewhere? I would like to give it a shot.
@merkys the current stuff is at http://sid.ethz.ch/debian/coot/2024/ and without debian/ it's just building manually from source, once this is successfull, i can start/continue what's on salsa and put it on salsa...
If IRC is easier for you, i'm there as tarzeau (or tarzeau_)