Re: i370 port - constructing compile script

["Paul Edwards" <mutazilah@gmail.com>]

>> 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.

The only thing the compiler is capable of doing is generating
assembler code.  Just getting that to work has been a 20
year effort.

So what I have done is get the compiler to fail on any missing
prototype.  I think perhaps we need to have a generic gcc or
autoconfigure option called "config by prototype".  MVS is just
one instance where you might wish to do it this way.  Other
ports in their infancy may not have working cross-assemblers
and linkers either.  It worked out quite well.

> 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

Ok, thanks, I've added that, and can confirm that it did the
trick.

> A more permanent solution would be to set this correctly based upon
> $host in libiberty/configure.ac and regenerate libiberty/configure with
> autoconf.

Ok, that's what a lot of this exercise is about - finding out what
needs to be changed in the long term in GCC 4 if MVS is to be
supported.

>> 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.)

Ok, I put it back in, and indeed, it does work.  I must have been
confused by an unrelated failure.

>> 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.  

As above, that is certainly on the cards.  However, I'm trying
to flesh out the issues that exist before seeing if we can get
agreement for changes in GCC 4.  E.g. what do you think of
the generic "configure by prototype rather than link" facility?
Personally I'd like a "configure by standard" option, where
autoconfigure knows what to do based on me just telling it
that the compiler is C90 (or C99 as another option) compliant,
so that I don't even need to provide headers.  But I think the
header file option is also useful, so both should be selectable.

> 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.

Man, I really wish that was even 1% of the issues that needed to be
sorted out going from GCC 3.4.6 to GCC 4.x.  :-)  I'd be happy to do
it for the rest of my life.  :-)  While the amount of intrusive code is
relatively small, it's still quite widespread.  ie more than 80 files.
And that's just the intrusive code.  There's all the separate port
files that need to be taken care of.  :-)  There's a good reason it took
20 years to get to this point.  :-)

BFN.  Paul.