HAVE_BZLIB_H not set
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}}