Hi Irene, Irene Huang wrote: > Closing as approved. > > Spec updated at > http://sac.eng/Archives/CaseLog/arc/LSARC/2008/068/proposal-v2.txt
Can someone see if this new spec can be pushed to the case directory on opensolaris.org? (Or emailed). Since it does not seem to have made it on it's own? Also, as a FYI, none of the previous emails made it into the correct case folder because of the subject incorrectly containing 2008/067, not 2008/068. So people in future may struggle to find the mail record, except for this message which will hopefully point the user in the right direction. > Interface stability changed as necessary. A section with risk is also > added to explain the name conflict of libgc.so in Sun Studio. Presumably this will also go in the man page? Thanks, Hugh. > Modified contents are marked using "!" at the beginning of the line. > > --Irene > On Mon, 2008-02-18 at 14:29 +0800, Irene Huang wrote: >> Hi, all >> >> Here's the issue list for this case, with answers provided by Jerry >> >> Interface stability: why is it "Volatile" >> Jerry: we are agreeable with change the stability to be "Uncommitted". >> Since there is little incompatible changes in the community. >> >> there's also another copy of libgc.so in Sun Studio, will there be any >> conflict? >> There's no runtime issues, since the SONAME of these two libgc.so are >> different. By specifying cflag -L, there will be no link-time issues >> either. >> >> However, the duplication of libgc.so is still pending opinion from >> compiler team. It seems that this doesn't block the approval of this >> case. >> >> If there's no further issues, I would like to close this case as >> approved. >> >> Thanks >> >> --Irene >> On Wed, 2008-02-13 at 23:37 -0800, Danek Duvall wrote: >>> On Wed, Feb 13, 2008 at 11:02:46PM -0800, Hugh McIntyre wrote: >>> >>>> Danek Duvall wrote: >>>>> On Mon, Feb 04, 2008 at 04:44:44PM -0600, Brian Cameron wrote: >>>>> >>>>> Any word from the compiler folks about how they'd like to see this project >>>>> move forward? Or should we just let it time out as specified (with the >>>>> interfaces changed to Committed)? >>>> Exactly. Although there seems to be agreement to have one libgc.so in the >>>> end, which is fine, there's still no comment on what's planned to avoid >>>> two >>>> incompatible libraries if someone installs Studio on top of Indiana. >>>> >>>> I.e.: is the assumed plan to issue a studio patch or new version to move >>>> or >>>> upgrade the studio library? A warning to users? Or some other measure? >>> Another thing we need to know is the full SONAME for the libraries >>> involved. For anyone looking to submit arc cases, please note: the *.so >>> form of a library is *not* sufficient. Nor is the realpath()ed name of the >>> link correct. We need to know what the SONAME is, as specified on the ld >>> commandline with the -h flag. We've been seeing this mistake a lot >>> recently. >>> >>> Studio appears to ship libgc.so.1. I know a lot of F/OSS libraries ship >>> with version numbers other than 1, so there may not be a run-time issue, >>> only a link-time issue, which can be pretty easily managed with the >>> appropriate -L flags. >>> >>> Danek
