Yes. LGTM. Proceed. craig ----- rich.burri...@oracle.com wrote:
> On 03/13/2012 04:00 PM, Craig Mohrman wrote: > > Sorry. > > > > The question is since libexslt is not using a mapfile why should > libxslt? > > If you agree with that statement but a deferring making that change > right > > now then that is fine. > > That's exactly it. We are doing just enough to fix the bug in > question. > The longer range goal (not this bug fix), is to remove all the > mapfiles > that we don't want in Userland components. > > (Another possibility is to use mapfiles in a different way. Ali > mentioned > SYMBOL_SCOPE creates an unversioned library that only exports the > symbols you list, but unless I'm misunderstanding it, that still means > you > need to know the symbols that you wish to put in the mapfile, which > leads > us back to the potential situation where the symbols we want to make > available in an update might not match what's in the mapfile. In other > > words, > you still need to do the due diligence to get the mapfile contents > correct > each time an update occurs. Anyhoo, we should discuss this in more > detail > with Rod and Ali at a future date). > > > > > I.E. looks good except for this discrepancy. > > Okay. I'll take that as a LGTM then. > > > > > Am I not understand this? > > No, I think we are both on the same page. > > Thanks. > > > > > ----- rich.burri...@oracle.com wrote: > > > >> On 03/13/2012 02:03 PM, Craig Mohrman wrote: > >>> So what about the other mapfile: > >>> > >>> cp ../mapfile.xslt libxslt/libxslt.syms > >> I haven't touched that, and you can see from lines 22, 427, 428, > 1523 > >> > >> and 1524 of > >> > >> > >> > /net/stard.us.oracle.com/tank/ws/UL/7153397/components/libxslt/publish-trans.txt > >> > >> that it's still being used. > >> > >> As mentioned below: > >> > >> "To minimize the changes we are making as we come > >> up to the end of a build cycle, we are just adjust the libexslt > >> library generation for now." > >> > >> Thanks. > >> > >> > >> > >>> > >>> > >>> ----- rich.burri...@oracle.com wrote: > >>> > >>>> Hi, > >>>> > >>>> Thanks for the reviews (both on-list and off-list). > >>>> > >>>> After further discussion on this (off-list), we are going with a > >>>> different approach. > >>>> > >>>> Rather than modify the mapfile for libexslt to add in the four > >>>> new symbols, the component Makefile has been adjusted to build > >>>> the libexslt library without a mapfile. > >>>> > >>>> As components in Userland are updated frequently, and have > >>>> Uncommitted interfaces, it was thought that this was a better > >>>> fit and less likely to get us into a repeat of this situation > >>>> at a future date. To minimize the changes we are making as we > come > >>>> up to the end of a build cycle, we are just adjust the libexslt > >>>> library generation for now. > >>>> > >>>> The new webrev at: > >>>> > >>>> http://jurassic.us.oracle.com/~richb/7153397-v2/ > >>>> > >>>> x86 code workspace (with just libxslt rebuilt) is at: > >>>> > >>>> /net/stard.us.oracle.com/tank/ws/UL/7153397/ > >>>> > >>>> New build/publish log is: > >>>> > >>>> > >>>> > >>>> > >>>> SPARC Userland workspace (with just libxslt rebuilt) is at: > >>>> > >>>> /net/wonderland.us.oracle.com/builds/richb/7153397/ > >>>> > >>>> New build/publish log is: > >>>> > >>>> > >>>> > >> > /net/wonderland.us.oracle.com/builds/richb/7153397/components/libxslt/publish-trans.txt > >>>> I've successfully repeated the various tests I'd previous run. > >>>> > >>>> Thanks. > >>>> > >>>> > >>>> -------- Original Message -------- > >>>> Subject: [userland-discuss] Fairly urgent code review request > for > >> CR > >>>> #7153397 > >>>> Date: Tue, 13 Mar 2012 08:21:01 -0700 > >>>> From: Rich Burridge<rich.burri...@oracle.com> > >>>> To: Userland-Discuss<userland-discuss@opensolaris.org> > >>>> > >>>> > >>>> > >>>> Hi, > >>>> > >>>> Can I have a fairly urgent code review for my fix for: > >>>> > >>>> 7153397 libexslt is built incorrectly > >>>> http://monaco.us.oracle.com/detail.jsf?cr=7153397 > >>>> > >>>> As we want to update the Python lxml bindings in Userland, (CR > >>>> #7153019) > >>>> and this fix is going to be needed as part of the CBE for doing > >> that, > >>>> then it needs to get in sooner rather than later. > >>>> > >>>> > >>>> Webrev is at: > >>>> > >>>> http://jurassic.us.oracle.com/~richb/7153397-v1/ > >>>> > >>>> > >>>> x86 code workspace (with just libxslt built) is at: > >>>> > >>>> /net/stard.us.oracle.com/tank/ws/UL/7153397/ > >>>> > >>>> Build/publish log is: > >>>> > >>>> > >>>> > >> > /net/stard.us.oracle.com/tank/ws/UL/7153397/components/libxslt/publish-trans.txt > >>>> > >>>> SPARC Userland workspace (with just libxslt built) is at: > >>>> > >>>> /net/wonderland.us.oracle.com/builds/richb/7153397/ > >>>> > >>>> Build/publish log is: > >>>> > >>>> > >>>> > >> > /net/wonderland.us.oracle.com/builds/richb/7153397/components/libxslt/publish-trans.txt > >>>> > >>>> See the test related comments in the Bugster CR for how I tested > >>>> this. > >>>> > >>>> Thanks. > >>>> > >>>> _______________________________________________ > >>>> userland-discuss mailing list > >>>> userland-discuss@opensolaris.org > >>>> http://mail.opensolaris.org/mailman/listinfo/userland-discuss > >>>> > >>>> _______________________________________________ > >>>> userland-discuss mailing list > >>>> userland-discuss@opensolaris.org > >>>> http://mail.opensolaris.org/mailman/listinfo/userland-discuss _______________________________________________ userland-discuss mailing list userland-discuss@opensolaris.org http://mail.opensolaris.org/mailman/listinfo/userland-discuss
