AC_NO_EXECUTABLES in libc/machine/sh

[Jeff Johnston]

Jeff Johnston wrote:
> Nick Clifton wrote:
> 
>> Hi Jeff,
>>
>>> DJ Delorie wrote:
>>>
>>>> [snip]  However, in a local discussion, one of us also
>>>> noted that the objects in that directory don't seem to be correctly
>>>> overriding the generic C implementations of those functions, due to
>>>> new object naming conventions.  We're not sure what to do about that.
>>
>>
>>
>> This was me.  It seems that nowadays the object files in the newlib 
>> sub-directories all have a "lib_a-" prefix.  So for example the source 
>> file newlib/libc/string/strlen.c compiles to lib_a-strlen.o.
>>
>> The problem is that the object files built in the 
>> libc/machine/<target>/ directory are not being given this prefix.  So 
>> for example for the SH port the libc/machine/sh/strlen.S file is being 
>> compiled into strlen.o.
>>
>> When the object files from the various sub-directories are extracted 
>> into the temporary directory as part of the process of building libc.a 
>> it used to be that the version from the machine/ sub-directory would 
>> have the same name as the version from the string/ sub-directory and 
>> (since it was extracted last) it would overwrite it.  Thus the machine 
>> specific version would be used by the application.
>>
>> With the switch over to autoconf-2.59 and the appearance of this 
>> "lib_a-" prefix there are now two distinct filenames, and so both are 
>> copied into libc.a.  Since the "lib_a-" prefix is usually 
>> alphabetically prior to the un-prefixed name, the lib_a- version is 
>> usually the one picked up by an application that links with libc.a.  
>> Thus applications do not get the versions that are optimized for their 
>> target architecture, and in some cases, the versions that are 
>> necessary for correct operation on their target architecture.
>>
>> (Note this affects not just the SH port, but all ports that have 
>> machine specific versions of some libc functions, including the CRIS, 
>> CRX, H8300, HPPA, i386, i960, M68K, MIPS, MN10300, XSTORMY16 and Z8K).
>>
>> Unfortunately I have not been able to work out why this "lib_a-" 
>> prefix has appeared, nor why it is not being applied to the files 
>> built in the machine sub-directory.  Any clues in this direction would 
>> be greatly appreciated.
>>
> 
> It is caused by a work-around I was forced to use.  I have no idea why, 
> but the new autoconf/automake complains about multiple objects of the 
> same name when we have a directory that optionally uses libtool or 
> non-libtool.  It is ridiculous because both objects are not built at the 
> same time due to an if/else check.  The workaround I found for this 
> problem is to specify the lib_a_CFLAGS=$(AM_CFLAGS) and this adds the 
> prefix which is why the error goes away.
> 

Without the lib_a_CFLAGS=$(AM_CFLAGS), the error message from automake is:

bash-3.00$ automake --cygnus stdio/Makefile
stdio/Makefile.am: object `clearerr.$(OBJEXT)' created both with libtool 
and without


> I'm certainly not happy with this and I am open to suggestions for 
> alternatives.  I will investigate getting the prefix added to the 
> machine object files as well to at least fix the problem.
> 
> -- Jeff J.
> 
> 
> 
>> Cheers
>>   Nick
> 
>