From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=0.7 required=5.0 tests=MAILING_LIST_MULTI, RCVD_IN_MSPIKE_H2,URIBL_BLACK autolearn=no autolearn_force=no version=3.4.4 Received: (qmail 24724 invoked from network); 13 Nov 2022 18:30:49 -0000 Received: from second.openwall.net (193.110.157.125) by inbox.vuxu.org with ESMTPUTF8; 13 Nov 2022 18:30:49 -0000 Received: (qmail 12155 invoked by uid 550); 13 Nov 2022 18:30:46 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Reply-To: musl@lists.openwall.com Received: (qmail 12123 invoked from network); 13 Nov 2022 18:30:45 -0000 X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=in-reply-to:content-disposition:mime-version:references:message-id :subject:cc:to:from:date:x-gm-message-state:from:to:cc:subject:date :message-id:reply-to; bh=HgDhpx/CRApZ3hdwQSJ7gHvZsMaj+Wm+K0vWx7LqMZo=; b=EvJPEL+1bhQKY5O3nDwb9cgPs5yJL1I5yYOj/ndGTuvIhDiUrqTjIV52B+CdPViDon Lt5Oe3P38x26dImMsq6skSzyGb/GPr0WTzOmijiVNtTaOZHy6DGxxV5XBnF87/4uOb8X bJ9d9l6NaJfBMUH722Eja50R6dEG/8sHyEKe6nlVRZx8BbuENspP/8f7eNu5eGEvxLuM 8PjkaFC3e8sCea5qJz8e5w7hhXFOmUBSNOxYxHHN239m5jaA4lZNtNGAV7V0VRsbmtYA l2oNXmQzOejXRprX5MKQQHRaqEEb+8HVAcF2baCWoY4TvNy2SCCGoTCgHTDiSBWEziiy xdQQ== X-Gm-Message-State: ANoB5pmDSfH2iRhX4aAp94oMTXyettvPo3GyvtH0lVi+IE+eH8s3+iq9 Gu0220IimfKiIdVFhNB2/5R6acxpxuI= X-Google-Smtp-Source: AA0mqf6WtaejPdbTEQiFJyw8qiK99TeKep5sSnobptgn4TaWmNbd2ji2qB/ue6VPSqIltT6I+yIbkw== X-Received: by 2002:a63:4d1c:0:b0:462:e0d0:2582 with SMTP id a28-20020a634d1c000000b00462e0d02582mr9070954pgb.48.1668364232630; Sun, 13 Nov 2022 10:30:32 -0800 (PST) Date: Sun, 13 Nov 2022 10:30:31 -0800 From: Fangrui Song To: musl@lists.openwall.com Cc: Rui Ueyama Message-ID: <20221113183031.bfropwgg3k52hwma@gmail.com> References: <20221113003813.GL29905@brightrain.aerifal.cx> <20221113032653.6qz4hqh3nfm25tpt@gmail.com> <20221113155126.GF98588@port70.net> <20221113170918.GD7728@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Content-Disposition: inline In-Reply-To: <20221113170918.GD7728@brightrain.aerifal.cx> Subject: Re: [musl] `musl-gcc -static` and lld/mold On 2022-11-13, Rich Felker wrote: >On Sun, Nov 13, 2022 at 04:51:26PM +0100, Szabolcs Nagy wrote: >> * Fangrui Song [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.)