[Bioc-devel] Segfault in Rsamtools when R built with static libz

Hi all,

I build the R installations on our research cluster. Unfortunately we
are running an older OS so the system versions of various libraries
(libz, bz2, pcre and libcurl, specifically) are not modern enough to
build R with.

For protection from ABI incompatability when R is interacting with other
programs on the system, I have built static versions of those libraries
and linked them directly into R. This works fine once a few gotchas are
taken care of.

After an inordinant amount of work, I have tracked an intermittent
segfault we have been getting to Rsamtools, and specifically the version
of libz that it grabs during linking.

The problem is that Rsamtools is hardcoded to have -lz in it's PKG_LIBS
variable by Makevars (I believe this is because the embedded version of
samtools needs libz). Because there is no way (that I know of) to take
the system libz out of the path, and it is an so, it will ALWAYS be used
instead of the static one I want it to use instead. Furthermore, AFAICS
there is no way to override the PKG_LIBS construction with an
environment variable.

Can someone please make Rsamtools' Makevars a bit more polite for those
of us stuck in old OSes?
Barring that (and until that lands) I am stuck downloading and modifying
the package locally, which I really don't like doing.

Thanks,
~G


--
Gabriel Becker, Ph.D
Associate Scientist
Bioinformatics and Computational Biology
Genentech Research

Hi Gabe --

On 07/21/2016 12:08 PM, Maintainer wrote:

Hi all,

I build the R installations on our research cluster. Unfortunately we
are running an older OS so the system versions of various libraries
(libz, bz2, pcre and libcurl, specifically) are not modern enough to
build R with.

For protection from ABI incompatability when R is interacting with other
programs on the system, I have built static versions of those libraries
and linked them directly into R. This works fine once a few gotchas are
taken care of.

After an inordinant amount of work, I have tracked an intermittent
segfault we have been getting to Rsamtools, and specifically the version
of libz that it grabs during linking.

The problem is that Rsamtools is hardcoded to have -lz in it's PKG_LIBS
variable by Makevars (I believe this is because the embedded version of
samtools needs libz). Because there is no way (that I know of) to take
the system libz out of the path, and it is an so, it will ALWAYS be used
instead of the static one I want it to use instead. Furthermore, AFAICS
there is no way to override the PKG_LIBS construction with an
environment variable.

Can someone please make Rsamtools' Makevars a bit more polite for those
of us stuck in old OSes?
Barring that (and until that lands) I am stuck downloading and modifying
the package locally, which I really don't like doing.

Sorry to be slow at this. I guess this could be done 'elegantly' via
configure.ac, but that introduces some complexity. I was wondering...

Other packages hard-code -lz, including e.g., rtracklayer,
VariantAnnotation, Rsubread, and R itself (including grDevices). So I guess
this is a general problem?

Can you build R with static linkage, and set LDFLAGS to include a 'custom'
location before the system-wide location?

Martin

Thanks,
~G


--
Gabriel Becker, Ph.D
Associate Scientist
Bioinformatics and Computational Biology
Genentech Research

This email message may contain legally privileged and/or...{{dropped:2}}

wrote:

Maybe Gabe could share the linker line. I think (from the man page) as
long as the directory with the static lib comes first with -L, it
should find the static lib, not the shared object.

On Wed, Jul 27, 2016 at 6:48 AM, Martin Morgan
<martin.morgan at roswellpark.org> wrote:

Hi Gabe --

On 07/21/2016 12:08 PM, Maintainer wrote:

Hi all,

I build the R installations on our research cluster. Unfortunately we
are running an older OS so the system versions of various libraries
(libz, bz2, pcre and libcurl, specifically) are not modern enough to
build R with.

For protection from ABI incompatability when R is interacting with other
programs on the system, I have built static versions of those libraries
and linked them directly into R. This works fine once a few gotchas are
taken care of.

After an inordinant amount of work, I have tracked an intermittent
segfault we have been getting to Rsamtools, and specifically the version
of libz that it grabs during linking.

The problem is that Rsamtools is hardcoded to have -lz in it's PKG_LIBS
variable by Makevars (I believe this is because the embedded version of
samtools needs libz). Because there is no way (that I know of) to take
the system libz out of the path, and it is an so, it will ALWAYS be used
instead of the static one I want it to use instead. Furthermore, AFAICS
there is no way to override the PKG_LIBS construction with an
environment variable.

Can someone please make Rsamtools' Makevars a bit more polite for those
of us stuck in old OSes?
Barring that (and until that lands) I am stuck downloading and modifying
the package locally, which I really don't like doing.

Sorry to be slow at this. I guess this could be done 'elegantly' via
configure.ac, but that introduces some complexity. I was wondering...

Other packages hard-code -lz, including e.g., rtracklayer,
VariantAnnotation, Rsubread, and R itself (including grDevices). So I

guess

this is a general problem?

Can you build R with static linkage, and set LDFLAGS to include a

'custom'

location before the system-wide location?

Martin

Thanks,
~G


--
Gabriel Becker, Ph.D
Associate Scientist
Bioinformatics and Computational Biology
Genentech Research

This email message may contain legally privileged and/or...{{dropped:2}}