[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160503180230.GL21636@brightrain.aerifal.cx>
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.
