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
<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
<mailto: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
<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
<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/
<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 <mailto: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
<mailto:bioc-devel-boun...@r-project.org> on behalf of
kho...@cs.ucr.edu <mailto: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 <mailto:Bioc-devel@r-project.org>
mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
<https://stat.ethz.ch/mailman/listinfo/bioc-devel>
>>> _______________________________________________
>>> Bioc-devel@r-project.org <mailto:Bioc-devel@r-project.org>
mailing list
>>> https://stat.ethz.ch/mailman/listinfo/bioc-devel
<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 <mailto:thomas.gi...@ucr.edu>
URL: https://girke.bioinformatics.ucr.edu
<https://girke.bioinformatics.ucr.edu>
Phone/Cell/Text: 951-732-7072
Fax: 951-827-4437
