Thanks Hervé for your help with this. Kevin has provided the *.deb package for installing OpenBabel 3.x on Ubuntu 18.04. Just in case, below is how we usually install OpenBabel 3.x.x across different Ubuntu/Debian systems.
BTW: is it correct to assume that the Ubuntu 18.04 builds will be discontinued in the next release in April? Thanks, Thomas ## Install ChemmineOB with OpenBabel 3.x from source ## First uninstall libopenbabel-dev (which is version 2.x.x) if already installed via sudo apt-get remove libopenbabel-dev; sudo apt-get purge libopenbabel-dev; sudo apt-get --purge autoremove libopenbabel-dev ## Some dependencies to install sudo apt install cmake libeigen3-dev libboost-all-dev ## Clone OpenBabel 3.x.x from GitHub here: https://github.com/openbabel/openbabel git clone g...@github.com:openbabel/openbabel.git mkdir build; cd build cmake ../openbabel make sudo make install ## Install ChemmineOB where you provide environment variables including header files and ChemmineOB package iprovided as *.tar.gz (adjust paths if not correct) R CMD INSTALL --configure-args='--with-openbabel-include=/usr/local/include/openbabel3/ --with-openbabel-lib=/usr/local/lib/openbabel/3.1.1' ChemmineOB_1.28.0.tar.gz On Mon, Mar 15, 2021 at 1:12 PM Kevin Horan <kho...@cs.ucr.edu> wrote: > Herve, > > I've backported openbabel3 from 20.04 to 18.04. You can download a > tarball with all the deb files in here: > > http://cluster.hpcc.ucr.edu/~khoran/ubuntu_18.04_openbabel3_debs.tar.gz > > Kevin > > On 3/15/21 10:10 AM, Hervé Pagès wrote: > > Hi Thomas, Kevin, > > > > We still need to install the system deps on the devel Windows builders > > (riesling1 and tokay2). We'll do it this week. Thanks for the reminder > > and for making the OpenBabel-3.0.0 Windows Binaries available on your > > GitHub repo. > > > > Note that OpenBabel 3 is installed on machv2 (devel macOS builders): > > > > machv2:~ biocbuild$ which obabel > > /usr/local/bin/obabel > > > > machv2:~ biocbuild$ obabel -V > > Open Babel 3.1.0 -- Oct 21 2020 -- 21:57:42 > > > > machv2:~ biocbuild$ pkg-config --cflags openbabel-3 > > -I/usr/local/Cellar/open-babel/3.1.1_1/include/openbabel3 > > > > machv2:~ biocbuild$ pkg-config --libs openbabel-3 > > -L/usr/local/Cellar/open-babel/3.1.1_1/lib -lopenbabel > > > > In release: The reason ChemmineOB does not compile on malbec1 is > > because it requires OpenBabel 3 but malbec1 only has OpenBabel 2 which > > is what Ubuntu 18.04 comes with. OpenBabel 3 only became available > > starting with Ubuntu 20.04. > > > > To workaround this we could propagate the ChemmineOB_1.28.2.tar.gz > > source tarball produced on nebbiolo1 (Ubuntu 20.04), or, if you know > > an easy way to get OpenBabel 3 installed on an Ubuntu 18.04 system, > > let us know and we will do that. The best thing would be to be able to > > use a .deb package for this. The easiest the procedure, the more > > likely people that are still using Ubuntu 18.04 will be able to > > install ChemmineOB. > > > > Best, > > H. > > > > > > > > On 3/12/21 11:10 AM, Thomas Girke wrote: > >> Dear Hervé and Martin, > >> > >> It seems the above problem on the Windows builds has been resolved > >> for some > >> time now. However, any updates on Linux in the release branch are not > >> taking effect since some/all of the Openbabel dependencies are not > >> available on the corresponding Linux build system (here Ubuntu 18.04). > >> However, Ubuntu 20.04 seems to be fine but may not be used to create the > >> source download instance at the moment? As a result, the package is only > >> up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not Linux > >> (still at > >> ChemmineOB_1.28.0.tar.gz): > >> http://bioconductor.org/packages/release/bioc/html/ChemmineOB.html. > >> To fix > >> this, one suggestion would be whether the functional build from the > >> 20.04 > >> system could be pushed instead of 18.04? Not sure whether this is less > >> effort than installing the dependencies on 18.04 that may be > >> discontinued > >> soon - just a suggestion/question? > >> > >> On the development branch the situation is opposite where the > >> dependencies are missing on Windows and OSX but Linux is fine: > >> http://bioconductor.org/checkResults/devel/bioc-LATEST/ChemmineOB/. > >> > >> We realize that the dependencies of the ChemmineOB package creates extra > >> workload for the Bioc team, and we are extremely grateful for the > >> support > >> by the Bioc core team. Please let us know if there is anything on our > >> end > >> that could be done to resolve this and/or to minimize your workload > >> as much > >> as possible. > >> > >> Thanks, > >> > >> Thomas > >> > >> On Mon, Feb 8, 2021 at 10:02 AM Martin Morgan <mtmorgan.b...@gmail.com> > >> wrote: > >> > >>> It's likely failing because your package has C source code that > >>> accesses > >>> memory in an invalid way. Likely the bug is present on all > >>> platforms, but > >>> only apparent, for the tests you have written, on Windows. The right > >>> thing > >>> to do is to fix the bug, rather than avoid by not running on the > >>> troublesome platform. > >>> > >>> Under Linux you'd likely have success with valgrind or UBSAN; if you > >>> were > >>> reasonably confident that the package occurred in unit tests, and > >>> you have > >>> a script to run the unit tests run_tests.R then something like > >>> > >>> R -d valgrind -f run_tests.R > >>> > >>> may be productive. valgrind is slow so it pays to narrow the problem > >>> down > >>> as much as possible. > >>> > >>> Maartin > >>> > >>> On 2/8/21, 12:43 PM, "Bioc-devel on behalf of Kevin Horan" < > >>> bioc-devel-boun...@r-project.org on behalf of kho...@cs.ucr.edu> > wrote: > >>> > >>> > >>> I have a package which randomly segfaults when running my > >>> unit > >>> tests only on windows i386, but never on x64, or any other OS. > >>> I can't > >>> imagine there are many out there still running i386 systems are > >>> there? > >>> Is it possible to just disable the i386 build on bioconductor > >>> so that > >>> the tests are not run on that architecture? > >>> > >>> I have of course done my best to debug the issue, but all > >>> I get > >>> is > >>> an error in some nt dll file, with no useful message or > >>> location. I'm > >>> I > >>> Linux guy, I don't know how to do the in-depth debugging that > >>> would be > >>> required to track this bug down on windows. I tried disabling each > >>> test > >>> one by one to see which one caused the crash, but as is typical > >>> with > >>> segfaults, changing the setup can mask the bug even when the > >>> bad code > >>> is > >>> still be executed. Each test runs fine in isolation. > >>> > >>> Thanks > >>> > >>> Kevin > >>> > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>> _______________________________________________ > >>> Bioc-devel@r-project.org mailing list > >>> https://stat.ethz.ch/mailman/listinfo/bioc-devel > >>> > >> > >> > > > -- Thomas Girke, Ph.D. Professor of Bioinformatics 1207F Genomics Building University of California Riverside, CA 92521 E-mail: thomas.gi...@ucr.edu URL: https://girke.bioinformatics.ucr.edu Phone/Cell/Text: 951-732-7072 Fax: 951-827-4437 [[alternative HTML version deleted]] _______________________________________________ Bioc-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/bioc-devel