[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20120913044127.GW27715@brightrain.aerifal.cx>
Date: Thu, 13 Sep 2012 00:41:27 -0400
From: Rich Felker <dalias@...ifal.cx>
To: musl@...ts.openwall.com
Subject: Re: R/GNU S: up with a couple hitches...
On Thu, Sep 13, 2012 at 12:29:07AM -0400, idunham@...abit.com wrote:
> Cleaning up my Drafts folder, I found this:
>
> I decided to give my gcc-3.4 build a workout (including the g77 fortran
> compiler) by building R (a/k/a GNU S).
> R is a fairly large stats package that uses C and Fortran.
> Here are the issues I encountered:
> 1. iconv() needs UCS-* support: I used
> LD_PRELOAD=preloadable_libiconv.so
Hmm, which UCS-* is musl missing? It's supposed to be there.
> 2. __libc_stack_end is *apparently* assumed present on linux, rather than
> properly checked for. (This breaks build in src/unix/system.c) So you need
> to change (in src/include/config.h)
> #define HAVE_LIBC_STACK_END 1
> to
> #undef HAVE_LIBC_STACK_END
I think this is another case of improper use of an internal symbol. In
case we do want to add support for it though, do you know if it's
supposed to be a symbol whose address is the end of the stack, or a
pointer variable pointing to the end of the stack? My guess would be
the latter since the former isn't really possible if the kernel can
randomize the stack location.
> There is fallback code, but currently it seems to just be guessing the
> location of the stack end (if I understand properly).
Basically if the stack grows downward, any address >= an automatic
variable's address is also a stack address. This is true on any
platform I know of.
> After these, R builds. It runs, but does not pass tests.
Any idea why?
Rich
Powered by blists - more mailing lists
Confused about mailing lists and their use?
Read about mailing lists on Wikipedia
and check out these
guidelines on proper formatting of your messages.
