[Rd] compile question

[peter dalgaard]

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