AC_NO_EXECUTABLES in libc/machine/sh

[Jeff Johnston]

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.

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