On Tue, Jan 26, 2016 at 11:17:55AM -0200, Alba Pompeo wrote:
> I tried to compile the source myself, but it appears R doesn't play
> well with musl.
> Can someone please help? If we can compile from source, then a
> packager should easily make an APKBUILD for everyone.
> The error.
> ../unix/system.o: In function `Rf_initialize_R':
> /home/albap/R-3.2.3/src/unix/system.c:185: undefined reference to
> ../unix/system.o: relocation R_X86_64_PC32 against undefined symbol
> `__libc_stack_end' can not be used when making a shared object;
> recompile with -fPIC
Looking over things online, this is a (very longstanding) abuse of a private
glibc symbol in R.
When I tried building R, there was fallback code and a config.h 'feature
guard', but no proper configure test (undef HAVE_LIBC_STACK_END).
In R 3.2.3, it seems that configure is trying to test for it on Linux.
It apparently fails to accurately test (as demonstrated by your link error),
perhaps because the test program does not actually *use* __libc_stack_end
so it gets optimized out. (See line 35500 or so in R-3.2.3/configure.)
Ideally, the test program would check that a pointer to __libc_stack_end
is non-null, but that's an autoconf bug.
To work around the broken test, run:
before configuring R.
Once you have it building, it would be good to report the issues you had
with building--and results of "make check"--to the R mailing list.
(And make *sure* that it *doesn't* pick up OpenBLAS; that would not
help with getting support any.)
Here, I'm seeing a couple little issues with non-ASCII text and a *lot*
of math differences, many of which say
"*no* convergence: NOTIFY R-core!"
Until these are resolved, packaging R is not a good idea.
But having only completed basic stats, I wouldn't have a clue about what
to do; you would probably be the best person to bring these up.
Received on Wed Jan 27 2016 - 19:19:11 UTC