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 <aixto...@gmail.com> wrote:
> On 2015-11-23 23:43, peter dalgaard wrote:
>>> On 23 Nov 2015, at 22:30 , aixtools<aixto...@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@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@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....@cbs.dk Priv: pda...@gmail.com
______________________________________________
R-devel@r-project.org mailing list
https://stat.ethz.ch/mailman/listinfo/r-devel
