This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: i370 port - constructing compile script
* 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