[J-core] [musl] updated cross-compiler build system

[Rich Felker]

On Sun, May 01, 2016 at 06:50:55PM -0500, Rob Landley wrote:
> On 05/01/2016 12:15 PM, Rich Felker wrote:
> > 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?
> 
> Did you check that it doesn't wind up hard-wired into the binaries?

Either way it's not used at runtime, but the value is shown by gcc -v
since --with-build-sysroot was on the configure command line which
gets saved. In my version, only the unexpanded make var appears there.
It's not a big deal, but I'd rather not leak the builder's directory
structure in binaries. Obviously fully suppressing this requires
either use of -g0 or the gcc options to fake paths for debug info.

> >> 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.
> 
> I've been patching that out of the binutils I build for over 10 years
> and they STILL haven't fixed it upstream.
> 
> https://github.com/landley/aboriginal/blob/master/sources/patches/binutils-screwinfo.patch

If you're using this approach I think you should just remove the line
rather than "exit 0"; otherwise no output file is created and thus the
make rule that triggered it will keep getting run. An empty output
file is probably better.

Maybe a better approach, though, would be putting a fake makeinfo
shell script in the build system and passing in MAKEINFO=our_fake.

> > 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.
> 
> You _are_ allowed to have a for-linus-nonsh bratch with patches to go
> upstream outside the arch/sh directory. Just submit it as a separate
> pull request.
> 
> (Me, I mail patches to Andrew Morton, who is more or less the designated
> nongit input point to the kernel integration process.)

I assumed somebody wants that broken behavior. It's easy enough to
work around with a staged install, anyway, but I might try to get it
fixed at some point.

> >> @@ -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 don't understand? Your _destination_ must exist. Your source can more
> or less be an arbitrary string.

Except the empty string. Linux's symlink(2) fails with ENOENT when the
source is a zero-length string. I'm skeptical whether this behavior is
conforming.

> $ ln -s "martha the whistling tapeworm/////" fred
> $ ls -l fred
> lrwxrwxrwx 1 landley landley 31 May  1 18:49 fred -> martha the
> whistling tapeworm/////

Try ln -s "" fred

Rich