This is the mail archive of the gcc-patches@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: gcj, shared libraries, and -Bsymbolic


On Tue, Jan 25, 2005 at 02:58:03PM +0000, Andrew Haley wrote:
> Jakub Jelinek writes:
>  > On Tue, Jan 25, 2005 at 02:43:55PM +0000, Andrew Haley wrote:
>  > > The C semantics of the dynamic linker don't play well with Java: when
>  > > a method in a shared library accesses some locally defined object it
>  > > wants the local copy, not some other object with the same name that
>  > > happens to be in a shared library earlier in the search path.
>  > > However, the semantics we require correspond quite nicely with the the
>  > > GNU linker option -Bsymbolic.
>  > 
>  > On the other side, -Bsymbolic doesn't work at all together with C++
>  > semantics.  So if you link both Java and C++ code into a shared library
>  > and link with -Bsymbolic, C++ code will often misbehave.
> 
> Go on, give me a clue.  I'm not aware of the problem you describe.

<typeinfo>:
    // On platforms that support weak symbols, typeinfo names are merged.
    #define __GXX_MERGED_TYPEINFO_NAMES 1
...
    // In new abi we can rely on type_info's NTBS being unique,
    // and therefore address comparisons are sufficient.
    bool before(const type_info& __arg) const
    { return __name < __arg.__name; }
    bool operator==(const type_info& __arg) const
    { return __name == __arg.__name; }

With -Bsymbolic this assumption is no longer true.

	Jakub


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]