[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20151108005833.GG3818@brightrain.aerifal.cx>
Date: Sat, 7 Nov 2015 19:58:33 -0500
From: Rich Felker <dalias@...c.org>
To: musl@...ts.openwall.com
Subject: Re: [PATCH] don't define SHARED macro in the source
On Sat, Nov 07, 2015 at 11:24:56PM +0000, Petr Hosek wrote:
> We don't support static pie in our toolchain so I haven't really tested
> that scenario but now I see why the SHARED macro is needed here.
>
> One option around this issue would be to avoid building rcrt1.c altogether,
> but I'd like to avoid carrying an extra patch for that. The other option
> would be to allow inline assembly in this case since it seems to be only
> used as a guard. I'll see if the second option is feasible.
As part of this release cycle, I plan to, by default, use the same .o
files (built as PIC) for both libc.so and libc.a, and remove the
SHARED macro. --disable-pic would then both imply --disable-shared and
inhibit building of rcrt1.o. I could add a separate
--disable-static-pie if you want to be able to use PIC but not static
pie (not generate rcrt1.o) and your arch could force all of these, but
my guess is that there's no such thing as PIC vs non-PIC for pnacl and
it's some kind of higher-level byte code. Anyway, does that sound
reasonable?
BTW, how are you doing cancellation without asm?
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.
