not have setprogname(3) and getprogname(3), and we need to build
lint(1) as a cross-tool to bootstrap. Versions from lib/libc/gen
can't be compiled either.
PR: bin/36747
(See commit log for usr.bin/xlint/Makefile,v 1.11 for what was wrong
with enabling build of lint libraries in rev. 1.12.)
This fixes cross-arch compiles (running binaries for a different arch
when generating lint.7 and lint libraries) and cross-branch compiles
(4.x -> 5.0 buildworld should be working again).
this in this file is the correct way round. (Maybe our definition of
__assert is wrong?)
Anyway, perhaps we should revisit this later. For the time being,
building lint libraries here does not blow up.
to enable this.
1: it was running xlint out of the object directory, which is not
safe (ie: run a 5.x binary on a 4.x world - no libc.so.5, or run an
alpha binary on x86).
2: lint has /usr/libexec/lint1 and /usr/libexec/lint2 hard coded in.
This is the same as problem 1.
3: lint has got /usr/bin/cc hard coded in as well. Also, see problem 1.
There are probably more problems, but these are enough of a showstopper.
Set LINT to the obj path, since we need to use the new lint's features
to create .ln files. We do not want to use the installed version for that,
since that might create files according to the old lint.
This is still a work in progress to clean this all up, but it gets
through buildworld, which was the problem at hand.
Call cc -E, not cpp, this allows lint to be unaware of any
machine-dependent defines that cc(1) may normally define.
Change fork() to vfork() and exit() to _exit().
Reuse temporary file so that multiple files passed can be processed without
problems.
files. Mostly -I${.CURDIR} was needed -- especially for YACC generated
files as the new cpp does not look in the ultimate source file
(ie, the .y file)'s directory as told by the "#line" directive. Some were
misspellings of "-I${.CURDIR}" as "-I.".
