From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Spam-Checker-Version: SpamAssassin 3.4.2 (2018-09-13) on inbox.vuxu.org X-Spam-Level: X-Spam-Status: No, score=-3.0 required=5.0 tests=HEADER_FROM_DIFFERENT_DOMAINS, MAILING_LIST_MULTI,RCVD_IN_DNSWL_MED,RCVD_IN_MSPIKE_H3, RCVD_IN_MSPIKE_WL autolearn=ham autolearn_force=no version=3.4.2 Received: from mother.openwall.net (mother.openwall.net [195.42.179.200]) by inbox.vuxu.org (OpenSMTPD) with SMTP id 87b7dc53 for ; Sat, 18 Jan 2020 21:55:10 +0000 (UTC) Received: (qmail 28489 invoked by uid 550); 18 Jan 2020 21:55:09 -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 28470 invoked from network); 18 Jan 2020 21:55:08 -0000 Date: Sat, 18 Jan 2020 16:54:55 -0500 From: Rich Felker To: musl@lists.openwall.com Message-ID: <20200118215455.GZ30412@brightrain.aerifal.cx> References: <20200118051447.GV30412@brightrain.aerifal.cx> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.21 (2010-09-15) Sender: Rich Felker Subject: Re: [musl] Absolute symlink breaks cross compilation On Sat, Jan 18, 2020 at 11:27:43AM -0800, Khem Raj wrote: > On Fri, Jan 17, 2020 at 9:15 PM Rich Felker wrote: > > > > On Sat, Jan 18, 2020 at 02:24:49AM +0300, Андрей Аладьев wrote: > > > Hello. Gentoo users find that it is not possible to cross compile musl. See > > > here https://bugs.gentoo.org/645626 more details. > > > > > > I am sending to you proposed patch that is related to upstream. Please keep > > > all installed symlinks relative. Thank you. > > > > > diff --git a/Makefile b/Makefile > > > index bd8f5c38..81bf33d5 100644 > > > --- a/Makefile > > > +++ b/Makefile > > > @@ -209,7 +209,7 @@ $(DESTDIR)$(includedir)/%: $(srcdir)/include/% > > > $(INSTALL) -D -m 644 $< $@ > > > > > > $(DESTDIR)$(LDSO_PATHNAME): $(DESTDIR)$(libdir)/libc.so > > > - $(INSTALL) -D -l $(libdir)/libc.so $@ || true > > > + $(INSTALL) -D -l $$(realpath --no-symlinks --relative-to=$$(dirname $@) $(DESTDIR)$(libdir)/libc.so) $@ || true > > > > > > install-libs: $(ALL_LIBS:lib/%=$(DESTDIR)$(libdir)/%) $(if $(SHARED_LIBS),$(DESTDIR)$(LDSO_PATHNAME),) > > > > > > > I don't understand what you mean by it "breaks cross compilation". The > > ldso link produced is not used for compiling anything; it's only used > > for executing programs, which you don't do when cross compiling musl > > or cross compiling applications against it. The link is setup to be > > installed on the $host, not to be used on the $build where it's not > > needed. > > > > Could you could explain what specifically you're trying to do that's > > not working as desired? > > > > If you look at commit msg > for https://github.com/kraj/musl/commit/102f35b194a3405b30001ff08cfd54752179376f > > then you will see the usecase we have in for Yocto/OE OK. So it's specifically execution of target binaries via qemu-user that's broken. The above patch isn't suitable because it introduces a dependency on a nonstandard utility, GNU realpath, and thereby breaks cross compiling of musl from non-GNU-like systems. It also might introduce dependencies of the staged-area symlink structure into the link contents. I'd probably be happy with a solution that involves a make or shell expression to convert $(syslibdir) into a suitable number of repetitions of ../ to prepend to $(libdir)/libc.so, but I'm mildly concerned about whether there may be setups with symlinks where this breaks. There's also always been a school of thought that the direction of the symlink should be reversed, so that libc.so is the symlink and ldso is the actual file, but I believe I tried to do this at least once and ran into reasons it was problematic. I'd have to go dig up old conversations to try to remember why... Rich