[Bioc-devel] is it possible to disable i386 builds on bioconductor

Thomas Girke thom@@@g|rke @end|ng |rom ucr@edu
Mon Mar 15 21:59:18 CET 2021


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 git using 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 using 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.bioc using 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-bounces using r-project.org on behalf of khoran using 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 using r-project.org mailing list
> >>>      https://stat.ethz.ch/mailman/listinfo/bioc-devel
> >>> _______________________________________________
> >>> Bioc-devel using 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.girke using ucr.edu
URL: https://girke.bioinformatics.ucr.edu
Phone/Cell/Text: 951-732-7072
Fax: 951-827-4437

	[[alternative HTML version deleted]]



More information about the Bioc-devel mailing list