On Thu, 14 Aug 2014 10:32:42 -0400 (EDT), Philipp Kern wrote: > > Hrm. Odd. It shouldn't be because the brokeness relates to the C > library, not to the C compiler itself and zipl does not use the C > library.
Again, we must distinguish between zipl, the Linux command which runs at a Linux shell prompt, and zIPL, the boot loader proper, a customized version of which is written out by zipl when zipl gets run. zipl, the command which runs at a Linux shell prompt, most certainly does use the C library. It is written in C, it is compiled by the C compiler, and, at execution time, it uses the C run-time library, just like any other C program. zIPL, which is written out by zipl, does not use the C library. Or does it? Well, not the regular C library, no. But it does use a minimalist run-time library. In the source package, look at zipl/boot/libc.c. Yes, even zIPL, the boot loader proper, does use a C library of sorts. > > That being said, I had to recompile s390-tools on sid, Therein lies the problem. > > and I do not run sid due to the C breakage. You should. You may not be able to directly install jessie or sid, but you can install wheezy and then do an upgrade to jessie or sid. Of course, you will likely experience problems during the upgrade, as I did, most likely with the upgrade of package perl-base. But there are posts to debian-s390 by me that explain how I worked around it. If you had a sid system to test with, you would have realized that this package is unusable and you never would have uploaded it. > > It worked before the recompilation, hence there might be > a change in sid vs. wheezy that caused this. Oh, absolutely. I downloaded the new source package, built it on a wheezy system, transferred the binary package to my jessie system, installed the binary package on my jessie system, ran zipl, shutdown my system, and IPLed. It IPLed just fine. I then took the exact same source package, compiled it on a jessie system, installed the binary package, ran zipl, shutdown, and IPLed. Kaboom! disabled wait state code X'32EE'. The C compiler and run-time library used is the only difference. I think I've proven pretty conclusively that this is C breakage causing this problem. > > You are talking about Hercules, right? It doesn't matter. I get the exact same results on Hercules as I do on a real mainframe, and vice versa. I have found Hercules to be a deadly accurate emulation of real mainframe hardware, when properly configured. In my opinion, everyone who maintains a package which is mainframe-specific, such as s390-tools, and anyone responsible, in whole or in part, for the s390x port needs their own mainframe system that they can play around with in a totally unrestricted manner, without fear of messing someone else up. And if you don't have access to a real mainframe, a Hercules emulation of one is the next best thing. It's slower than a real mainframe; but architecturally, it is virtually indistinguishable from a real mainframe to the software. And that's what an emulator is all about, right? You need a jessie/sid system to play around with. I must say that the C breakage on s390x is the biggest mess that I have ever seen, and in the case of this package, has produced the worst error yet: a totally unbootable system. By the way, when version 1.17.1 of the package is compiled on a jessie system, it runs fine. To me, the most significant difference between the two packages is that the zIPL portion of the 1.17.1 package, the boot loader proper, is all written in assembly language (zipl/boot/sclp.S, zipl/boot/menu.S, etc.), whereas the zIPL portion of the 1.24.1 package has been rewritten in C (zipl/boot/sclp.c, zipl/boot/menu.c, etc.). Since it's written in C, it needs that minimalist C run-time library (zipl/boot/libc.c), which the 1.17.1 version doesn't need. Yes, this bug has C breakage written all over it. -- .''`. Stephen Powell : :' : `. `'` `- -- To UNSUBSCRIBE, email to debian-s390-requ...@lists.debian.org with a subject of "unsubscribe". Trouble? Contact listmas...@lists.debian.org Archive: https://lists.debian.org/1925263645.331324.1408067153733.javamail.r...@md01.wow.synacor.com
