AC_NO_EXECUTABLES in libc/machine/sh

[Jeff Johnston]

Dave Korn wrote:
> On 02 May 2006 17:01, Jeff Johnston wrote:
> 
> 
>>Nick Clifton wrote:
>>
>>>Hi Jeff,
>>>
>>>
>>>>I have just checked in a patch to handle the overrides properly.
>>>
>>>
>>>Thanks!
>>>
>>>
>>>>I basically made sure that all the assembler code are .S files instead
>>>>of .s
>>>
>>>
>>>Will this still be a problem on file systems with case-insensitive file
>>>naming ? 
>>>
>>
>>The renaming was to force the .S.o rule which uses the compiler to
>>assemble.  There is an inherent support problem if the build system
>>can't distinguish .S from .s files because .S files require preprocessing.
>>
>>-- Jeff J.
> 
> 
> 
>   One of newlib's main consumers is cygwin, and we have to live with case
> insensitivity as the default.
> 
>   Even though the compiler offers us this option - which simply amounts to
> setting the state of the -fpreprocessed flag according to the case of the
> filename-extension letter - can we perhaps not use it, but do something that
> involves actually different extensions?  Maybe '.spp'? for source that needs
> preprocessor treatment, and a .spp -> .s rule?
> 
>   It's not just filing systems that are case-insensitive; the human eye can
> easily miss the difference between upper and lower case when you're looking
> over a whole long list of filenames.  Surely we can find an
> alternative-but-equivalent solution to this problem ?
>

Looking closer at the Makefile.in files, there should be no issue here. 
  Building embedded platforms results in a static library.  For the 
static libraries, the lib_a prefix is appended and each object is 
specified directly with its own rule (this is needed to add the prefix). 
  For the libtool case, after renaming and regenerating, there are no .s 
rules in the Makefile.in files.  So for libtool libraries, make will 
find the appropriate .S rules which use the compiler.  See the latest 
libc/machine/i386/Makefile.in, for example.

-- Jeff J.