Re: AC_NO_EXECUTABLES in libc/machine/sh

[Jeff Johnston <jjohnstn at redhat dot com>]

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