RE: RE: s390 lsbsi diffs

"Wichmann, Mats D" <[email protected]> Wed, 30 Apr 2003 07:56:15 -0700
Newsgroups gmane.linux.lsb.implementation
Message-ID <[email protected]>
> I guess I can compare and see if I can come up with a patch 
> for this... Any ideas as to how it's been done before could
> be of help.

It's kind of a manual process. Roughly speaking, the
process should be something like this:

1. Try to patch a clean glibc + glibc-linuxthreads 
(ignoring completely the nALFS xml for this) for s390, 
not applying any of the other LSB or architecture patches.
2. if that patches cleanly, make ANOTHER glibc 2.2.5
tree, and apply the patches that the nALFS xml will
apply (again, I'd do this by hand)
3. If we now have two clean trees, we can diff them
and try to see if there are any conflicts. They should
be almost completely disjoint, but since the 390 patches 
didn't apply, I'm not sure I believe that any longer.

I'm willing to take a pass at this and report back.

By the way, I checked the IBM page you referenced and
it doesn't list five patches, just one.  From your
original mail:
       To create the complete glibc sources, the following patches need
to be applied   
       in sequence:

 

 

       glibc-2.2.5.tar.gz (see www.gnu.org/software/libc)

       + glibc-linuxthreads-2.2.5.tar.gz (see www.gnu.org/software/libc)

       + glibc-2.2.5-s390-may2002.diff (IBM)

       + glibc-2.2.5-s390-1-may2002.diff (IBM)

       + glibc-2.2.5-s390-2-may2002.diff (IBM)

       + glibc-2.2.5-s390-3-may2002.diff (IBM)  

But I see this:
	To create the complete glibc sources, the following patches need
to be applied 	in sequence: 

	glibc-2.2.5.tar.gz (see www.gnu.org/software/libc)
	+ glibc-linuxthreads-2.2.5.tar.gz (see
www.gnu.org/software/libc)
	+ glibc-2.2.5-s390-may2002.diff (IBM) 

And when I download the patch, it indeed only contains a
single diff file.

> I still have a lingering question as to why the 
> ../glibc-2.2.5/configure is failing as well. Any ideas?

Here's what you sent:

    -: checking for gcc... gcc
    -: checking version of gcc... v. ?.??, bad
    -: checking for gnumake... no
    -: checking for gmake... no
    -: checking for make... make
    -: checking version of make... 3.80, ok
    -: configure: error:
    -: *** These critical programs are missing or too old:gcc
    -: *** Check the INSTALL file for required versions.

The configure script is checking gcc for the
version, and not getting back a value it knows
what to do with. If it reports "v. ?.??" it 
means it didn't find a "version" string at all
in the output of "gcc -v".  

This is an odd situation because glibc isn't
built in the bootstrap phase, it's constructed
at the beginning of the intermediate phase
and thus using the built bootstrap.  That implies
that the bootstrap didn't get built correctly,
for whatever reason.  Since there was some
back-and-forth trying to get other stuff to
work, I'd suggest just getting rid of the built
tree completely and starting the build over.


Mats