> On 23 Nov 2015, at 22:30 , aixtools <aixtools at gmail.com> wrote: > >> >> ./configure --enable-maintainer-mode ...Two things here - possibly irrelevant, but I'd avoid building in the source directory. (mkdir ../BUILD ; cd ../BUILD; ../R/configure) - don't turn on mantainer mode. You are not a maintainer, and if you want to play at being one, I think you need extra tools. -- Peter Dalgaard, Professor, Center for Statistics, Copenhagen Business School Solbjerg Plads 3, 2000 Frederiksberg, Denmark Phone: (+45)38153501 Email: pd.mes at cbs.dk Priv: PDalgd at gmail.com
On 2015-11-23 23:43, peter dalgaard wrote:>> On 23 Nov 2015, at 22:30 , aixtools<aixtools at gmail.com> wrote: >> >>> ./configure --enable-maintainer-mode ... > Two things here > > - possibly irrelevant, but I'd avoid building in the source directory. (mkdir ../BUILD ; cd ../BUILD; ../R/configure)I'll try this. It is a requirement for building gcc.> > - don't turn on mantainer mode. You are not a maintainer, and if you want to play at being one, I think you need extra tools. >Nope - do not want to be a maintainer (of R) - just hope to have a easy to install package. I was trying the flag because it helped spot things while packaging httpd. Would not have it on for normal packaging. I was thinking more verbose messages. Thanks.
On 2015-11-23 23:43, peter dalgaard wrote:>> On 23 Nov 2015, at 22:30 , aixtools<aixtools at gmail.com> wrote: >> >>> ./configure --enable-maintainer-mode ... > Two things here > > - possibly irrelevant, but I'd avoid building in the source directory. (mkdir ../BUILD ; cd ../BUILD; ../R/configure) > > - don't turn on mantainer mode. You are not a maintainer, and if you want to play at being one, I think you need extra tools. >Took advice, and moving forward. Currently both 32-bit and 64-bit are having similar issues - which I prefer to one working perfectly and the other having issues. Main issues are dublicate issues and a missing function - that I would expect to be in libm (logf()). So, for both 32-bit and 64-bit, even with -lm added to LDFLAGS it is ending with: byte-compiling package 'grDevices' Warning in solve.default(rgb) : unable to load shared object '/data/prj/cran/32/R-build/modules//lapack.so': rtld: 0712-001 Symbol logf was referenced from module /data/prj/cran/32/R-build/lib/libRlapack.so(), but a runtime definition of the symbol was not found. Error in solve.default(rgb) : LAPACK routines cannot be loaded Error: unable to load R code in package 'grDevices' Execution halted /data/prj/cran/R-devel/share/make/lazycomp.mk:7: recipe for target '../../../library/grDevices/R/grDevices.rdb' failed For the interested, I have captured the screen outputs of the configure and make - sub-directory 003 is the last 64-bit I tried, and sub-directory 004 is the 32-bit build. See http://download.aixtools.net/test/R/2015-11-23/ as I do not want to bog down mailers with included files. * Note that the 32-bit build failed because the 64-bit curl include files were still installed. MAYBE it is worth considering having curl included again in the source distribution. That way the correct include files can be included in R directories for packages et al that are being built around/based upon R environment.
On 2015-11-23 23:43, peter dalgaard wrote:>> On 23 Nov 2015, at 22:30 , aixtools<aixtools at gmail.com> wrote: >> >>> ./configure --enable-maintainer-mode ... > Two things here > > - possibly irrelevant, but I'd avoid building in the source directory. (mkdir ../BUILD ; cd ../BUILD; ../R/configure) > > - don't turn on mantainer mode. You are not a maintainer, and if you want to play at being one, I think you need extra tools. >I think I may need the extra tools. Besides autoconf and automake (plus gnu m4) - what other tools are needed? I am not able to generate a good configure (yet). root at x072:[/data/prj/cran/R-devel]autoconf configure.ac:254: error: possibly undefined macro: AM_CONDITIONAL If this token and others are legitimate, please use m4_pattern_allow. See the Autoconf documentation. configure.ac:655: error: possibly undefined macro: AC_DISABLE_STATIC configure.ac:727: error: possibly undefined macro: AC_CHECK_LIBM configure.ac:1982: error: possibly undefined macro: AM_LANGINFO_CODESET configure.ac:2639: error: possibly undefined macro: AM_NLS configure.ac:2643: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION configure.ac:2644: error: possibly undefined macro: AM_GNU_GETTEXT What I changed... root at x072:[/data/prj/cran]diff -u R-devel_2015-11-26/configure.ac R-devel/configure.ac --- R-devel_2015-11-26/configure.ac 2015-10-18 16:02:55.000000000 +0000 +++ R-devel/configure.ac 2015-11-26 13:29:28.000000000 +0000 @@ -1300,12 +1300,14 @@ ##ADD: A symbol of memcpy,memset is exported in libR by expall. ##ADD: However, for example, symbol in libc of memcpy is __memmove,__memmove64. ##ADD: This black magic puts lc before lR and pockets this. + ## MAMF: This black magic is no longer working, it seems - getting duplicate symbol errors now. if test "x${OBJECT_MODE}" = "x64"; then - main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x100000000 ${wl}-bpD:0x110000000 -lc" + main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x100000000 ${wl}-bpD:0x110000000" else - main_ldflags="${wl}-brtl ${wl}-bexpall -lc" + main_ldflags="${wl}-brtl ${wl}-bexpall" fi - shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry -lc" + ## MAMF: This black magic is clearly not working, removed from main_ldflags to be consistent + shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry" SHLIB_LIBADD="\$(LIBM)" shlib_cxxldflags="${shlib_ldflags}" if test "${GCC}" = yes; then This removes most of the Duplicate symbol messages, although there are still several coming from -lR being included during the build of the shared libraries (.so files). Another group of Duplicate symbols is coming from the -lm flag being too early in the command syntax (autoconf library discovery, so more difficult to "move", or "remove". And I expect the logf() failure is from a program that was dynamically linked but the symbol was ignored (as unref/unknown) for some reason. I'll continue looking for that. Regards, Michael p.s. is libR still exporting a libc defined symbol? Or is this just very old text?
If you do want to play with maintainer-mode, first check out https://developer.r-project.org/R-build-prerelease it is what is done in the nightly builds on OSX. (Actually Mavericks. The comment is old.) -pd On 26 Nov 2015, at 14:38 , Michael Felt <aixtools at gmail.com> wrote:> On 2015-11-23 23:43, peter dalgaard wrote: >>> On 23 Nov 2015, at 22:30 , aixtools<aixtools at gmail.com> wrote: >>> >>>> ./configure --enable-maintainer-mode ... >> Two things here >> >> - possibly irrelevant, but I'd avoid building in the source directory. (mkdir ../BUILD ; cd ../BUILD; ../R/configure) >> >> - don't turn on mantainer mode. You are not a maintainer, and if you want to play at being one, I think you need extra tools. >> > I think I may need the extra tools. Besides autoconf and automake (plus gnu m4) - what other tools are needed? > > I am not able to generate a good configure (yet). > > root at x072:[/data/prj/cran/R-devel]autoconf > configure.ac:254: error: possibly undefined macro: AM_CONDITIONAL > If this token and others are legitimate, please use m4_pattern_allow. > See the Autoconf documentation. > configure.ac:655: error: possibly undefined macro: AC_DISABLE_STATIC > configure.ac:727: error: possibly undefined macro: AC_CHECK_LIBM > configure.ac:1982: error: possibly undefined macro: AM_LANGINFO_CODESET > configure.ac:2639: error: possibly undefined macro: AM_NLS > configure.ac:2643: error: possibly undefined macro: AM_GNU_GETTEXT_VERSION > configure.ac:2644: error: possibly undefined macro: AM_GNU_GETTEXT > > What I changed... > > root at x072:[/data/prj/cran]diff -u R-devel_2015-11-26/configure.ac R-devel/configure.ac > --- R-devel_2015-11-26/configure.ac 2015-10-18 16:02:55.000000000 +0000 > +++ R-devel/configure.ac 2015-11-26 13:29:28.000000000 +0000 > @@ -1300,12 +1300,14 @@ > ##ADD: A symbol of memcpy,memset is exported in libR by expall. > ##ADD: However, for example, symbol in libc of memcpy is __memmove,__memmove64. > ##ADD: This black magic puts lc before lR and pockets this. > + ## MAMF: This black magic is no longer working, it seems - getting duplicate symbol errors now. > if test "x${OBJECT_MODE}" = "x64"; then > - main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x100000000 ${wl}-bpD:0x110000000 -lc" > + main_ldflags="${wl}-brtl ${wl}-bexpall ${wl}-bpT:0x100000000 ${wl}-bpD:0x110000000" > else > - main_ldflags="${wl}-brtl ${wl}-bexpall -lc" > + main_ldflags="${wl}-brtl ${wl}-bexpall" > fi > - shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry -lc" > + ## MAMF: This black magic is clearly not working, removed from main_ldflags to be consistent > + shlib_ldflags="${wl}-brtl ${wl}-G ${wl}-bexpall ${wl}-bnoentry" > SHLIB_LIBADD="\$(LIBM)" > shlib_cxxldflags="${shlib_ldflags}" > if test "${GCC}" = yes; then > > This removes most of the Duplicate symbol messages, although there are still several coming from -lR being included > during the build of the shared libraries (.so files). > > Another group of Duplicate symbols is coming from the -lm flag being too early in the command syntax (autoconf library discovery, so more difficult to "move", or "remove". > > And I expect the logf() failure is from a program that was dynamically linked but the symbol was ignored (as unref/unknown) for some reason. I'll continue looking for that. > > Regards, > Michael > > p.s. is libR still exporting a libc defined symbol? Or is this just very old text? >-- 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