On 18/11/17 18:18, Peter Langfelder wrote:> Rolf, > > looking at the configure script I believe you need to specify > > --with-tcl-config=/usr/lib/tcl8.6/tclConfig.sh > > and similarly > > --with-tk-config=<location of tkConfig.sh> > > HTH.Yes it helped. Thank you. I don't really understand why, but. I had previously (following an off-list suggestion from Berwin Turlach) put in symbolic links in /usr/lib: tclConfig.sh -> tcl8.6/tclConfig.sh* and tkConfig.sh -> tk8.6/tclConfig.sh so if the configure was by default looking for these files in /usr/lib it should have found them. But it seemed not to. In respect of Dirk's suggestion that I try using pre-built ubuntu R, I decided to try that and did sudo apt update sudo apt-get install r-base and that kind of worked --- but naturally it screwed something up. I can no longer load a "personal" library of utilities --- when I try this (either having the load command in my .Rprofile or by invoking R --vanilla) R crashes and tries to dump core. Now, after having successfully installed R from source (following Peter Langfelder's tip) I still cannot load my utilities library. Something got changed by the "install r-base" procedure, and there would appear to be no way of tracking down just what got changed. It's things like that which make me want to "do it myself" as much as possible. W.r.t. Peter Dalgaard's suggestion/question about ${LIBnn}$: I looked through R-3.4.2/configure and can see nowhere that LIBnn gets set. (Lots of references to LIBnn, but nowhere that its value gets set equal to something.) BTW I (of course) am using the configure file that comes with R-3.4.2; I haven't changed anything. So if anyone looks at the R-3.4.2 configure file they should see exactly what I see. Then I scanned through BldDir/config.log and found: LIBnn='lib64' (on line 19901 !!!) So it would appear that Peter D.'s conjecture is correct. OTOH this is waaayyy after the "checking for tclConfig.sh" business, which happens at about line 15101 of config.log. So how does it have an impact on that? And how did LIBnn get to be set to 'lib64'? I certainly didn't do it, and there's nothing about 'lib64' in the environment variables that I have set. I remain mystified. cheers, Rolf P.S. On a whim, I scanned through config.log some more and found many, many errors logged and many, many "compilation terminated" notes. In particular there seem to be problems with a file "confdef.h", which repeatedly seems to give rise to "fatal errors". (Where is confdef.h? It seems to be nowhere.) But this was from a "*successful*" configure (using Peter L.'s suggestion.) So it would appear that these errors were harmless. Mostly harmless??? R. -- Technical Editor ANZJS Department of Statistics University of Auckland Phone: +64-9-373-7599 ext. 88276
This is normal, but you're not reading it right. Typically, a program conftest.c is generated on the fly and contains something like a #include of something you may or may not have. The first part of the program is labeled /* conftest.h */ which indicates that it is taken from that file of standard definitions. The contents of confdefs.h is actually mostly irrelevant (though I suppose there are cases when it isn't), the interesting bit is usually the line(s) that comes from elsewhere, e.g. .... | #define HAVE_UNISTD_H 1 | #define HAVE_UTIME_H 1 | #define HAVE_ARPA_INET_H 1 | /* end confdefs.h. */ | #include <dl.h> configure:23459: result: no configure:23459: checking for dl.h configure:23459: result: no This whole thint is about whether or not your system contains dl.h. When the compile fails, configure concludes that it doesn't. You only get to see the programs when they fail, but the same mechanism is behind all the other tests, like configure:23459: checking langinfo.h presence configure:23459: gcc -arch x86_64 -E -I/usr/local/include conftest.c configure:23459: $? = 0 configure:23459: result: yes configure:23459: checking for langinfo.h configure:23459: result: yes In some other cases, there is a rudimentary main() function, usually to check existence of specific library routines, and in a few cases there is a check whether the compiled program actually runs. -pd> On 19 Nov 2017, at 02:02 , Rolf Turner <r.turner at auckland.ac.nz> wrote: > > P.S. On a whim, I scanned through config.log some more and found many, many errors logged and many, many "compilation terminated" notes. In particular there seem to be problems with a file "confdef.h", which repeatedly seems to give rise to "fatal errors". (Where is confdef.h? > It seems to be nowhere.)-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
Dirk may want to dig in here: Seems like you have a system with a /usr/lib64 dir for 64 bit libraries, but Tcl files in /usr/lib. If that is not an anomaly, it looks like we have a configure bug (conceiveably, a system might be using /usr/lib for architecture-independent files, and lib64/lib32 for binaries). It doesn't look too hard to modify configure to also check /usr/lib, but we probably shouldn't do it if one user has shot himself in the foot somehow. -pd> On 19 Nov 2017, at 02:02 , Rolf Turner <r.turner at auckland.ac.nz> wrote: > > Then I scanned through BldDir/config.log and found: > > LIBnn='lib64' > > (on line 19901 !!!) > > So it would appear that Peter D.'s conjecture is correct. > > OTOH this is waaayyy after the "checking for tclConfig.sh" business, which happens at about line 15101 of config.log. So how does it have an impact on that? > > And how did LIBnn get to be set to 'lib64'? I certainly didn't do it, and there's nothing about 'lib64' in the environment variables that I have set.-- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Office: A 4.23 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
On 19 November 2017 at 12:17, peter dalgaard wrote: | Dirk may want to dig in here: I respectfully decline. R builds fine on every Ubuntu system, and always has. No bug in R, or Ubuntu, or Debian (which would be cup of tea). There is the distro package (which may be older if an older distro like 16.04 is used) and there always is a current package at CRAN based on Michael's build of my packages. Always. Of course a lot of people also locally build R, or maybe R-devel. There is no general issue here as best as I can tell. | [...] if one user has shot himself in the foot somehow. My brief reading suggests that this is the case. Nothing good comes off moving files around in /usr as was done. It creates local non-standard circumstances. You cannot expect standardized build to anticipate each and every possible non-standard modification. This discussion is still on the wrong list too. Dirk -- http://dirk.eddelbuettel.com | @eddelbuettel | edd at debian.org