Looking over the logs of the IRC discussion, I have to disagree with the
conclusion regarding the bcc-cc1 issue with building the rombios. A quick
review of the docs for bcc give no indication that the cc1 pass of the
compiler either "is" or "is not" intended to to be called directly, though
the documentation does make it clear that it is not necessary to call it
directly. To me, this makes it at least debateable as to whether
or not this is an FHS violation. Frankly there is no reason that bcc-cc1
could not at any time be rolled into the bcc binary, in which case direct
calls to it will break, and while it is a common practice for compilers
to break out their passes as separate executables, this does not
necessarily mean that anything other than the frontend is intended to be
called directly by a user. Looking at the doc file for compiling the
BIOS (docs/xml/PUG/ch_BIOS.xml), it says:
"Only needed the bcc-cc1 phase of the compiler"
but gives no other reason for not calling bcc instead of bcc-cc1.
Anyway, using the line:
bcc -o rombios.s -C-c -D__i86__ -0 -S _rombios_.c
instead of the current:
bcc-cc1 -o rombios.s -c -D__i86__ -0 _rombios_.c
fixes the problem and generates an identical binary image.
One added note, the Makefile assumes that the current directory is on the
path in it's reference to the "dataseghack" script, which is not a valid
assumption.
Shannon C. Dealy | DeaTech Research Inc.
[EMAIL PROTECTED] | - Custom Software Development -
| Embedded Systems, Real-time, Device Drivers
Phone: (800) 467-5820 | Networking, Scientific & Engineering Applications
or: (541) 451-5177 | www.deatech.com
