From aixtools at gmail.com  Thu Nov 26 14:38:04 2015
From: aixtools at gmail.com (Michael Felt)
Date: Thu, 26 Nov 2015 14:38:04 +0100
Subject: [Rd] compile question
In-Reply-To: <81EBBC68-83B0-4843-8236-B9141EAA8988@gmail.com>
References: <56535263.4010706@gmail.com> <56538588.40006@gmail.com>
	<81EBBC68-83B0-4843-8236-B9141EAA8988@gmail.com>
Message-ID: <56570B3C.7060108@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)
>
> - 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?



[Rd] compile question
Michael Felt