The OS X configure in R-devel has been changed to use two-level namespaces. There are still some problems. 1. Trunmed.c in the modreg packages defines a function heapsort(), while heapsort is also defined (differently) in /usr/lib/stdlib.h. I (temporarily) disabled the definition in stdlib.h. 2. If R is configured with the --without-x flag, then CPPFLAGS does not include /usr/X11R6/include, while the tk.h files still tries to include X11/xlib.h (and can't find it, obviously). I added -I /usr/X11R6/include to the compile of tcltk.o 3. Configure does not pass the $(Rexecbindir) to the Makefiles in the /src/library directory, so the links cannot find the bundle_loader. I added them by hand for all package links. 4. The aqua module does not work with two-level namespaces. Since it does not work anyway, and Stefano will remove it soon, it may be better to remove it even sooner. 5. In order to link the bundles with -bundle -bundle_loader /usr/local/lib/R/bin/R.bin the /usr/local/lib/R/bin/R.bin must exist, and moreover must be an R-devel build. This is a little bootstrap problem which can be easily hacked.
On Mon, 24 Feb 2003, Jan de Leeuw wrote:> The OS X configure in R-devel has been changed to use two-level > namespaces. There > are still some problems. > > 1. Trunmed.c in the modreg packages defines a function heapsort(), > while heapsort > is also defined (differently) in /usr/lib/stdlib.h. I (temporarily) > disabled the > definition in stdlib.h.That's a very recent addition, and we do try to keep an eye on such things. The R symbol has been changed now.> 2. If R is configured with the --without-x flag, then CPPFLAGS does not > include > /usr/X11R6/include, while the tk.h files still tries to include > X11/xlib.h (and > can't find it, obviously). I added -I /usr/X11R6/include to the compile > of tcltk.oThis looks like a bug in your tkConfig.sh. For example on Solaris it has # -I switch(es) to use to make all of the X11 include files accessible: TK_XINCLUDES='-I/usr/openwin/include' and that is what R uses, specifically if test -n "${TK_XINCLUDES}"; then TCLTK_CPPFLAGS="${TCLTK_CPPFLAGS} ${TK_XINCLUDES}" else TCLTK_CPPFLAGS="${TCLTK_CPPFLAGS} ${X_CFLAGS}" fi Or is tkConfig.sh not being found and you need to point configure at it? -- Brian D. Ripley, ripley@stats.ox.ac.uk Professor of Applied Statistics, http://www.stats.ox.ac.uk/~ripley/ University of Oxford, Tel: +44 1865 272861 (self) 1 South Parks Road, +44 1865 272866 (PA) Oxford OX1 3TG, UK Fax: +44 1865 272595
>>>>> Jan de Leeuw writes:> The OS X configure in R-devel has been changed to use two-level > namespaces. There are still some problems.> 3. Configure does not pass the $(Rexecbindir) to the Makefiles in the > /src/library directory, so the links cannot find the bundle_loader. I > added them by hand for all package links.I thought I had already fixed this, but maybe I am missing something obvious. It seems to me that e.g. ctest/src/Makefile has R_HOME = $(top_builddir) ... include $(top_srcdir)/share/make/shlib.mk where the latter has include $(R_HOME)/etc/Makeconf which in turn has ## As we currently use ## -bundle -bundle_loader $(Rexecbindir)/R.bin -undefined error ## for the default SHLIB_LDFLAGS on Darwin >= 5 ... rhome = @libdir@/R Rexecbindir = $(rhome)/bin (in the source). But I now see that on my system this gives rhome = ${exec_prefix}/lib/R for reasons maybe known to Autoconf wizards but not to me: so I will add substitutions for prefix and exec_prefix as well. Pls let me know if this helps.> 5. In order to link the bundles with -bundle -bundle_loader > /usr/local/lib/R/bin/R.bin the /usr/local/lib/R/bin/R.bin must exist, > and moreover must be an R-devel build. This is a little bootstrap > problem which can be easily hacked.As I already tried to explain, I think there is a more substantial problem here. We build in say, BUILDDIR and install to INSTALLDIR, say, and there no reason to assume for something to work in BUILDDIR that something else has happened in INSTALLDIR. In fact, for typical users we cannot even do something in the default INSTALLDIR as they will have no write permissions in /usr/local. The only thing guaranteed to work is to use a bundle loader path in BUILDDIR when building, and change to one in INSTALLDIR when installing. I assume this amounts to re-linking and hence a terrible mess unless we use GNU libtool to provide an abstraction, and I hope we will have this for R 2.0, but certainly not for 1.7. Or is there a way to change the bundle loader? Best -k