From mboxrd@z Thu Jan 1 00:00:00 1970 X-Msuck: nntp://news.gmane.org/gmane.linux.lib.musl.general/9985 Path: news.gmane.org!not-for-mail From: Rich Felker Newsgroups: gmane.linux.lib.musl.general Subject: Re: musl-cross-make / litecross improvements Date: Tue, 3 May 2016 14:02:30 -0400 Message-ID: <20160503180230.GL21636@brightrain.aerifal.cx> References: <20160503044835.GA5517@brightrain.aerifal.cx> <20160503113942.GS22574@port70.net> 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 1462298576 23882 80.91.229.3 (3 May 2016 18:02:56 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Tue, 3 May 2016 18:02:56 +0000 (UTC) To: musl@lists.openwall.com, j-core@j-core.org Original-X-From: musl-return-9998-gllmg-musl=m.gmane.org@lists.openwall.com Tue May 03 20:02:56 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 1axeet-0002YT-4M for gllmg-musl@m.gmane.org; Tue, 03 May 2016 20:02:55 +0200 Original-Received: (qmail 3563 invoked by uid 550); 3 May 2016 18:02:50 -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 3538 invoked from network); 3 May 2016 18:02:48 -0000 Content-Disposition: inline In-Reply-To: <20160503113942.GS22574@port70.net> User-Agent: Mutt/1.5.21 (2010-09-15) Original-Sender: Rich Felker Xref: news.gmane.org gmane.linux.lib.musl.general:9985 Archived-At: On Tue, May 03, 2016 at 01:39:43PM +0200, Szabolcs Nagy wrote: > * Rich Felker [2016-05-03 00:48:36 -0400]: > > I've made a number of improvements and fixes to musl-cross-make which > > are in the upstream repo now, based on bug reports I got: > > > > - Spurious dependency on flex (upstream's fault, worked around) > > - Spurious dependency on texinfo (ditto) > > gcc assumes you want to install info files if BUILD_INFO > is set, which is set based on MAKEINFO, however you cannot > override that, because the configure script will find a > working makeinfo if there is one on the system anyway.. I'd certainly like cleaner solutions to this problem if you have any. Overriding these things as make variables is quite powerful and might be able to do it. > explicit gcc_cv_prog_makeinfo_modern=no solves this in gcc > directories. (the man pages are still installed) Yeah, it'd be nice to suppress them too, especially if they're out of sync with the patched docs when makeinfo is unavailable. > possibly make -o info -o install-info -o install-man > can do this too (havent tested). The -o approach only works when it's added to $(MAKE), because make explicitly strips -o's from being passed down recursively in MAKEFLAGS etc. > > - Ability to use pre-installed gmp/mpc/mpfr libs > > - Config examples for static linking, no-debug builds. > > this is not enough: > COMMON_CONFIG += CFLAGS="-g0 -Os" CXXFLAGS="-g0 -Os" LDFLAGS="-s" > > target libs still have the full debug path in them, > for that you also need: > COMMON_CONFIG += CFLAGS_FOR_TARGET="-g0 -Os" CXXFLAGS_FOR_TARGET="-g0 -Os" LDFLAGS_FOR_TARGET="-s" Generally you _do_ want debug info for target libs. If we want to keep bogus paths linked to the build system out of it, gcc has an option to fake these (strip a leading prefix) that we could use, I think. Overall, I'm not trying to strip build system paths from a hard-core privacy perspective because it seems too hard to do reliably. Users who really want to do that can use a symlink under /tmp for the build dir, I think. I mainly just want to avoid outwardly wrong behavior and printing paths that don't make sense. But these are minor issues I really don't want to spend time on since I have more productive things to be doing. :-) > i'm not sure if it's a good idea distributing the > toolchain without debug info, but this is needed > if you want to avoid leaking the build path. It wouldn't hurt to dig up the gcc option to strip a prefix from the debug paths and including an example of how to use it, in case users want this. > > Let me know if any major bugs/inconveniences remain that I should > > prioritize fixing. > > the target libs are installed under lib64/, > i think the usr/ and lib64/ symlinks are useful > (so it can be used as rootfs without fiddling > with etc/ld-musl*.path). Yes. Is there a good way to override that in gcc or should we just make the symlinks? > i think > GCC_CONFIG += --disable-gnu-indirect-function > is important, otherwise libatomic will be broken. Bleh, this should really be in the musl support patches, but I'll just add it here for now. > gcc-6 will need > GCC_CONFIG += --disable-libmpx OK. Is that because their code is broken, or because of something on musl's side? Is it detectable? > and libstdc++ only uses vdso clock_gettime > with --enable-libstdcxx-time Is there a link to this issue? I don't mind adding it but I'd like to know details. > diff --git a/litecross/Makefile b/litecross/Makefile > index fbabe4a..d2a7bce 100644 > --- a/litecross/Makefile > +++ b/litecross/Makefile > @@ -17,6 +17,7 @@ MUSL_CONFIG = CC="$(XGCC)" LIBCC="../obj_toolchain/$(TARGET)/libgcc/libgcc.a" -- > > MAKE += INFO_DEPS= infodir= > MAKE += ac_cv_prog_lex_root=lex.yy.c > +MAKE += gcc_cv_prog_makeinfo_modern=no Does this make a difference? > FULL_TOOLCHAIN_CONFIG = $(TOOLCHAIN_CONFIG) \ > --disable-werror \ > @@ -132,10 +133,16 @@ obj_toolchain/.lc_built: | obj_toolchain/.lc_configured obj_sysroot/.lc_libs > cd obj_toolchain && $(MAKE) MAKE="$(MAKE)" LC_ROOT=$(PWD) > touch $@ > > -install-musl: | obj_musl/.lc_built > +.lc_target_links: > + mkdir -p $(DESTDIR)$(OUTPUT)/$(TARGET) > + ln -sf . $(DESTDIR)$(OUTPUT)/$(TARGET)/usr > + ln -sf lib $(DESTDIR)$(OUTPUT)/$(TARGET)/lib64 > + touch $@ > + I think rather than using a stamp file we can just make lib64 itself a target: install-*: $(DESTDIR)$(OUTPUT)/$(TARGET)/lib64 $(DESTDIR)$(OUTPUT)/$(TARGET)/lib64: mkdir -p $(dir $@) mkdir -p $(patsubst %64,%,$@) ln -sf lib $@ or similar. > +install-musl: | obj_musl/.lc_built .lc_target_links > cd obj_musl && $(MAKE) $(MUSL_VARS) DESTDIR=$(DESTDIR)$(OUTPUT)/$(TARGET) install Installation of musl doesn't seem to depend on the links; only gcc does (because it installs stuff to lib64). Rich