* Paul Edwards wrote on Sat, Nov 14, 2009 at 09:51:39AM CET: > >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.
Why do you pass -S in the compiler script? configure sort of expects that neither -S nor -c are passed automatically. > 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. Yes. The macro that does this is libiberty_AC_FUNC_STRNCMP in libiberty/aclocal.m4. In a cross-compile situation, the macro assumes that strncmp does not work. It uses the cache variable ac_cv_func_strncmp_works, which you can set if you need to override the decision, e.g.: ac_cv_func_strncmp_works=yes export ac_cv_func_strncmp_works ../gcc/configure ... A more permanent solution would be to set this correctly based upon $host in libiberty/configure.ac and regenerate libiberty/configure with autoconf. > And then I changed ac_libobjs to stop putting that $U in there as > well, and I finally got my strcasecmp. Why does that $U hurt you? It should get expanded to nothing later on. (It is a remainder from some ansi2knr scheme.) > 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. :-) Again, rather than hacking the generated configure script, I think you should start modifying the input files, configure.ac in this case, for permanent solutions to your build issues. Even if you're only changing a few lines, doing it each time you want to build a different GCC version is an unnecessary burden. Thanks, Ralf