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
