mailing list of musl libc
 help / color / mirror / code / Atom feed
From: Rich Felker <dalias@aerifal.cx>
To: musl@lists.openwall.com
Subject: Re: R/GNU S: up with a couple hitches...
Date: Thu, 13 Sep 2012 00:41:27 -0400	[thread overview]
Message-ID: <20120913044127.GW27715@brightrain.aerifal.cx> (raw)
In-Reply-To: <36368.132.241.18.70.1347510547.squirrel@lavabit.com>

On Thu, Sep 13, 2012 at 12:29:07AM -0400, idunham@lavabit.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


  reply	other threads:[~2012-09-13  4:41 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-09-13  4:29 idunham
2012-09-13  4:41 ` Rich Felker [this message]
2012-09-13  7:08   ` Daniel Cegiełka
2012-09-15  3:21     ` Isaac Dunham
2012-09-15  3:51       ` Rich Felker
2012-09-15  7:06         ` Isaac Dunham
2012-09-19  4:17           ` idunham
2012-09-15 10:54       ` Daniel Cegiełka
2012-09-19  0:19         ` idunham
2012-09-19  2:59           ` Rich Felker
2012-09-19  4:44             ` idunham
2012-09-19  4:39               ` Rich Felker
2012-11-25 17:58 ` Daniel Cegiełka

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20120913044127.GW27715@brightrain.aerifal.cx \
    --to=dalias@aerifal.cx \
    --cc=musl@lists.openwall.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.vuxu.org/mirror/musl/

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).