[Rd] HAVE_BZLIB_H not set

[Martyn Plummer]

That must be a different problem as this one affects both R 2.7.2 and R
2.8.0 on Fedora 9. When the header is not included, the test program
that checks the version of bzlib segfaults. 

We can fix this by using AC_CHECK_HEADERS instead of AC_CHECK_HEADER
when looking for bzlib.h, since the former macro defines the missing
variable. Checking this in now.

Martyn

On Sun, 2008-10-26 at 15:24 -0500, Dirk Eddelbuettel wrote:
> On 26 October 2008 at 12:02, "Tom \"spot\" Callaway" wrote:
> | When building 2.8.0 this morning for Fedora, I noticed that it was
> | building the included bzlib2 source and using it rather than the system
> | bzip2 libraries and headers. I tracked down the reason to this section
> | of configure:
> | 
> | cat >>conftest.$ac_ext <<_ACEOF
> | /* end confdefs.h.  */
> | 
> | #ifdef HAVE_BZLIB_H
> | #include <bzlib.h>
> | #endif
> | int main() {
> |     char *ver = BZ2_bzlibVersion();
> |     exit(strcmp(ver, "1.0.5") < 0);
> | }
> | 
> | _ACEOF
> | 
> | That code wasn't working at all because HAVE_BZLIB_H never gets set
> | anywhere, even though the configure script had found the system bzip2
> | bits. This patch adds it to m4/R.m4 and configure, against 2.8.0. With
> | the patch, R now properly detects bzip2 1.0.5 in Fedora and uses that
> | rather than the local copy.
> 
> We had that problem in Debian with (most of ) the 2.7.* series when R thought
> it needed to compile bzip2 support itself -- but it didn't before, and it
> does no more since where it works in R 2.8.* and its prereleases as ...
> 
> edd at ron:~/src/debian/build-logs$ grep "whether bz" r-base_2.7.*
> r-base_2.7.0-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.0.20080304-1.log:checking whether bzip2 support needs to be compiled... no
> r-base_2.7.0~20080408-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.0~20080415-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.0~20080416-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.1-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.1~20080614-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.1~20080621-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.1.20080621-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.1-2.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.2-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.2~20080816-1.log:checking whether bzip2 support needs to be compiled... yes
> r-base_2.7.2-2.log:checking whether bzip2 support needs to be compiled... yes
> edd at ron:~/src/debian/build-logs$ grep "whether bz" r-base_2.8.*
> r-base_2.8.0-1.log:checking whether bzip2 support needs to be compiled... no
> r-base_2.8.0~20081005-1.log:checking whether bzip2 support needs to be compiled... no
> r-base_2.8.0~20081006-1.log:checking whether bzip2 support needs to be compiled... no
> r-base_2.8.0~20081013-1.log:checking whether bzip2 support needs to be compiled... no
> r-base_2.8.0.20081013-1.log:checking whether bzip2 support needs to be compiled... no
> edd at ron:~/src/debian/build-logs$ 
> 
> ... Kurt fixed that in r-devel in mid-July and told me then that the issue was a
> missing link instruction for -lbz2 in the actual test configure runs, rather
> than the string comparison as I had conjectured.  
> 
> That makes me think that maybe it is not the matter of the #define you
> set. But I defer to Kurt on this.
> 
> Cheers, Dirk
> 

-----------------------------------------------------------------------
This message and its attachments are strictly confidenti...{{dropped:8}}