Subject: [alpine-devel] Package request: R

From: Alba Pompeo <[email-masked]>
Date: Mon, 25 Jan 2016 22:53:24 -0200

I like to request the package R from https://www.r-project.org/
It's very important for my work in statistics and I would be happy if
we had it on Alpine. Thanks.

Ciao.

---
Unsubscribe:  [email-masked]
Help:         [email-masked]
---

---

From: Alba Pompeo <[email-masked]>
Date: Tue, 26 Jan 2016 11:17:55 -0200

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
`__libc_stack_end'
/usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld:
../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
/usr/lib/gcc/x86_64-alpine-linux-musl/5.3.0/../../../../x86_64-alpine-linux-musl/bin/ld:
final link failed: Bad value
collect2: error: ld returned 1 exit status

Ciao.

---

---

From: Isaac Dunham <[email-masked]>
Date: Tue, 26 Jan 2016 06:54:47 -0800

> packager should easily make an APKBUILD for everyone.

I've tried building R for musl in the past; however, that was a few years
ago, and it failed some of the tests. (IIRC, I was using gcc/gfortran 4.2
or a 3.4.x-based toolchain.)
Because of that, I figured my build was unreliable.

Passing 'make test' is an important step, despite being optional
(not to mention impossible for cross-compiling).

> The error.

You missed the command; there's no way to help without it. (It's also good
to know what configure options, CFLAGS, and LDFLAGS you used.)

There should be something along the lines of with 'gcc ... <a>.o <b>.o ...
-l<lib> -lc' .

---

---

From: Isaac Dunham <[email-masked]>
Date: Wed, 27 Jan 2016 19:19:11 -0800

> `__libc_stack_end' can not be used when making a shared object;

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:
 export r_cv_libc_stack_end=no
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.

HTH,
Isaac Dunham

---