@Kevin: Thanks for providing openbabel3 for Ubuntu 18.04. Will take a
look ASAP.
@Thomas: Yes, the Ubuntu 18.04 builds are only used for the BioC 3.12
builds (release). BioC 3.13 and further BioC releases are/will be using
Ubuntu >= 20.04.
Best,
H.
On 3/15/21 1:59 PM, Thomas Girke wrote:
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 git at 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 <khoran at cs.ucr.edu
<mailto:khoran at 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
> (riesling1 and tokay2). We'll do it this week. Thanks for the
> and for making the OpenBabel-3.0.0 Windows Binaries available on
> GitHub repo.
>
> Note that OpenBabel 3 is installed on machv2 (devel macOS
>
> 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
> is what Ubuntu 18.04 comes with. OpenBabel 3 only became
> starting with Ubuntu 20.04.
>
> To workaround this we could propagate the
> source tarball produced on nebbiolo1 (Ubuntu 20.04), or, if you
> an easy way to get OpenBabel 3 installed on an Ubuntu 18.04
> let us know and we will do that. The best thing would be to be
> 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
>> for some
>> time now. However, any updates on Linux in the release branch
>> taking effect since some/all of the Openbabel dependencies are
>> available on the corresponding Linux build system (here Ubuntu
>> However, Ubuntu 20.04 seems to be fine but may not be used to
>> source download instance at the moment? As a result, the package
>> up-to-date for Windows and OSX (ChemmineOB_1.28.2.) but not
>> (still at
>> ChemmineOB_1.28.0.tar.gz):
>>
>> To fix
>> this, one suggestion would be whether the functional build
>> 20.04
>> system could be pushed instead of 18.04? Not sure whether this
>> 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:
>>
>>
>> We realize that the dependencies of the ChemmineOB package
>> workload for the Bioc team, and we are extremely grateful for
>> support
>> by the Bioc core team. Please let us know if there is anything
>> end
>> that could be done to resolve this and/or to minimize your
>> as much
>> as possible.
>>
>> Thanks,
>>
>> Thomas
>>
>> On Mon, Feb 8, 2021 at 10:02 AM Martin Morgan
<mtmorgan.bioc at gmail.com <mailto:mtmorgan.bioc at gmail.com>>
>>> 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
>>> thing
>>> to do is to fix the bug, rather than avoid by not running on
>>> troublesome platform.
>>>
>>> Under Linux you'd likely have success with valgrind or UBSAN;
>>> were
>>> reasonably confident that the package occurred in unit tests,
>>> 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
>>> down
>>> as much as possible.
>>>
>>> Maartin
>>>
>>> ?On 2/8/21, 12:43 PM, "Bioc-devel on behalf of Kevin Horan" <
>>> bioc-devel-bounces at r-project.org
<mailto:bioc-devel-bounces at r-project.org> on behalf of
khoran at cs.ucr.edu <mailto:khoran at cs.ucr.edu>> wrote:
>>>
>>>
>>> I have a package which randomly segfaults when
>>> unit
>>> tests only on windows i386, but never on x64, or any other
>>> I can't
>>> imagine there are many out there still running i386
>>> there?
>>> Is it possible to just disable the i386 build on
>>> so that
>>> the tests are not run on that architecture?
>>>
>>> I have of course done my best to debug the issue, but
>>> 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
>>> would be
>>> required to track this bug down on windows. I tried
>>> test
>>> one by one to see which one caused the crash, but as is
>>> with
>>> segfaults, changing the setup can mask the bug even when
>>> bad code
>>> is
>>> still be executed. Each test runs fine in isolation.
>>>
>>> Thanks
>>>
>>> Kevin
>>>
>>> _______________________________________________
>>> Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
>>> _______________________________________________
>>> Bioc-devel at r-project.org <mailto:Bioc-devel at r-project.org>
--
Herv? Pag?s
Bioconductor Core Team
hpages.on.github at gmail.com