[Rd] R-2.2.0: malloc probelm in regex code (PR#8287)
Full_Name: Gordon Lack Version: 2.2.0 OS: OSF1/Tur64 Submission from: (NULL) (193.128.25.20) R-2.2.0 fails to build on OSF1 systems. . make[4]: Leaving directory `/R-2.2.0/src/library/tools/src Error in list.files(path, pattern, all.files, full.names, recursive) : invalid 'pattern' regular expression Execution halted make[3]: *** [all] Error 1 . I've tracked down the problem to change (somewhere) in 2.2.0 vs. 2.1.1 which has resulted in re_node_set_alloc() (in src/main/regex.c) being called with a size of 0. Whereas some system (Solaris, Linux, ...) return a valid pointer to a zero-size allocation, OSF1 returns a NULL pointer on a 0 allocation request (documented as such, and the Open Group Base Specifications Issue 6 documents that either may happen). The calling code treats a NULL return as a ESPACE error. In R-2.1.1 this code was not asked to allocate 0 sizes, so I suspect that it shouldn't be happening here either. A workaround is to add: if (size==0) size=1; /* OSF1 (at least) returns NULL on 0 alloc */ before the re_malloc (int, size) line in re_node_set_alloc(), which just means you allocate a small space (which shodul be free()d soon anyway). The actual regex whcih triggers this during the build is: ^tools($|_) __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] R 2.8.0. INSTALL script error on Solaris2.8 (PR#13261)
Full_Name: Gordon Lack
Version: 2.8.0
OS: Solaris 2.8
Submission from: (NULL) (198.28.92.5)
The INSTALL.in script in src/scripts has this at line 620:
if ! test -f "${R_INCLUDE_DIR}/R.h" ; then
That fails to run under sh on Solaris (itis OK in bash, which is why it runs OK
on Linux).
The correct sh syntax is:
if test ! -f "${R_INCLUDE_DIR}/R.h" ; then
i.e. test understands that ! means not, but the if statement in sh doesn't.
The result of this is that you get error messages tryign to install extensions
on Solaris.
/the/path/to/my/installation/2.8.0/lib/R/bin/INSTALL: !: not found
__
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] configure issue (PR#9379)
Full_Name: Gordon Lack Version: 2.4.0 OS: Redhat Linux AS2.1 Submission from: (NULL) (198.28.92.5) Not sure whether this is a configure issue or an R one. It's only a minor issue, so this is really just FYI. The code in configure checks for the version of makeinfo by splitting the version string into a major and minor component. The tests on these assume they are numeric. RHAS2.1 shipped with a makeinfo version of "4.0b" The result is this: = checking whether makeinfo version is at least 4.7... ./configure: test: 0b: integer expression expected yes = ie: an error reported, but the test passed (4.0b > 4.7!!!). And there is no command line option to tell configure not to run the makeinfo commands (you can set r_cv_prog_makeinfo_v4=0 in your environment, but that isn't "right"). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] OSF1 build fails (PR#9380)
Full_Name: Gordon Lack Version: 2.4.0 OS: OSF1 5.1 Submission from: (NULL) (198.28.92.5) Attempts to build R 2.4.0 on an OSF1 5.1 system result in: == gcc -I. -I../../src/include -I../../src/include .. In file included from dynload.c:33: ../../src/include/Defn.h:554: error: parse error before "R_CStackLimit" ../../src/include/Defn.h:554: warning: type defaults to `int' in declaration of `R_CStackLimit' ../../src/include/Defn.h:554: warning: data definition has no type or storage class ../../src/include/Defn.h:555: error: parse error before "R_CStackStart" ../../src/include/Defn.h:555: warning: type defaults to `int' in declaration of `R_CStackStart' ../../src/include/Defn.h:555: warning: data definition has no type or storage class == This is a result of uintptr_t being undefined at this point. This is caused by HAVE_DECL_SIZE_MAX not being defined on OSF1 and so is not included. Moving the inclusion of (which is already conditional on having it) out of the SIZE_MAX test block cures the problem. __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
[Rd] Solaris build produces worrying warning. (PR#9382)
Full_Name: Gordon Lack Version: 2.4.0 OS: Solaris8 Submission from: (NULL) (198.28.92.5) A 32-bit compile of R-2.4.0 on Solaris8 (using gcc3.4.3) produces this: == make[3]: Entering directory `/var/tmp/gml-R/R-2.4.0/src/extra/pcre' gcc -I. -I. -I../../../src/include -I../../../src/include ... -DHAVE_CONFIG_H -g -O2 -std=gnu99 -c dftables.c -o dftables.o In file included from pcre_internal.h:68, from dftables.c:50: ../../../src/include/config.h:903:1: warning: "_FILE_OFFSET_BITS" redefined In file included from /usr/include/iso/ctype_iso.h:30, from /usr/include/ctype.h:18, from dftables.c:46: /usr/include/sys/feature_tests.h:96:1: warning: this is the location of the previous definition == _FILE_OFFSET_BITS is being redefined from 32 to 64 here, which I find slightly worrying. The problem is caused by stdio.,h being included before config.h. The former sets _FILE_OFFSET_BITS to 32 if it is not set, while the latter sets it to 64 (which it should be) unconditionally. BUT, by then all of stdio.h has been run though with it set to 32... Possible fixes are: a) include as the first #include b) move the include of pcre_internal.h to be the first one (since it includes config.h). __ R-devel@r-project.org mailing list https://stat.ethz.ch/mailman/listinfo/r-devel
