Well, the configure process should result in the variable LIBOBJS
in the generated libiberty Makefile to be set to list of objects
containing implementations of replacement system routines.

So if you do not have HAVE_STRCASECMP in config.h, you should
have been getting strcasecmp.o in LIBOBJS ...

And indeed, I sort of am.

LIBOBJS includes a strcasecmp.s$U.s

That suffix is certainly strange-looking though.  I checked in
config.log and I can see that it automatically detected that
my "object code" has a ".s" extension, which is basically
correct given that I forced the "-S" option.

All of the LIBOBJS are like that.

In addition, there's another problem - it has included strncmp
in the list.  I had a look and it appears that it attempts to
actually run the program to see if strncmp works.  That's
not going to work in a cross-compile environment though.
So maybe it assumes the worst.

I've taken a look at the Makefile to try to find out what is
happening.  It seems that there are REQUIRED_OFILES
which include things like safe-ctype and that has to have
a ".o" extension.  Give that those are hardcoded and
forced to ".o", why isn't LIBOBJS done the same way?

Anyway, I decided to change this:

else
 LIBOBJS="$LIBOBJS $ac_func.$ac_objext"
fi

code you showed earlier to be hardcoded to .o.

And then I changed ac_libobjs to stop putting that $U in there as well, and I finally got my strcasecmp.

Note that I also seem to be getting strerror.  It's on the list
of "required files", even though it isn't required or wanted.
configure correctly detected that I already had strerror.
I manually excluded that from my list of files and now things
are looking good again - including strcasecmp being
automatically selected in the build process.  :-)

Hopefully it won't be too much longer before I have the stage 1
JCL being automatically generated so that I can verify the
new files to be compiled actually work on MVS.  :-)

BFN.  Paul.

Reply via email to