mailing list of musl libc
 help / color / mirror / code / Atom feed
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.)

      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).