Number 3 below is fixed. Number 5 is a bootstrap problem, which could be solved perhaps with
make bin; make install bin; make install modules packages
or by doing a real two stage build. But I agree that is a major change in the build process.
This can also be hacked by doing a make install, wait until it breaks, then do another make install. I am not suggesting this as an actual solution.
It's not a problem if you have a version of R installed, at least not if that R.bin has all the required symbols (but I think the R.bin from 1.6.2 misses one symbol needed by the 1.7.0 version of ctest, for example). Again this does not provide a solution.
I'll see if the bundle_loader solution can be changed in any way (for instance by using weak binding, so that the symbol does not have to be there at link time, only at run time).
On Tuesday, Feb 25, 2003, at 23:57 US/Pacific, Kurt Hornik wrote:
===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
______________________________________________ [EMAIL PROTECTED] mailing list http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
Jan de Leeuw; Professor and Chair, UCLA Department of Statistics;
Editor: Journal of Multivariate Analysis, Journal of Statistical Software
US mail: 9432 Boelter Hall, Box 951554, Los Angeles, CA 90095-1554
phone (310)-825-9550; fax (310)-206-5658; email: [EMAIL PROTECTED]
homepage: http://gifi.stat.ucla.edu
------------------------------------------------------------------------ -------------------------
No matter where you go, there you are. --- Buckaroo Banzai
http://gifi.stat.ucla.edu/sounds/nomatter.au
------------------------------------------------------------------------ -------------------------
______________________________________________ [EMAIL PROTECTED] mailing list http://www.stat.math.ethz.ch/mailman/listinfo/r-devel
