Observed with rev 6727 on Ubuntu 11.04 and OS X 10.6.8
I am not 100% certain whether this is a problem with the front end or with sdcpp:
- sdcc -M <infile> -o <outfile> tries to invoke sdcpp a'la GNU: The outfile is passed as the second non-option argument causing an error. The same happens with -E and -MM
- According to the gnu cpp docs, the second non-option argument is interpreted as a file to store the preprocessor output (identical to -o)
- None of the sdcpp docs seem to suggest the same, I've only seen references to -o as the method to control output
To reproduce this all we need is an empty file
we can then do
sdcc -M foo.c -o foo.o -V
+ "/usr/local/bin/sdcpp" -nostdinc -Wall -M -obj-ext=.rel -DSDCC_MODEL_SMALL -DSDCC_FLOAT_REENT -DSDCC=304 -DSDCC_REVISION=6726 -DSDCC_mcs51 -D__mcs51 -isystem "/usr/local/bin/../share/sdcc/include/mcs51" -isystem "/usr/local/share/sdcc/include/mcs51" -isystem "/usr/local/bin/../share/sdcc/include" -isystem "/usr/local/share/sdcc/include" "foo.c" "foo.d"
sdcpp: error: too many filenames given. Type sdcpp --help for usage
So this is either sdcpp misinterpreting the arguments or sdcc passing them the wrong way
Since I'm not certain of the intended behavior for sdcpp, I'm attaching a patch which changes the behavior of sdcc -M/-E/-MM when combined with -o. We pass the outfile to sdcpp with -o instead of passing it as a non-option argument. A side-effect of that is that we no longer use the cppoutfilename portion of the sdcpp macro.
This was created against 6727 with `svn diff src/SDCCmain.c'
Hope this Helps
Log in to post a comment.