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

[Rob Landley]

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?

>> 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

> 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.)

>> @@ -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.

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

Rob