This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: i370 port - constructing compile script


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.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]