[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Support for SDCC (small device C compiler)

From: Ralf Wildenhues
Subject: Re: Support for SDCC (small device C compiler)
Date: Sat, 20 May 2006 09:34:04 +0200
User-agent: Mutt/1.5.11+cvs20060403

Hi Kallol,

* address@hidden wrote on Fri, May 19, 2006 at 07:55:59AM CEST:
> Hi
> I am using autoconf/make to build using SDCC as the target compiler. SDCC
> generates five files from the input C sources with the extensions - .map,
> .lst, .asm, .elf and .rel
> I see that somehow (maybe due to a mistake in my conf file) when I run
> ./configure, it takes in .asm as input as well as output file !! whereas
> it should take .c as input and .ihx as output file formats.
> I am confused. Am I doing something wrong in the conf file (should i
> enforce input/output file formats, if so, how ?) ? Or is that
> autoconf/make does not support SDCC ?

Well, Autoconf needs a patch to support it.  I tried Debian's packages
for sdcc.  Version 2.4.0-4 was pretty unusable, as the compiler didn't
fail but only warned for headers it doesn't find.  2.5.0-11 from Debian
unstable has this fixed.  In my test it generates files with endings
  *.asm, *.lnk, *.lst, *.map, *.mem, *.rst, *.sym

in addition to the "binary"[1] ending in ".ihx" and the object file
ending in ".rel".  So I wonder where that .elf file comes from -- is
that maybe an executable, in which case we shouldn't strip that?  It's
not listed in
either.  (I have not tested the current version of the compiler.)

Furthermore, the documentation also lists
  *.adb, *.cdb, *.dump

Let's hope the naming of the object files doesn't depend upon the phase
of the moon or any compiler flags we test, but remains fixed during the
entire configure tests.

In any case, a patch similar to the one below should help.  OK to apply
this proliferation of files to ignore?

I wonder whether we need to start documenting the possible extensions of
executables that compilers may create, so that we have a change to
notice a clash: the legit program output by one compiler may be the
byproduct of another.  Wrapping the corresponding test in a cache
variable helps for overriding, but the patch that introduces this caused
unfortunate side effects[2], so we may end up reverting that.

Kallol, did I spell your name right in the ChangeLog entry?


[1] "binary" because what it generates is an interesting string of
colons followed by runs of characters that all belong to the hexadecimal
system.  `file a.ihx' says
| a.ihx: shell archive or script for antique kernel text


[2] See

        * lib/autoconf/lang.m4 (_AC_COMPILER_OBJEXT_REJECT): Add
        .adb, .asm, .cdb, .dump, .lnk, .lst, .mem, .rst, and .sym,
        for the Small Device C Compiler (sdcc).
        (_AC_COMPILER_EXEEXT_REJECT): Likewise, add .rel.
        Report by Kallol Borah <address@hidden>.

Index: lib/autoconf/lang.m4
RCS file: /cvsroot/autoconf/autoconf/lib/autoconf/lang.m4,v
retrieving revision 1.180
diff -u -r1.180 lang.m4
--- lib/autoconf/lang.m4        6 Apr 2006 18:34:24 -0000       1.180
+++ lib/autoconf/lang.m4        20 May 2006 06:01:38 -0000
@@ -428,6 +428,10 @@
 # - *.map, *.inf
 #   Created by the Green Hills compiler.
+# - *.adb, *.asm, *.cdb, *.dump, *.lnk, *.lst, *.map, *.mem, *.rst, *.sym
+#   Created by sdcc - Small Device C Compiler
+#   (object files are named *.rel or *.o)
@@ -435,7 +439,8 @@
 # Case/esac pattern matching the files to be ignored when looking for
 # compiled object files.
-[*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | 
+[*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map \
+ | *.inf | *.adb | *.asm | *.cdb | *.dump | *.lnk | *.lst | *.mem | *.rst | 
@@ -443,7 +448,7 @@
 # Case/esac pattern matching the files to be ignored when looking for
 # compiled executables.
-[_AC_COMPILER_OBJEXT_REJECT | *.o | *.obj])
+[_AC_COMPILER_OBJEXT_REJECT | *.o | *.obj | *.rel])
 # We must not AU define them, because autoupdate would then remove

reply via email to

[Prev in Thread] Current Thread [Next in Thread]