[<prev] [next>] [thread-next>] [day] [month] [year] [list]
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.
