From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9975 Path: news.gmane.org!not-for-mail From: Szabolcs Nagy Newsgroups: gmane.linux.lib.musl.general Subject: Re: Re: [J-core] [musl] updated cross-compiler build system Date: Sun, 1 May 2016 23:55:22 +0200 Message-ID: <20160501215521.GQ22574@port70.net> References: <20160501054502.GA4059@brightrain.aerifal.cx> <20160501153804.GP22574@port70.net> <20160501171554.GI21636@brightrain.aerifal.cx> Reply-To: musl@lists.openwall.com NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1462139742 8298 80.91.229.3 (1 May 2016 21:55:42 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sun, 1 May 2016 21:55:42 +0000 (UTC) Cc: j-core@lists.j-core.org To: musl@lists.openwall.com Original-X-From: musl-return-9988-gllmg-musl=m.gmane.org@lists.openwall.com Sun May 01 23:55:37 2016 Return-path: Envelope-to: gllmg-musl@m.gmane.org Original-Received: from mother.openwall.net ([195.42.179.200]) by plane.gmane.org with smtp (Exim 4.69) (envelope-from ) id 1awzKy-0001RV-JD for gllmg-musl@m.gmane.org; Sun, 01 May 2016 23:55:36 +0200 Original-Received: (qmail 17462 invoked by uid 550); 1 May 2016 21:55:34 -0000 Mailing-List: contact musl-help@lists.openwall.com; run by ezmlm Precedence: bulk List-Post: List-Help: List-Unsubscribe: List-Subscribe: List-ID: Original-Received: (qmail 17444 invoked from network); 1 May 2016 21:55:33 -0000 Mail-Followup-To: musl@lists.openwall.com, j-core@lists.j-core.org Content-Disposition: inline In-Reply-To: <20160501171554.GI21636@brightrain.aerifal.cx> User-Agent: Mutt/1.5.24 (2015-08-30) Xref: news.gmane.org gmane.linux.lib.musl.general:9975 Archived-At: * Rich Felker [2016-05-01 13:15:55 -0400]: > On Sun, May 01, 2016 at 05:38:04PM +0200, Szabolcs Nagy wrote: > > changed $$(LC_ROOT) to $${LC_ROOT} because it seems to > > be passed to bash in config.status (as $$(, \$( and $( > > and the last one executes LC_ROOT as a command, this > > might be an autoconf bug: it does not escape the args > > correctly) > > I noticed that too but didn't get around to looking into the details > since nothing broke. The whole point though is to _avoid_ it getting > expanded in places like config.status -- I was trying to keep the > absolute path to the top-level dir from getting saved anywhere in the > build tree, so that it can safely be moved. Do you know if your change > preserves this property? > the only difference i see is the --with-build-sysroot in gcc -v output has abs path in my version, but otherwise strings gcc |grep / has the same output. > > for me make fails in bfd/doc despite MAKINFO=false, but > > the export AM_MAKEFLAGS=INFO_DEPS= hack fixed it. > > Uhg, yes, I just installed texinfo on my VPS and forgot to check the > case where it's missing. > this hack is not ok in general as Makefile.am might have its own AM_MAKEFLAGS. > > $(MAKE) -C ../src_linux headers_install ARCH=$$A \ > > CROSS_COMPILE=$(DESTDIR)$(OUTPUT)/$(TARGET)- \ > > INSTALL_HDR_PATH=$(DESTDIR)$(OUTPUT)/$(TARGET) > > AFAIK you don't need CROSS_COMPILE= to install headers, and in > principle it shouldn't be there because the install targets are not > intended to depend on each other. But you do need to install to a > staging dir and then copy to the final dest; the broken > headers_install target in Linux rm's the scsi headers (eew) provided > by libc and fails to provide replacements. > i see > > @@ -55,13 +55,13 @@ src_musl: | $(MUSL_SRCDIR) > > ln -sf $(MUSL_SRCDIR) $@ > > > > src_gmp: | $(GMP_SRCDIR) > > - ln -sf "$(GMP_SRCDIR)" $@ > > + ln -sf $(GMP_SRCDIR) $@ > > > > src_mpc: | $(MPC_SRCDIR) > > - ln -sf "$(MPC_SRCDIR)" $@ > > + ln -sf $(MPC_SRCDIR) $@ > > > > -src_mpfr: | $(GMP_SRCDIR) > > - ln -sf "$(MPFR_SRCDIR)" $@ > > +src_mpfr: | $(MPFR_SRCDIR) > > + ln -sf $(MPFR_SRCDIR) $@ > > The dep was wrong, but the quoting was intentional, albeit untested. > The idea was to make broken symlinks that would then ENOENT out if the > caller does not want to provide these libs (i.e. wants to use the > system ones). But apparently symlink(2) fails with ENOENT in this > case, so I need a new solution... i see