From: Fangrui Song <i@maskray.me>
To: musl@lists.openwall.com
Cc: Rui Ueyama <rui314@gmail.com>
Subject: Re: [musl] `musl-gcc -static` and lld/mold
Date: Sun, 13 Nov 2022 10:30:31 -0800 [thread overview]
Message-ID: <20221113183031.bfropwgg3k52hwma@gmail.com> (raw)
In-Reply-To: <20221113170918.GD7728@brightrain.aerifal.cx>
On 2022-11-13, Rich Felker wrote:
>On Sun, Nov 13, 2022 at 04:51:26PM +0100, Szabolcs Nagy wrote:
>> * Fangrui Song <i@maskray.me> [2022-11-12 19:26:53 -0800]:
>> > On 2022-11-13, Rui Ueyama wrote:
>> > > diff --git a/tools/musl-gcc.specs.sh b/tools/musl-gcc.specs.sh
>> > > index 30492574..ffb46d70 100644
>> > > --- a/tools/musl-gcc.specs.sh
>> > > +++ b/tools/musl-gcc.specs.sh
>> > > @@ -23,7 +23,7 @@ libgcc.a%s %:if-exists(libgcc_eh.a%s)
>> > > crtendS.o%s $libdir/crtn.o
>> > >
>> > > *link:
>> > > --dynamic-linker $ldso -nostdlib %{shared:-shared} %{static:-static}
>> > > %{rdynamic:-export-dynamic}
>> > > +%{!static:-dynamic-linker $ldso} -nostdlib %{shared:-shared}
>> > > %{static:-static} %{rdynamic:-export-dynamic}
>> > >
>> > > *esp_link:
>> >
>> > I use this patch which handles -static-pie as well: https://github.com/MaskRay/musl/tree/musl-gcc
>>
>> i guess you meant
>> https://github.com/MaskRay/musl/commit/e8a9c5489b9be78a4532712045df6f7cd45c4de6
>> (would be nice if it was submitted to the list)
>>
>> >
>> > In addition, I use `*libdir: $libdir` to avoid absolute path references
>> > so that the spec file can be easily fixed after moving the build directory.
>>
>> i think that should only affect the paths used at compile/link time
>> but not paths at runtime:
>>
>> %{static|static-pie:; :-dynamic-linker %(libdir)/libc.so}
>>
>> different runtime path should be a separate option.
>> (just like --syslibdir is separate from --libdir, e.g. syslibdir
>> could be a variable too)
>
>Yes, this change is wrong. Use of $ldso here was very intentional.
I agree for installation purposes using $ldso is better.
However, the main purpose of this change is to allow musl-gcc without `make install`.
I actually also use
*cpp_options:
-nostdinc -isystem %(srcdir)/arch/x86_64 -isystem %(srcdir)/arch/generic -isystem %(srcdir)/include -isystem %(objdir)/obj/include -isystem include%s %(old_cpp_options)
*cc1:
%(cc1_cpu) -isystem %(srcdir)/arch/x86_64 -isystem %(srcdir)/arch/generic -isystem %(srcdir)/include -isystem %(objdir)/obj/include -nostdinc -isystem include%s
so that I can use musl-gcc without installing the headers. It's
assuredly hacky but seems to work well for my learning purpose.
I have the musl-gcc.specs template in my utility directory which I'll
use to overwrite musl configure created musl-gcc.specs :) The repo was
created to give a one-off link to someone asked how to use -static-pie.
>> there is also interference with the -static-pie handling of gcc's
>> driver which might cause trouble when -static and -static-pie is mixed:
>>
>> %{static-pie:-static -pie --no-dynamic-linker -z text}
>
>While musl-target-patched gcc supports -static -pie (or -static with
>default-pie) as static-pie, we can't assume a gcc we're repurposing
>does that, so I think we need to make -static just act as classic
>static (no pie). This can probably be in the "else case" for
>-static-pie though, so that, if both are included, -static-pie takes
>precedence.
In glibc gcc, -static-pie -static are not supposed to be used together.
Using both will pass -static -pie --no-dynamic-linker to ld while
crtbeginT.o (only intended for -static) is used, likely causing a linker
error.
(Similarly, while it appears that the default spec file let -shared override -pie/-static/-static-pie
-shared -static cannot be used together in practice because of crtbeginT.o.)
>Note that we can't just implement the desired behavior for -static
>afaict because it requires existence of --no-dynamic-linker, which the
>host ld might not have. So, something like:
>
>*link:
>-nostdlib %{static-pie:-static -pie --no-dynamic-linker -z text;%{static:-static;-dynamic-linker $ldso %{shared:-shared}}} %{rdynamic:-export-dynamic}
>
GNU ld has --no-dynamic-linker since 2.26 (2015)/lld has it since 2017
so I do not worry about the portability that much. If a user really
uses a very old linker, they can change the musl-gcc.specs file
themselves. (The file is for convenience not fully supported AIUI.)
prev parent reply other threads:[~2022-11-13 18:30 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-11-13 0:11 Rui Ueyama
2022-11-13 0:38 ` Rich Felker
2022-11-13 0:46 ` Rui Ueyama
2022-11-13 0:55 ` Rui Ueyama
2022-11-13 3:26 ` Fangrui Song
2022-11-13 15:51 ` Szabolcs Nagy
2022-11-13 17:09 ` Rich Felker
2022-11-13 18:30 ` Fangrui Song [this message]
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=20221113183031.bfropwgg3k52hwma@gmail.com \
--to=i@maskray.me \
--cc=musl@lists.openwall.com \
--cc=rui314@gmail.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).