[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20160501171554.GI21636@brightrain.aerifal.cx>
Date: Sun, 1 May 2016 13:15:55 -0400
From: Rich Felker <dalias@...c.org>
To: j-core@...ts.j-core.org, musl@...ts.openwall.com
Subject: Re: [J-core] updated cross-compiler build system
On Sun, May 01, 2016 at 05:38:04PM +0200, Szabolcs Nagy wrote:
> * Rich Felker <dalias@...c.org> [2016-05-01 01:45:02 -0400]:
> > I've just pushed the new overhaul of musl-cross-make, my cross
> > compiler build system:
> >
> > https://github.com/richfelker/musl-cross-make
> >
> > This should make it faster (single-stage), safer (https and hash
> > checking), simpler (built-in fetching of gmp & friends), and cleaner
> > to build and install cross compilers that can be used to target J-core
> > Linux. The sh2eb-linux-muslfdpic target profile in the sample
> > config.mak(.dist) file is all you need to select and use. As usual it
> > also should work for all other (non J-core) musl targets too.
> >
> > I've tested it pretty extensively on two systems I use for builds, but
> > as this is a big change/overhaul there might be things that break. Let
> > me know how using it goes.
>
> nice
>
> i made some mods:
>
> 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?
> 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.
> src_mpfr dep was wrong.
Thanks.
> i like saving the build log, but 2>&1 might not be what
> everybody wants.
Indeed; see below for more thoughts on it:
> and linux headers are often needed to build things so
> there could be an install target for it:
I was thinking of this too, but it would be nice to be able to get
just the headers rather than the whole Linux source tree. I think one
or more musl-based distros might already have a stripped-down package
we could fetch, if the hosting is suitable.
> install-linuxheaders: install-toolchain
> case $(TARGET) in \
> i*86* | x86_64* | x32*) A=x86 ;; \
> arm*) A=arm ;; \
> aarch64*) A=arm64 ;; \
> mips*) A=mips ;; \
> or1k*) A=openrisc ;; \
> sh* | j[24]*) A=sh ;; \
> powerpc* | ppc*) A=powerpc ;; \
> microblaze*) A=microblaze ;; \
> esac; \
> $(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.
> diff --git a/Makefile b/Makefile
> index e85ccba..adac3c1 100644
> --- a/Makefile
> +++ b/Makefile
> @@ -130,7 +130,7 @@ $(BUILD_DIR)/config.mak: | $(BUILD_DIR)
> "-include ../config.mak"
>
> all: | $(SRC_DIRS) $(BUILD_DIR) $(BUILD_DIR)/Makefile $(BUILD_DIR)/config.mak
> - cd $(BUILD_DIR) && $(MAKE) $@
> + cd $(BUILD_DIR) && $(MAKE) $@ 2>&1 |tee -a build.log
Logging should probably either be left to the user or sent to a file
specific to the build directory rather than saved in the top-level
directory. The supported/intended use for the future is that you can
omit TARGET= in config.mak and instead have conditionals for he
settings you want for different targets, then do things like:
make TARGET=i486-linux-musl all
and have that build end up in its own isolated dir. It shouldn't be
hard to add "make TARGETS='a b c ...'" support too if desired using
another level of recursion, or even make target tuple names act as
make targets when $(TARGET) is unset.
> @@ -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...
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.
