[Prev][Next][Index][Thread]
[PATCH] GCC driver script problems
In the course of packaging the OSKit for Debian, I've made a couple of
small changes to the OSKit's GCC wrapper script.
First, a bug fix: it seems that on some machines, i[3456]86-oskit-gcc was
not running properly, causing cpp processes to spawn indefinitely. The
problem was that the gcc wrapper script specified the -B option to gcc as
well as set the GCC_EXEC_PREFIX envrionment variable. GCC's behavior (as
defined for 2.7.2.3 and 2.95.2, at the very least) is to first check
for a specs file and for relevant binaries (cpp, cc1, etc.) in the
prefix specified by -B, with the ability to fall back to GCC_EXEC_PREFIX
if set. Thus, when i[3456]86-oskit-gcc was being called, the specs file
was located, but the binaries were unavailable. This is remedied by not
setting the GCC_EXEC_PREFIX envar, causing OSKit to find the correct specs
file at the location specified by -B, and being able to fall back to its
defaults to find its support binaries.
The remaining changes were primarily cosmetic, but may be of interest: I
changed the wrapper script's name from i[3456]86-oskit-gcc to
x86-oskit-gcc. Although I am building on an i686, it may be confusing for
users of other x86-class chips to be forced to refer to it as
i686-oskit-gcc. Since there is nothing to the specs file which is
CPU-specific, i decided to use ARCH instead. Also, I have moved the specs
file from /usr/specs (it's against debian policy to put files in /usr;
even if it wasn't, i still like to keep things sorted as logically as
possible) to /usr/lib/gcc-lib/x86-oskit/specs. This has the added benefit
of being consistent with standard locations for other compilers and
cross-compilers. To reflect that change, I updated gcc-driver-script.in as
well.
The patch isn't the most elegant ever, but it works, and it gives an idea
of what I was trying to do. Optimally, it'd be nicer to define
gcc_specdir at a higher level (eg., in configure.in) so that
unsupported/scripts/gcc-driver-script.in and unsupported/GNUmakerules
could reference it from one location, etc.
Anyway, I thought it'd be important to get that bugfix out in the open,
since that bug affects every Debian machine i've tried it on. Feel free to
give me feedback on the patch -- it seems to work fine on all the systems
i could get my hands on.
Thanks,
Ed Boraas.
gccwrapper.diff.gz