From gk4 at austin.ibm.com Wed Jun 16 11:48:16 2004 From: gk4 at austin.ibm.com (George Kraft) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] [Fwd: book completion] Message-ID: <1087411695.5127.5.camel@gk4.austin.ibm.com> Yesterday I sent of the LSB book manuscript to Prentice Hall. Unfortunately I only received approvals from a few. Were there any objections? George (gk4) -----Forwarded Message----- From: George Kraft To: lsb-book@linuxbase.org Cc: lsb-sc@linuxbase.org, Mark Taub Subject: book completion Date: 14 May 2004 09:50:50 -0500 Authors, Book completion is Thursday May 20th @ 11AM Central. After the appbat conference call, we will have our final authors meeting. The book will be built and pushed out by 4pm. The two major things being finished this week are: 1) completion of appbat chapter 2) rewording of migration chapter By Monday May 24th at 11AM Central I would like to receive approval (lsb-book) from the authors, chairman, and majority of the steering committee (authors?) to send the book to Prentice Hall. If anyone believes this book compromises the integrity of the LSB or themselves, then please let me know. ------------------------------------------------------ APPROVERS APPROVAL ------------------------------------------------------ Stuart Anderson (author, sc) Mark Brown (author) Kevin Caunt (author) Marvin Heffler (author, sc) Andrew Josey (author, sc) George Kraft (author) Rad Sethuraman (author) Kristin Thomas (author) Matt Taggart (author, sc) Ted Ts'o (author) Mats Wichmann (author, chair) Chris Yeoh (author, sc) ------------------------------------------------------ George (gk4) -----Forwarded Message----- From: George Kraft To: lsb-book@freestandards.org Cc: Mark Taub , Hal Porter , cckane@us.ibm.com Subject: May 20th deadline Date: 06 May 2004 13:01:01 -0500 The book is to be delivered to Prentice Hall on June 1st; however, Kevin and I will be out of town so it needs to be delivered on May 24th. We already have a May 20th authors meeting, so I would like to make that the absolute deadline. Here is what needs to be done in the next two weeks. 1) everyone resolve their bugs 2) finish the AppBat chapter 3) rework the Solaris to Linux chapter 4) add lsbdynchk -- George Kraft IV IBM Linux Technology Center gk4@austin.ibm.com http://www.ibm.com/linux/ltc/ GPG fingerprint = 3AFD 7397 59AF 114A D2A0 D39E C2FC E074 E323 FE90 -- George Kraft IV IBM Linux Technology Center gk4@austin.ibm.com http://www.ibm.com/linux/ltc/ GPG fingerprint = 3AFD 7397 59AF 114A D2A0 D39E C2FC E074 E323 FE90 From mats.d.wichmann at intel.com Thu Jun 17 09:13:28 2004 From: mats.d.wichmann at intel.com (Wichmann, Mats D) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] C++ blocker problem Message-ID: Steering Committee members: We're facing a blocker-type situation for LSB 2.0 that really shouldn't be this complicated. I think you all know of the LSB C++ "patch". In generating the spec, Stuart found a few interfaces that are not exported by stock GCC libstdc++ 3.3.x. A few of these looked like they were just oversights, and were really supposed to be public interfaces, and in fact these now are public in later gcc versions - but those changes were not backported into the gcc 3.3 branch. A few others may or may not be necessary for applications, but are necessary to be able to trace back into the library and examine it for correctness. The "patch" changes no code in libstdc++, but does fiddle with the set of exported symbols, assigning (invented) versions to the newly exported ones. Having these symbols visible is called out by the LSB specification and as things currently stand, a library would have to do so in order to be LSB certified. This means that today, no distro could certify unless we grant waivers or change the spec prior to release. The distributions who have expressed an opinion on this want to follow the guidance of the gcc team, if the patch were accepted there they would apply it. We can get no response from the gcc project. This issue has been open for nine months and there's no sign that we can move it off the current stuck state. What shall we do? - release with changes and wait for the storm when nobody can certify - pre-plan to grant waivers (but the libraries may not be fully testable in this circumstance) - back off and remove these extra symbols (see the "but" in the previous point) - push harder on the gcc committee and hope we can get an answer in about the next two weeks? Or some other choice? Mats From dbb at beatties.us Thu Jun 17 09:39:47 2004 From: dbb at beatties.us (Doug Beattie) Date: Thu Jul 12 13:07:53 2007 Subject: [Lsb-sc] C++ blocker problem In-Reply-To: References: Message-ID: <20040617163947.GA27501@beatties.us> Mats: I met with Jeff Law (Red Hat Fellow and GCC optimizer developer) last night. He presented to our SLLUG group. Anyway, I asked him again to do what he could to encourage Gabriel (the 3.3 branch maintainer) to review and provide us feedback on the e-mails we have sent him on this subject. I told Jeff we must have feedback within the next week and explained the reason. Jeff said he would try to get Gabriel to take a couple hours to look into this. Doug On Thu, Jun 17, 2004 at 09:13:28AM -0700, Wichmann, Mats D wrote: > > Steering Committee members: > > We're facing a blocker-type situation for LSB 2.0 that really > shouldn't be this complicated. > > I think you all know of the LSB C++ "patch". In generating > the spec, Stuart found a few interfaces that are not exported > by stock GCC libstdc++ 3.3.x. A few of these looked like > they were just oversights, and were really supposed to be > public interfaces, and in fact these now are public in later > gcc versions - but those changes were not backported into > the gcc 3.3 branch. > > A few others may or may not be necessary for applications, > but are necessary to be able to trace back into the library > and examine it for correctness. > > The "patch" changes no code in libstdc++, but does fiddle > with the set of exported symbols, assigning (invented) > versions to the newly exported ones. > > Having these symbols visible is called out by the LSB > specification and as things currently stand, a library > would have to do so in order to be LSB certified. This > means that today, no distro could certify unless we grant > waivers or change the spec prior to release. > > The distributions who have expressed an opinion on this > want to follow the guidance of the gcc team, if the > patch were accepted there they would apply it. We can > get no response from the gcc project. > > This issue has been open for nine months and there's no > sign that we can move it off the current stuck state. > > What shall we do? > > - release with changes and wait for the storm when > nobody can certify > - pre-plan to grant waivers (but the libraries may > not be fully testable in this circumstance) > - back off and remove these extra symbols (see the > "but" in the previous point) > - push harder on the gcc committee and hope we can > get an answer in about the next two weeks? > > Or some other choice? > > Mats > > > _______________________________________________ > Lsb-sc mailing list > Lsb-sc@mail.freestandards.org > http://mail.freestandards.org/mailman/listinfo/lsb-sc --