Closing as approved. Spec updated at http://sac.eng/Archives/CaseLog/arc/LSARC/2008/068/proposal-v2.txt
Interface stability changed as necessary. A section with risk is also added to explain the name conflict of libgc.so in Sun Studio. 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 >
