Fine, just closed the Debian bug report and sent a patch to savannah

On Sat, Apr 13, 2002 at 08:26:02PM -0700, Shannon C. Dealy wrote:
> 
> 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
> 
> 
> 

-- 
Robert Millan

Reply via email to