Re: namespace namespace

[Sam Ruby <rubys at intertwingly dot net>]

Andrew Haley wrote:
> Sam Ruby wrote:
> > Andrew Haley wrote:
> > > Sam Ruby wrote:
>
> > > > Is there something more I can provide?  Will gcj/g++ also be fixed?
> > > Well, I already suggested how you might fix gcjh.  It's a matter of
> > > whether you want to be able to access namespace namespace from CNI or
> > > merely not have header files that choke C++.  Why not try the fix?
> > For the moment, I'm doing the equivalent of sed scripts to post process
> > the header files (actually, I'm using Ruby -pi -e).
> >
> > I can certainly fix gcjh locally, but I want to share my results with
> > others, and ultimately the fix should go into cvs.  I'm certainly
> > willing to do my share of the work, but you already identified the
> > actual fix.  What's the next step?
>
> Someone must apply the change, make a patch, and test the results.

Hopefully the attached test case will help?

I will confess that I don't feel confident enough to dive into the code 
and work out a suitable patch to the namespace mangling portion of the 
g++ compiler.  Proposing a patch to gcjh is something I could have 
handled, but you already have done the bulk of this work.

> > > Do you really need CNI access to namespace namespace ?
> > What I am working on is the a Ruby extension that calls out to a HTML 5
> > parser that happens to be written in Java and exposes a JAXP interface.
> >  Along the way, I will have a need to create and access, via CNI,
> > objects of the type javax::xml::namespace::QName.  I didn't create that
> > class, nor can I change it.
> >
> > http://intertwingly.net/blog/2009/06/23/Validator-Nu-on-GCJ-Update
>
> OK, I see.  I was wondering whether this was a theoretical problem that
> might just come up or something real.  I was also wondering whether this
> was relevant to free software.

I discovered this bug trying to use the classes provided with libgcj for 
the purposes that these classes were intended.  My code is public and 
(if successful) will be a part of a package which is made available 
under a MIT license.

> Given that this looks real, and it is relevant to free software, I can
> have a look.  However, I can't go back in time, so any change that I make
> will not affect the gcj that's in distros for some time to come.

Understood.  But "download and build the latest" is still marked 
progress over "merge this patch, built it, and hope it works".  And 
within a year or so of being committed the fix should be in the 
distributions I care about.  Meanwhile, I have workarounds.

> Andrew.

- Sam Ruby

Attachment: testqname.sh
Description: Bourne shell script