|
Message-ID: <20160502025834.GJ21636@brightrain.aerifal.cx> Date: Sun, 1 May 2016 22:58:34 -0400 From: Rich Felker <dalias@...c.org> To: Rob Landley <rob@...dley.net> Cc: 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 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
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.