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.
----- [email protected] 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.
----- [email protected] 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<[email protected]>
To: Userland-Discuss<[email protected]>
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
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
_______________________________________________
userland-discuss mailing list
[email protected]
http://mail.opensolaris.org/mailman/listinfo/userland-discuss
