Hi Kallol, * k.borah@xxxxxxxxxxxxxxxxxx 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 http://sdcc.sourceforge.net/doc/sdccman.html/node41.html either. (I have not tested the current version of the compiler.) Furthermore, the documentation also lists *.adb, *.cdb, *.dump at http://sdcc.sourceforge.net/doc/sdccman.html/node177.html 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? Cheers, Ralf [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 amusingly. [2] See http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=368012 * 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 <k.borah@xxxxxxxxxxxxxxxxxx>. 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) # _AC_COMPILER_OBJEXT_REJECT @@ -435,7 +439,8 @@ # Case/esac pattern matching the files to be ignored when looking for # compiled object files. m4_define([_AC_COMPILER_OBJEXT_REJECT], -[*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map | *.inf]) +[*.$ac_ext | *.xcoff | *.tds | *.d | *.pdb | *.xSYM | *.bb | *.bbg | *.map \ + | *.inf | *.adb | *.asm | *.cdb | *.dump | *.lnk | *.lst | *.mem | *.rst | *.sym]) # _AC_COMPILER_EXEEXT_REJECT @@ -443,7 +448,7 @@ # Case/esac pattern matching the files to be ignored when looking for # compiled executables. m4_define([_AC_COMPILER_EXEEXT_REJECT], -[_AC_COMPILER_OBJEXT_REJECT | *.o | *.obj]) +[_AC_COMPILER_OBJEXT_REJECT | *.o | *.obj | *.rel]) # We must not AU define them, because autoupdate would then remove _______________________________________________ Autoconf mailing list Autoconf@xxxxxxx http://lists.gnu.org/mailman/listinfo/autoconf