Re: GCC to open the C++ demangle API?

Re: GCC to open the C++ demangle API?

[Robert Dewar]

<<I have no intention to put people in the same shitty situation that
I was in: the code exists as Open Source but you can't use it because
of the license.  Sorry, but I don't like the GPL.
>>

Yes, well everyone would like to be able to use Microsoft software freely
too as well. Of course if you say you don't like the GPL, because it is
too restrictive, and you opposed to anyone using restrictive licensing,
that's consistent, but on the other hand, it sounds as though you are
proposing to use an even more restrictive licensing yourself, since
why otherwise would this be a concern :-)

Re: GCC to open the C++ demangle API?

[Zack Weinberg]

On Mon, Mar 04, 2002 at 02:07:33PM -0500, Robert Dewar wrote:
> Yes, well everyone would like to be able to use Microsoft software freely
> too as well. Of course if you say you don't like the GPL, because it is
> too restrictive, and you opposed to anyone using restrictive licensing,
> that's consistent, but on the other hand, it sounds as though you are
> proposing to use an even more restrictive licensing yourself, since
> why otherwise would this be a concern :-)

Dunno about Carlo's situation specifically, but there is a very real
problem within GCC (extended sense)'s own tree with the current
license of the demangler.  The libstdc++ and libgcj libraries are
supposed to implement interfaces which expose the functionality of the
demangler.  They have licenses which are more permissive than the GPL.
We cannot link the demangler into these libraries, or its license
would force us to apply the GPL's restrictions to them as well.
Therefore we cannot implement all the interfaces that users expect.

zw

Re: GCC to open the C++ demangle API?

[Ross Smith]

Zack Weinberg wrote:
> 
> Dunno about Carlo's situation specifically, but there is a very real
> problem within GCC (extended sense)'s own tree with the current
> license of the demangler.  The libstdc++ and libgcj libraries are
> supposed to implement interfaces which expose the functionality of the
> demangler.  They have licenses which are more permissive than the GPL.
> We cannot link the demangler into these libraries, or its license
> would force us to apply the GPL's restrictions to them as well.
> Therefore we cannot implement all the interfaces that users expect.

Is this why std::typeinfo::name() is still returning the mangled names
instead of human-readable ones?

-- 
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ......................... http://storm.net.nz/~ross/
  "We need a new cosmology. New gods. New sacraments. Another drink."
                                                       -- Patti Smith

Re: GCC to open the C++ demangle API?

[Carlo Wood]

On Tue, Mar 05, 2002 at 09:14:06PM +1300, Ross Smith wrote:
> Is this why std::typeinfo::name() is still returning the mangled names
> instead of human-readable ones?

HOLA!  Don't change that!
I am relying on it returning the mangled name :/

I know, I know, it is not an API - but it would be a disaster
if it was changed.

-- 
Carlo Wood <carlo@alinoe.com>

Re: GCC to open the C++ demangle API?

[Mark Mitchell]

--On Tuesday, March 05, 2002 09:14:06 PM +1300 Ross Smith 
<r-smith@ihug.co.nz> wrote:

> Zack Weinberg wrote:
>>
>> Dunno about Carlo's situation specifically, but there is a very real
>> problem within GCC (extended sense)'s own tree with the current
>> license of the demangler.  The libstdc++ and libgcj libraries are
>> supposed to implement interfaces which expose the functionality of the
>> demangler.  They have licenses which are more permissive than the GPL.
>> We cannot link the demangler into these libraries, or its license
>> would force us to apply the GPL's restrictions to them as well.
>> Therefore we cannot implement all the interfaces that users expect.
>
> Is this why std::typeinfo::name() is still returning the mangled names
> instead of human-readable ones?

No; that is because the ABI standard specifies that it return mangled
names.

You're then supposed to be able to call the demangler -- but that's
the bit that's missing.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC to open the C++ demangle API?

[Ross Smith]

Mark Mitchell wrote:
> 
> --On Tuesday, March 05, 2002 09:14:06 PM +1300 Ross Smith
> <r-smith@ihug.co.nz> wrote:
> 
> > Zack Weinberg wrote:
> >>
> >> Dunno about Carlo's situation specifically, but there is a very real
> >> problem within GCC (extended sense)'s own tree with the current
> >> license of the demangler.  The libstdc++ and libgcj libraries are
> >> supposed to implement interfaces which expose the functionality of the
> >> demangler.  They have licenses which are more permissive than the GPL.
> >> We cannot link the demangler into these libraries, or its license
> >> would force us to apply the GPL's restrictions to them as well.
> >> Therefore we cannot implement all the interfaces that users expect.
> >
> > Is this why std::typeinfo::name() is still returning the mangled names
> > instead of human-readable ones?
> 
> No; that is because the ABI standard specifies that it return mangled
> names.
> 
> You're then supposed to be able to call the demangler -- but that's
> the bit that's missing.

Ah, thank you.

-- 
Ross Smith ...................................... Auckland, New Zealand
r-smith@ihug.co.nz ......................... http://storm.net.nz/~ross/
  "We need a new cosmology. New gods. New sacraments. Another drink."
                                                       -- Patti Smith

Re: GCC to open the C++ demangle API?

[Bo Thorsen]

On Friday 22 March 2002 07:40, Fergus Henderson wrote:
> On 20-Mar-2002, Mark Mitchell <mark@codesourcery.com> wrote:
> > > True, though I'm not aware of other approaches.  But I definitely agree
> > > that this stuff has no place in the language standard.
> >
> > We're wandering into never-never land, but I do know of one other
> > approaches that have Really Been Used: interpretation, where the
> > lookup was done following the language rules, rather than by mangled
> > name.
> >
> > In practice, though, everyone uses mangling.
>
> For the .NET CLR, name mangling is not used; the underlying assembler,
> object file format, and linker directly support overloading.

... and it is by choice that existing systems do not do this. There's no 
technical reason this couldn't be done as an ELF extension.

Bo.

-- 

     Bo Thorsen                 |   Praestevejen 4
     Free software developer    |   5290 Marslev
     SuSE Labs                  |   Denmark

Re: GCC to open the C++ demangle API?

[Fergus Henderson]

On 20-Mar-2002, Mark Mitchell <mark@codesourcery.com> wrote:
> > True, though I'm not aware of other approaches.  But I definitely agree
> > that this stuff has no place in the language standard.
> 
> We're wandering into never-never land, but I do know of one other
> approaches that have Really Been Used: interpretation, where the
> lookup was done following the language rules, rather than by mangled
> name.
> 
> In practice, though, everyone uses mangling.

For the .NET CLR, name mangling is not used; the underlying assembler,
object file format, and linker directly support overloading.

-- 
Fergus Henderson <fjh@cs.mu.oz.au>  |  "I have always known that the pursuit
The University of Melbourne         |  of excellence is a lethal habit"
WWW: <http://www.cs.mu.oz.au/~fjh>  |     -- the last words of T. S. Garp.

Re: GCC to open the C++ demangle API?

[Mark Mitchell]

> True, though I'm not aware of other approaches.  But I definitely agree
> that this stuff has no place in the language standard.

We're wandering into never-never land, but I do know of one other
approaches that have Really Been Used: interpretation, where the
lookup was done following the language rules, rather than by mangled
name.

In practice, though, everyone uses mangling.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC to open the C++ demangle API?

[Joe Buck]

> >  http://www.codesourcery.com/cxx-abi/abi.html#mangling

Andrew Marlow writes:
> This does not appear to be a standard to me. 
> I would call it a documented convention for the Itanium environment.
> I do like the documentation though, especially the use of BNF.
> Thankyou for drawing my attention to this. If only this would be adopted
> by ISO.

This is not in the scope of the ISO C++ standard.  The only reason we
need name mangling is so that we can use traditional C-oriented assembers
and linkers, and freezing issues of object layout would degrade
performance on future processors.

These kinds of things will probably be done in the future in a specific
way for each distinct processor/OS-group combination (where "OS-group"
is a group of similar operating systems), except where barriers exist
(for example, Microsoft has patented certain aspects of its C++ object
layout).

Re: GCC to open the C++ demangle API?

[Jason Merrill]

>>>>> "Robert" == Robert Dewar <dewar@gnat.com> writes:

> <This does not appear to be a standard to me.
> I would call it a documented convention for the Itanium environment.
> I do like the documentation though, especially the use of BNF.
> Thankyou for drawing my attention to this. If only this would be adopted
> by ISO.> 

> To me it would seem a bit odd for ISO to adopt this as part of the language
> definition. Is it really the case that name mangling has anything whatsoever
> to do with the C++ language. To me it is just a low level implementation
> approach to solving low level implementation problems, and is definitely
> not the only approach.

True, though I'm not aware of other approaches.  But I definitely agree
that this stuff has no place in the language standard.

Jason

Re: GCC to open the C++ demangle API?

[Robert Dewar]

<This does not appear to be a standard to me.
I would call it a documented convention for the Itanium environment.
I do like the documentation though, especially the use of BNF.
Thankyou for drawing my attention to this. If only this would be adopted
by ISO.
>

To me it would seem a bit odd for ISO to adopt this as part of the language
definition. Is it really the case that name mangling has anything whatsoever
to do with the C++ language. To me it is just a low level implementation
approach to solving low level implementation problems, and is definitely
not the only approach. GNAT for example does not need to do name mangling
in the same kind of way at all, and if we did not have annoying limitations
like no dots in external identifiers, we would encode names even less than
we do now.

Re: GCC to open the C++ demangle API?

[Andrew Marlow]

jason@redhat.com writes:
>>>>>> "Andrew" == Andrew Marlow <apm35@student.open.ac.uk> writes:
>
>> As the OP I would like to chip in at this point. I no longer wish for
>the
>> API to be opened. I agree with RMS that since there is no standard for
>> name mangling in C++ the most appropriate license for this code is the
>GPL
>> rather than the LGPL.
>
>But there IS a standard for name mangling.  And there are at least two
>other vendors with compatible compilers: HP and Intel.
>
>  http://www.codesourcery.com/cxx-abi/abi.html#mangling

This does not appear to be a standard to me. 
I would call it a documented convention for the Itanium environment.
I do like the documentation though, especially the use of BNF.
Thankyou for drawing my attention to this. If only this would be adopted
by ISO.

-apm

Re: GCC to open the C++ demangle API?

[Daniel Berlin]

On Tue, 2002-03-19 at 21:15, Joe Buck wrote:
> Andrew Marlow <apm35@student.open.ac.uk> writes:
> > > As the OP I would like to chip in at this point. I no longer wish for the
> > > API to be opened. I agree with RMS that since there is no standard for
> > > name mangling in C++ the most appropriate license for this code is the GPL
> > > rather than the LGPL.
> 
> Jason Merrill writes:
> > But there IS a standard for name mangling.  And there are at least two
> > other vendors with compatible compilers: HP and Intel.
> > 
> >   http://www.codesourcery.com/cxx-abi/abi.html#mangling
> 
> Furthermore RMS has already agreed to change the license, so this issue is
> now moot and we can argue about something else. :-)
Guys and Gals,
We need to slow down the rate at which we argue about random, mostly (or
completely) moot issues.
If you look, just this week we've gone through at least two or three of
them.  In two days.
This means we have to make up new issues for the next week or two, since
there's really nothing left.
In the future, we need to be more careful to make sure we don't argue
pointless issues simultaneously, or else we run the risk of running out
again.

Thanks for your attention to this important matter,
Dan
> 
> 

Re: GCC to open the C++ demangle API?

[mike stump]

> Date: Tue, 19 Mar 2002 21:39:16 +0000
> To: gcc@gcc.gnu.org
> From: Andrew Marlow <apm35@student.open.ac.uk>

> I agree with RMS that since there is no standard for name mangling
> in C++

Hum, and what if there were?  What if you were wrong and the
readings.html page had a pointer to an abi standard for C++ that not
only had a standard for mangling, but also mandated a demangler for it
as well?

What then?

Re: GCC to open the C++ demangle API?

[Joe Buck]

Andrew Marlow <apm35@student.open.ac.uk> writes:
> > As the OP I would like to chip in at this point. I no longer wish for the
> > API to be opened. I agree with RMS that since there is no standard for
> > name mangling in C++ the most appropriate license for this code is the GPL
> > rather than the LGPL.

Jason Merrill writes:
> But there IS a standard for name mangling.  And there are at least two
> other vendors with compatible compilers: HP and Intel.
> 
>   http://www.codesourcery.com/cxx-abi/abi.html#mangling

Furthermore RMS has already agreed to change the license, so this issue is
now moot and we can argue about something else. :-)

Re: GCC to open the C++ demangle API?

[Jason Merrill]

>>>>> "Andrew" == Andrew Marlow <apm35@student.open.ac.uk> writes:

> As the OP I would like to chip in at this point. I no longer wish for the
> API to be opened. I agree with RMS that since there is no standard for
> name mangling in C++ the most appropriate license for this code is the GPL
> rather than the LGPL.

But there IS a standard for name mangling.  And there are at least two
other vendors with compatible compilers: HP and Intel.

  http://www.codesourcery.com/cxx-abi/abi.html#mangling

Jason

Re: GCC to open the C++ demangle API?

[Andrew Marlow]

mark@codesourcery.com writes:
>
>--On Monday, March 04, 2002 05:45:21 PM -0300 Alexandre Oliva 
><aoliva@redhat.com> wrote:
>
>> On Mar  4, 2002, Phil Edwards <phil@jaj.com> wrote:
>>> The cplus_demangle_v3 is the more public entry point, I /think/, and
>>> the __cxa_demangle one is for completeness with the rest of the new
>ABI.
>>
>> If __cxa_demangle is indeed demanded by the C++ ABI, then it appears
>> to me that it would be appropriate to place Carlo's implementation in
>> libsupc++, whose license is already GPL plus runtime exception.

As the OP I would like to chip in at this point. I no longer wish for the
API to be opened. I agree with RMS that since there is no standard for
name mangling in C++ the most appropriate license for this code is the GPL
rather than the LGPL. If there is ever an ABI for C++ then I expect the
API will be opened and LGPL'd at that point. In the meantime I am going to
have to find other way to solve my problem. I will probably write a
shellscript or a perl script that uses the c++ filt command.

-Andrew M.

Re: GCC to open the C++ demangle API?

[Richard Stallman]

    But you were objecting to David O'Brien claiming (falsely) that Bison was
    a ripoff of Byacc.

That is not what he said.  He said that we had done something with
Byacc and that Corbett was angry at us for that.  

      Given this, you should have said, in your first
    message, as you do now, that "The code we used with Corbett's explicit
    cooperation is in fact the core of Bison", and your claim that this is not
    relevant to the point you made is false.

Bison was not relevant at all.  The accusation was about Byacc.

    Exactly.  I only regret that your first message did not include this
    material, as I then would not have needed to prompt you to get you to set
    the record properly straight.

I wish you regretted the way you treated me.  You thought I should
have explained the history of Bison, so you made an accusation against
me so that I would give that explanation to defend myself.

Now that the record is "properly straight" on this point, everyone can
see there was no reason for your fuss.  That short message took me 20
minutes to write, and this one took another 20 minutes.  I have other
work to do; please stop creating problems for me to solve.

Re: GCC to open the C++ demangle API?

[Joe Buck]

>     > I don't believe this either.  We used some of his code once,
>     > and he gave us his explicit cooperation with that.
> 
>     I don't think "We used some of his code once" is an appropriate thing
>     to say, given that the Bison manual and AUTHORS file says
> 
> The words are appropriate.  The code we used with Corbett's explicit
> cooperation is in fact the core of Bison, but its identity was not
> relevant to the point I made.

But you were objecting to David O'Brien claiming (falsely) that Bison was
a ripoff of Byacc.  Given this, you should have said, in your first
message, as you do now, that "The code we used with Corbett's explicit
cooperation is in fact the core of Bison", and your claim that this is not
relevant to the point you made is false.  You were answering an accusation
that Bison ripped off byacc.  In doing so, you suggested by your wording
that Corbett's contribution to Bison was minor.  The reason O'Brien is
wrong is because you and Corbett willingly collaborated to produce Bison,
and the Bison documentation properly credits his contribution, not because
"We used some of his code once"

> I was well aware of all these facts when I carefully chose my words.
> By the way, I obtained the original version of Bison directly from
> Corbett in January 1984.

Exactly.  I only regret that your first message did not include this
material, as I then would not have needed to prompt you to get you to set
the record properly straight.

David, you can apologize now any time you want.

Re: GCC to open the C++ demangle API?

[Richard Stallman]

    > I don't believe this either.  We used some of his code once,
    > and he gave us his explicit cooperation with that.

    I don't think "We used some of his code once" is an appropriate thing
    to say, given that the Bison manual and AUTHORS file says

The words are appropriate.  The code we used with Corbett's explicit
cooperation is in fact the core of Bison, but its identity was not
relevant to the point I made.

    Now, this was more than 15 years ago, so I'm sure that you simply forgot, but
    you really should avoid this kind of phrasing.

I was well aware of all these facts when I carefully chose my words.
By the way, I obtained the original version of Bison directly from
Corbett in January 1984.

Re: GCC to open the C++ demangle API?

[Joe Buck]

>     This is not a good situation.  The FSF took Berkeley's YACC and GPL'ed
>     it[*].

RMS writes:
> I think you are mistaken.  We have never done anything with BYACC as
> far as I know.
> 
>     [*] to the displeasure of Robert Corbett, the Byacc author.
> 
> I don't believe this either.  We used some of his code once,
> and he gave us his explicit cooperation with that.

I don't think "We used some of his code once" is an appropriate thing
to say, given that the Bison manual and AUTHORS file says

"Bison was written primarily by Robert Corbett"

and REFERENCES credits Corbett's 1985 PhD thesis for the encoding of
the parse tables.

The earliest reference I can find to bison is from 1986, see

http://compilers.iecc.com/comparch/article/86-01-056

That article suggests that there was interaction in both directions:
RMS used Corbett's code and then Corbett used RMS's code.

Now, this was more than 15 years ago, so I'm sure that you simply forgot, but
you really should avoid this kind of phrasing.  After all, the only thing
that free software contributors (especially of the academic variety) ask
for in the end is proper credit, so credit should be generously given.

In any case, byacc came out after bison and was originally based on a
later version of Corbett's work, so David O'Brien's claims otherwise are
just wrong.  The FSF didn't "rip off byacc", even though it would have
been completely legal if they had.

Re: GCC to open the C++ demangle API?

[Richard Stallman]

    This is not a good situation.  The FSF took Berkeley's YACC and GPL'ed
    it[*].

I think you are mistaken.  We have never done anything with BYACC as
far as I know.

    [*] to the displeasure of Robert Corbett, the Byacc author.

I don't believe this either.  We used some of his code once,
and he gave us his explicit cooperation with that.

Re: GCC to open the C++ demangle API?

[Robert Dewar]

[*] to the displeasure of Robert Corbett, the Byacc author.

How ironic. Robert Corbett deliberately chooses a license whose whole
purpose is to abrogate any control over deriviative works, and then
is displeased when someone creates a deriviative work in accordance
with that license. 

You can't have it both ways, either you decide to relinquish control over
deriviative works, in which case you can't complain about what people do,
or you write a license that makes sure that people do not do displeasing
things :-)

To me, BSD is designed to result in code forks, which is not so terrible,
but if you think it is terrible, you should choose a license that prevents
such forks, or at least discourages them.

Yes, yes, I know, this is off topic, I apologize, but it seems like this
needs to be said. After all if Microsoft had taken Byacc, you would be
even less likely to be able to take their additions and changes.

Re: GCC to open the C++ demangle API?

[David O'Brien]

On Mon, Mar 04, 2002 at 11:13:31AM -0800, Zack Weinberg wrote:
> Perhaps the sanest thing to do would be distribute it separately,
> under a permissive license -- I would recommend GPL+runtime exception
> or three-clause BSD, not LGPL.  Get it packaged and included in major
> free operating system distributions, contribute patches for other
> libraries (including those included with GCC) to make them use it, etc.

This is not a good situation.  The FSF took Berkeley's YACC and GPL'ed
it[*].  Contributions to Byacc(under the name Bison) were GPL'ed, thus
preventing the changes from being also committed to Byacc.

This dual GPL/BSD licensing has not worked well in some cases, and only
leads to code forks -- purely because of licensing issues.

[*] to the displeasure of Robert Corbett, the Byacc author.
-- 
-- David  (obrien@FreeBSD.org)

Re: GCC to open the C++ demangle API?

[Mark Mitchell]

--On Tuesday, March 05, 2002 09:06:54 PM +0100 Theodore Papadopoulo 
<Theodore.Papadopoulo@sophia.inria.fr> wrote:

>
>
> mark@codesourcery.com said:
>> The problem is that the one that we contributed -- thinking that it
>> would be placed under a libgcc-style license -- was, over my
>> objections, only placed in the FSF tree under the GPL.  There's no
>> reason to think that RMS is going to allow Carlo's version to be
>> libgcc'd while our version was not.  The right place to take this
>> debate is to the FSF; there is nothing we can do here.
>
> Except maybe put some (kind) pressure on them by explaining why the
> current  situation does not allow the implementations of some interfaces
> in  libstdc++ and libjava as pointed by by Zack in a previous message.

Yes, this was pointed out as part of the initial discussion, which took
place on the Steering Committee list.

It's fine for us to build consensus here, but in the end people will
need to raise this issue with the FSF.

Yours,

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC to open the C++ demangle API?

[Theodore Papadopoulo]

mark@codesourcery.com said:
> The problem is that the one that we contributed -- thinking that it
> would be placed under a libgcc-style license -- was, over my
> objections, only placed in the FSF tree under the GPL.  There's no
> reason to think that RMS is going to allow Carlo's version to be
> libgcc'd while our version was not.  The right place to take this
> debate is to the FSF; there is nothing we can do here. 

Except maybe put some (kind) pressure on them by explaining why the current 
situation does not allow the implementations of some interfaces in 
libstdc++ and libjava as pointed by by Zack in a previous message.

	Theo.

--------------------------------------------------------------------
Theodore Papadopoulo
Email: Theodore.Papadopoulo@sophia.inria.fr Tel: (33) 04 92 38 76 01
 --------------------------------------------------------------------

Re: GCC to open the C++ demangle API?

[Mark Mitchell]

--On Monday, March 04, 2002 05:45:21 PM -0300 Alexandre Oliva 
<aoliva@redhat.com> wrote:

> On Mar  4, 2002, Phil Edwards <phil@jaj.com> wrote:
>
>> The cplus_demangle_v3 is the more public entry point, I /think/, and
>> the __cxa_demangle one is for completeness with the rest of the new ABI.
>
> If __cxa_demangle is indeed demanded by the C++ ABI, then it appears
> to me that it would be appropriate to place Carlo's implementation in
> libsupc++, whose license is already GPL plus runtime exception.

There's no point in having two of these things.  Whichever one is
better (Carlo's version, or the version we originally contributed)
should go in.

The problem is that the one that we contributed -- thinking that it would
be placed under a libgcc-style license -- was, over my objections, only
placed in the FSF tree under the GPL.  There's no reason to think that
RMS is going to allow Carlo's version to be libgcc'd while our version
was not.  The right place to take this debate is to the FSF; there is
nothing we can do here.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com

Re: GCC to open the C++ demangle API?

[Richard Stallman]

If you think of GCC as "open source" you are likely to find all our
decisions perplexing.  The GNU Project is part of the Free Software
Movement; its basic idea, and the reason why I wrote GCC in the first
place, is that *software should be free*.  Non-free published software
constitutes a social problem, and we aim to solve that problem.  The
Open Source Movement was founded, many years after GCC was written
specifically to avoid saying such things.

We use the GPL so as to maximize the effect we can get from our code
in fixing the social problem of proprietary software.  For more
explanation, see http://www.gnu.org/philosophy/pragmatic.html and
http://www.gnu.org/philosophy/x.html.

Re: GCC to open the C++ demangle API?

[Bryce McKinlay]

Alexandre Oliva wrote:

>>The cplus_demangle_v3 is the more public entry point, I /think/, and
>>the __cxa_demangle one is for completeness with the rest of the new ABI.
>>
>
>If __cxa_demangle is indeed demanded by the C++ ABI, then it appears
>to me that it would be appropriate to place Carlo's implementation in
>libsupc++, whose license is already GPL plus runtime exception.
>

libjava needs this as well, so ideally it would be somewhere where it 
can be used by both (a convenience library?)

regards

Bryce.

Re: GCC to open the C++ demangle API?

[Phil Edwards]

On Mon, Mar 04, 2002 at 09:14:06PM +0000, John Levon wrote:
> On Mon, Mar 04, 2002 at 04:12:21PM -0500, Phil Edwards wrote:
> > 
> > The libiberty headers have never been installed.  I'm pushing to change
> 
> moz moz 280 rpm -qf /usr/include/libiberty.h
> binutils-2.10.0.18-1
> 
> So at least some vendors are doing so.

I should say, "the libiberty Makefile never installs its own headers,"
and of course vendors are free to do what they want.  A user building GCC
from scratch would never see the headers installed, for instance.

And even that statement is now wrong, since DJ just approved the patch.  :-)
So the libiberty headers for GCC 3.2 will be able to install themselves.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 04:12:21PM -0500, Phil Edwards wrote:

> > If you really want to make your point, then don't install the headers. I
> > suspect you'll find most downstream vendors end up reverting that bit
> > anyway though ...
> 
> The libiberty headers have never been installed.  I'm pushing to change

moz moz 280 rpm -qf /usr/include/libiberty.h
binutils-2.10.0.18-1

So at least some vendors are doing so.

> that; there are some useful routines there for other programs to use,
> but right now nobody can take proper advantage of them.  I've actually

great to hear

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: GCC to open the C++ demangle API?

[Phil Edwards]

On Mon, Mar 04, 2002 at 08:40:34PM +0000, John Levon wrote:
> 
> You install a .so for libbfd but not for libiberty.
> 
> If you really want to make your point, then don't install the headers. I
> suspect you'll find most downstream vendors end up reverting that bit
> anyway though ...

The libiberty headers have never been installed.  I'm pushing to change
that; there are some useful routines there for other programs to use,
but right now nobody can take proper advantage of them.  I've actually
posted a patch recently, but no comments have been posted.

Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC to open the C++ demangle API?

[Alexandre Oliva]

On Mar  4, 2002, Phil Edwards <phil@jaj.com> wrote:

> The cplus_demangle_v3 is the more public entry point, I /think/, and
> the __cxa_demangle one is for completeness with the rest of the new ABI.

If __cxa_demangle is indeed demanded by the C++ ABI, then it appears
to me that it would be appropriate to place Carlo's implementation in
libsupc++, whose license is already GPL plus runtime exception.

-- 
Alexandre Oliva   Enjoy Guarana', see http://www.ic.unicamp.br/~oliva/
Red Hat GCC Developer                  aoliva@{cygnus.com, redhat.com}
CS PhD student at IC-Unicamp        oliva@{lsd.ic.unicamp.br, gnu.org}
Free Software Evangelist                Professional serial bug killer

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 02:46:34PM -0500, Daniel Jacobowitz wrote:

> I did not say that the interface of the two demangling functions
> wouldn't change.  Functions get added to libiberty fairly often, but
> rarely change or disappear.  That makes depending on an installed
> version somewhat tricky.
> 
> It is if they have a different copy installed than you built against! 

These problems exist for all libraries. If I want to build for a
specific platform (for example RedHat Linux 7.x), then I need to use the
compatible version of the libraries to build against.

In what way is libbfd and libiberty so different from other libraries ?

If my user wants to install his own version of binutils, then he is free
to do so, but I expect them to recompile my app ... this is pretty much
the definition of binary incompatibility :)

> We don't install linkable versions of the shared library for a reason. 
> (At least I think we don't.)

You install a .so for libbfd but not for libiberty.

If you really want to make your point, then don't install the headers. I
suspect you'll find most downstream vendors end up reverting that bit
anyway though ...

regards
john
-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: GCC to open the C++ demangle API?

[Robert Dewar]

>>Can't Carlo dual license under LGPL and GPL+runtime-exception ?


Of course, you can issue code under lots of different licenses. It would
be fine for him to have a proprietary license as well. In fact the
combination of GPL + proprietary license makes good sense to some.

Re: GCC to open the C++ demangle API?

[Daniel Jacobowitz]

On Mon, Mar 04, 2002 at 07:01:41PM +0000, John Levon wrote:
> On Mon, Mar 04, 2002 at 12:18:29PM -0500, Phil Edwards wrote:
> 
> > I'm not sure what John meant when he said that linking against libiberty is
> > not allowed, either.  The demangling routines are under the GPL, and their
> > API will not be changing (trust me, I accidentally broke this for a few days
> > recently, lots of programs noticed).  You're free to link against libiberty.
> 
> This is in direct contradiction to what the binutils list told me last
> week (and indeed what they said to someone reporting that the
> cplus_demangle wasn't in the installed libiberty headers).
> 
> In fact I was told in able to do binary work, I needed to include
> something of the order of 13Mb of source in my application (libbfd +
> libiberty).

I did not say that the interface of the two demangling functions
wouldn't change.  Functions get added to libiberty fairly often, but
rarely change or disappear.  That makes depending on an installed
version somewhat tricky.

> I didn't get a satisfactor answer for why it's not approved - they
> mentioned that BIC is broken for libbfd every week or so, which is
> hardly a problem, unless my users are upgrading every week to new
> binutils (which they are not).

It is if they have a different copy installed than you built against! 
We don't install linkable versions of the shared library for a reason. 
(At least I think we don't.)

> I shall certainly continue linking against libiberty/bfd until a
> sensible solution comes about.
> 
> > Perhaps you're worried about GPL/LGPL issues.  That's a huge political issue;
> > we'd like the code to be LGPL, but the FSF disagrees for now.  At the moment,
> > if you call the run-time demangling routines, your code must be full GPL.
> 
> no, this is irrelevant afaik ...
> 
> regards
> john
> 
> -- 
> I am a complete moron for forgetting about endianness. May I be
> forever marked as such.
> 

-- 
Daniel Jacobowitz                           Carnegie Mellon University
MontaVista Software                         Debian GNU/Linux Developer

Re: GCC to open the C++ demangle API?

[Zack Weinberg]

On Mon, Mar 04, 2002 at 01:42:41PM -0500, Phil Edwards wrote:
> On Mon, Mar 04, 2002 at 06:47:49PM +0100, Carlo Wood wrote:
> > The (legal) problem now is: how can I write a drop-in for these libiberty
> > functions when I want it to be LGPL?
> 
> I've no idea.

It's your (Carlo's) code, you can license it however you want.  The
problem would be getting permission from the FSF to distribute it as
part of GCC, while leaving the license as stated.

Perhaps the sanest thing to do would be distribute it separately,
under a permissive license -- I would recommend GPL+runtime exception
or three-clause BSD, not LGPL.  Get it packaged and included in major
free operating system distributions, contribute patches for other
libraries (including those included with GCC) to make them use it, etc.

We could then use that as leverage to get the FSF to change the
licensing on the libiberty implementation.

zw

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 01:42:41PM -0500, Phil Edwards wrote:

> > The (legal) problem now is: how can I write a drop-in for these libiberty
> > functions when I want it to be LGPL?
> 
> I've no idea.

Can't Carlo dual license under LGPL and GPL+runtime-exception ?

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 12:28:03PM -0500, Phil Edwards wrote:

> To be a drop-in replacement for the libiberty stuff, you would need to
> provide those two functions as wrappers to your own demangler.  That way
> existing code won't change.  Take a look at libiberty/cp-demangle.c.

Would this mean I can get the source code equivalent of "c++filt -s
auto" without having to link against the rest of the code ?

As it is it's impossible to split out the demangler code from much of
the rest of libiberty (without making bug merges difficult)

That's what I personally would like.

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 12:18:29PM -0500, Phil Edwards wrote:

> I'm not sure what John meant when he said that linking against libiberty is
> not allowed, either.  The demangling routines are under the GPL, and their
> API will not be changing (trust me, I accidentally broke this for a few days
> recently, lots of programs noticed).  You're free to link against libiberty.

This is in direct contradiction to what the binutils list told me last
week (and indeed what they said to someone reporting that the
cplus_demangle wasn't in the installed libiberty headers).

In fact I was told in able to do binary work, I needed to include
something of the order of 13Mb of source in my application (libbfd +
libiberty).

I didn't get a satisfactor answer for why it's not approved - they
mentioned that BIC is broken for libbfd every week or so, which is
hardly a problem, unless my users are upgrading every week to new
binutils (which they are not).

I shall certainly continue linking against libiberty/bfd until a
sensible solution comes about.

> Perhaps you're worried about GPL/LGPL issues.  That's a huge political issue;
> we'd like the code to be LGPL, but the FSF disagrees for now.  At the moment,
> if you call the run-time demangling routines, your code must be full GPL.

no, this is irrelevant afaik ...

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: GCC to open the C++ demangle API?

[Phil Edwards]

On Mon, Mar 04, 2002 at 06:47:49PM +0100, Carlo Wood wrote:
> 
> Since I was forced to write my demangler ONLY because libiberty
> is GPL - I feel like kicking back by refusing to release my demangler
> under the GPL.  Instead I want to release it under the LGPL or the libstdc++
> license (which gives people much more freedom to use it).

As an aside, it's called the "GPL with runtime exception," and more than
just libstdc++/libsupc++ use it.  libgcc does also, and I /think/ other
bits of libiberty might also, but I haven't checked.


> The (legal) problem now is: how can I write a drop-in for these libiberty
> functions when I want it to be LGPL?

I've no idea.


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC to open the C++ demangle API?

[Robert Dewar]

<<Perhaps you're worried about GPL/LGPL issues.  That's a huge political issue;
we'd like the code to be LGPL, but the FSF disagrees for now.  At the moment,
if you call the run-time demangling routines, your code must be full GPL.
>>

It is perhaps worth noting that this is only true if you plan to distribute
the resulting software, the licensing never restricts what you do for your
own use.

Re: GCC to open the C++ demangle API?

[Carlo Wood]

On Mon, Mar 04, 2002 at 12:28:03PM -0500, Phil Edwards wrote:
> To be a drop-in replacement for the libiberty stuff, you would need to
> provide those two functions as wrappers to your own demangler.  That way
> existing code won't change.  Take a look at libiberty/cp-demangle.c.
> 
> The cplus_demangle_v3 is the more public entry point, I /think/, and
> the __cxa_demangle one is for completeness with the rest of the new ABI.
> There are a couple of places in libcups++ where it's almost called, but
> avoided with a comment saying, "must wait until it's LGPL."

Hmm.

Since I was forced to write my demangler ONLY because libiberty
is GPL - I feel like kicking back by refusing to release my demangler
under the GPL.  Instead I want to release it under the LGPL or the libstdc++
license (which gives people much more freedom to use it).

I have no intention to put people in the same shitty situation that
I was in: the code exists as Open Source but you can't use it because
of the license.  Sorry, but I don't like the GPL.

The (legal) problem now is: how can I write a drop-in for these libiberty
functions when I want it to be LGPL?

-- 
Carlo Wood <carlo@alinoe.com>

Re: GCC to open the C++ demangle API?

[Phil Edwards]

On Mon, Mar 04, 2002 at 06:16:39PM +0100, Carlo Wood wrote:
> 1) Someone spelling out what I need to download/print and sign
>    and what license files and headers I need to add: I am a
>    zero when it comes to legal stuff and not motivated to
>    dive into that I must say.

An explanation of what/why can be found starting at GCC's own pages:
http://gcc.gnu.org/contribute.html and the following the "see some docs"
link for more.

I'll send you the forms by private email shortly.


> 2) The exact API description that people want me to implement.
[...]
> > All you would need to do would be to add the __cxa_demangle and
> > cplus_demangle_v3 entry points.
> 
> That doesn't tell me much.

To be a drop-in replacement for the libiberty stuff, you would need to
provide those two functions as wrappers to your own demangler.  That way
existing code won't change.  Take a look at libiberty/cp-demangle.c.

The cplus_demangle_v3 is the more public entry point, I /think/, and
the __cxa_demangle one is for completeness with the rest of the new ABI.
There are a couple of places in libcups++ where it's almost called, but
avoided with a comment saying, "must wait until it's LGPL."


Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC to open the C++ demangle API?

[Phil Edwards]

On Mon, Mar 04, 2002 at 04:25:49PM +0000, Andrew Marlow wrote:
> levon@movementarian.org writes:
> >On Mon, Mar 04, 2002 at 10:48:03AM +0000, Andrew Marlow wrote:
> >
> >> There does not appear to be a public API for demangling C++ symbol
> >> names with the GNU C++ compiler. The code is there in binutils because
> >> c++filt uses it. However, the API has not been 'opened'.
> [snip]
> >Of course you could just link to the platform libiberty and use
> >cplus_demangle as usual there ... (but this is not "allowed")
> 
> Indeed. That's what I meant when I said that the API has not been opened.

That doesn't really clarify things...

> I have received other email that says 'just use libiberty'. However I do
> not want to use an API that has not been opened.

You're using "opened" in a way that doesn't make a whole lot of sense.
I'm not sure what John meant when he said that linking against libiberty is
not allowed, either.  The demangling routines are under the GPL, and their
API will not be changing (trust me, I accidentally broke this for a few days
recently, lots of programs noticed).  You're free to link against libiberty.

Perhaps you're worried about GPL/LGPL issues.  That's a huge political issue;
we'd like the code to be LGPL, but the FSF disagrees for now.  At the moment,
if you call the run-time demangling routines, your code must be full GPL.



Phil

-- 
If ye love wealth greater than liberty, the tranquility of servitude greater
than the animating contest for freedom, go home and leave us in peace.  We seek
not your counsel, nor your arms.  Crouch down and lick the hand that feeds you;
and may posterity forget that ye were our countrymen.            - Samuel Adams

Re: GCC to open the C++ demangle API?

[Carlo Wood]

On Mon, Mar 04, 2002 at 01:33:51PM +0000, John Levon wrote:
> Also check out Carlo Woods' implementation: http://libcw.sf.net/

From the mails I received in the past, it seems that my
implementation is the best existing demangler so far.
I've been contacted (in particular by Jason Merrill)
with the request to donate my implementation for libiberty
and libsupc++.

In the past I've been contacted by Daniel Berlin who was the
C++ support maintainer for gdb and he ported the implementation
to C for use in gdb - unfortunately he lost the harddisk
where this was stored.

I am more then willing to donate my implementation
(320 man hours of work) to the open source community (and FSF),
but I need a little help with two things:
1) Someone spelling out what I need to download/print and sign
   and what license files and headers I need to add: I am a
   zero when it comes to legal stuff and not motivated to
   dive into that I must say.
2) The exact API description that people want me to implement.

I think that Jason will help me with that when he comes back
from Greece in a week.

In the meantime it might still be nice to hear from other
people about what they expect of such an API.

Jason wrote me:

> All you would need to do would be to add the __cxa_demangle and
> cplus_demangle_v3 entry points.

That doesn't tell me much.

-- 
Carlo Wood <carlo@alinoe.com>

Re: GCC to open the C++ demangle API?

[Andrew Snare]

At 04:39 PM 4/03/2002 +0000, John Levon wrote:
>On Mon, Mar 04, 2002 at 04:25:49PM +0000, Andrew Marlow wrote:
>
> > Indeed. That's what I meant when I said that the API has not been opened.
> > I have received other email that says 'just use libiberty'. However I do
> > not want to use an API that has not been opened. On other platforms it has
> > been opened by its own dedicated library and header in /usr/lib and
> > /usr/include respectively. Could this be done with GCC/G++ ?
>
>I would love to see a little library spun out that is /just/ for
>demangling.
>
>but it's not worth talking about unless someone who has the time to
>maintain it actually does so - and that's not me.

I wanted this as well, to enable some software we develop to display the 
call-stack at any given point (usually during failure, but also for 
tracking memory allocation). While libiberty allowed the decoding, being 
GPL and not LGPL meant we couldn't use it. I'm not complaining about the 
license or trying to start a flame-war here, but there are some situations 
where it's not feasible to use libiberty.

  - Andrew

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 04:25:49PM +0000, Andrew Marlow wrote:

> Indeed. That's what I meant when I said that the API has not been opened.
> I have received other email that says 'just use libiberty'. However I do
> not want to use an API that has not been opened. On other platforms it has
> been opened by its own dedicated library and header in /usr/lib and
> /usr/include respectively. Could this be done with GCC/G++ ?

I would love to see a little library spun out that is /just/ for
demangling.

but it's not worth talking about unless someone who has the time to
maintain it actually does so - and that's not me.

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

Re: GCC to open the C++ demangle API?

[Andrew Marlow]

levon@movementarian.org writes:
>On Mon, Mar 04, 2002 at 10:48:03AM +0000, Andrew Marlow wrote:
>
>> There does not appear to be a public API for demangling C++ symbol
>> names with the GNU C++ compiler. The code is there in binutils because
>> c++filt uses it. However, the API has not been 'opened'.
[snip]
>Of course you could just link to the platform libiberty and use
>cplus_demangle as usual there ... (but this is not "allowed")

Indeed. That's what I meant when I said that the API has not been opened.
I have received other email that says 'just use libiberty'. However I do
not want to use an API that has not been opened. On other platforms it has
been opened by its own dedicated library and header in /usr/lib and
/usr/include respectively. Could this be done with GCC/G++ ?

-Andrew M.

Re: GCC to open the C++ demangle API?

[John Levon]

On Mon, Mar 04, 2002 at 10:48:03AM +0000, Andrew Marlow wrote:

> There does not appear to be a public API for demangling C++ symbol
> names with the GNU C++ compiler. The code is there in binutils because
> c++filt uses it. However, the API has not been 'opened'.

What do you mean by this exactly ?

> Any ideas why
> this is (other than it being non-portable) ? 

apparently any tool wanting any features from binutils has to include
the whole necessary source itself. That means you have to ship
libiberty. And in my case, libbfd as well (!)

Of course you could just link to the platform libiberty and use
cplus_demangle as usual there ... (but this is not "allowed")

> the GNU C++ compiler environment opened access to the demangling

Also check out Carlo Woods' implementation: http://libcw.sf.net/

regards
john

-- 
I am a complete moron for forgetting about endianness. May I be
forever marked as such.

GCC to open the C++ demangle API?

[Andrew Marlow]

There does not appear to be a public API for demangling C++ symbol
names with the GNU C++ compiler. The code is there in binutils because
c++filt uses it. However, the API has not been 'opened'. Any ideas why
this is (other than it being non-portable) ? 

IMO it would be good if
the GNU C++ compiler environment opened access to the demangling
routine. Other compiler environments have opened up the API.
There is demangle on HPUX, cplus_demangle on Solaris etc.

Regards,

Andrew M.