This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: RFA: Please review the new C++ demangler patch
Phil Edwards <phil@jaj.com> writes:
> On Fri, Jun 27, 2003 at 10:06:56PM +0200, Gabriel Dos Reis wrote:
>> Benjamin Kosnik <bkoz@redhat.com> writes:
>>
>> | >2. libdemangle has few use for libstdc++. It is not a big deal,
>> | >but maybe confusing to users.
>> |
>> | Right. I was just using this to explain the idea. In reality, there
>> | needs to be a __cxa_demangle in libsupc++, irregardless: libdemangle
>> | should just link it from there and be done. Still, it's easier to
>> | express the dependency info this way.
>>
>> I do not believe there is any need to have libdemangle separate from
>> libstdc++. I do not believe taking the demangler out of libstdc++
>> would really solve the core issues.
>
> It needs to be outside of libstdc++ so that programs wishing for only core
> support can still use it. That's why it was moved to libsupc++, so that...
>
> gcc a_c++_program_only_using_clause_18.cc -lsupc++
>
> ...a.out does not depend on libstdc++.so at runtime. For more information,
> see PR 10246.
The demangler posted by H.J. Lu uses <vector>, but it doesn't depend
on libstdc++.a. As it links fine with the 'gcc' driver, I guess it
doesn't depends on any C++-specific support library either.
libstdc++.a depency is avoided by providing a custom allocator for the
vector.
The question is: have we any guarantee that providing a custom
allocator will be enough to use <vector> without linking to
libstdc++.a on the future?
> Of course, since the demangler in question uses symbols from
> libstdc++, we /still/ wouldn't have fixed that PR.
If libstdc++.a was the problem, the problem is solved.
As someone said that "we can't depend on libstdc++ at all", my work
consisted on avoiding the <vector> dependency as well.
As I see things, the real problem is the requirement of a C++
compiler.
--
Oscar