Date: Tue, 3 May 2016 14:02:30 -0400 From: Rich Felker <dalias@...c.org> To: musl@...ts.openwall.com, j-core@...ore.org Subject: Re: musl-cross-make / litecross improvements On Tue, May 03, 2016 at 01:39:43PM +0200, Szabolcs Nagy wrote: > * Rich Felker <dalias@...c.org> [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
Powered by blists - more mailing lists
Confused about mailing lists and their use? Read about mailing lists on Wikipedia and check out these guidelines on proper formatting of your messages.