Re: [Texmacs-dev] g++-3.2 segfaults -- linker -- virtual tree destructor

[Igor V. Kovalenko]

David Allouche wrote:
> On Tue, Nov 05, 2002 at 05:22:21PM +0100, Joris van der Hoeven wrote:
>
> > > What binutils version are you using? I'm now in deep confusion :) Mine is:
> > >
> > > $ ld -V
> > > GNU ld version 2.13.90.0.10 20021010
> > >   Supported emulations:
> > >    elf_i386
> > >    i386linux
> > >    elf_i386_glibc21
> > >
> > > I simply want to find a difference. Tests show that guile is probably not 
> > > guilty...
> >
> > David: can you tell this?
> > I don't know whether g++-3.2 uses a different ld.
> > I compiled as you said: CXX=g++-3.2 LD=g++-3.2 ./configure and make.
>
>
> What would you like me to tell???

I personally like to see the output of 'ld -V' :)

> g++ probably uses the standard linker on the system to build the
> executables, and there is no linker present in the g++ distribution.

Yes, if it does not use precompiled default... I see the point.
$CXX -v my.cc -o my.exe
probably would be interesting as well.

> However, c++ link is much more complex than c link, so g++ does have
> some stuff to do with compiled objects before linking them, including but
> not restricted ;-) to: run-time type information, exception handling,
> template generation, generating implicit operators (perhaps), etc.
> (probably more arcane stuff).

Nope, all is in 'o' files... BFD counted. As to 'rtti' and all, 
'-fno-exceptions'
allows to discard rtti, I've done so with '-fno-rtti' added and had no linker 
errors.

No one have an exact explaination as of now, so I'm collecting the info.

> By the way, I was also puzzled by the "virtual tree dtor" fix. I
> though that there way maybe some broken code which changed tree_rep.op
> by mistake, so I did
>
> *** tree.hh     2002/11/06 10:59:05     1.1
> --- tree.hh     2002/11/06 10:59:11
> ***************
> *** 114,120 ****
>   
>   class tree_rep: concrete_struct {
>   public:
> !   tree_label op;
>     inline tree_rep (tree_label op2): op (op2) {}
>     friend class tree;
>   };
> --- 114,120 ----
>   
>   class tree_rep: concrete_struct {
>   public:
> !   const tree_label op;
>     inline tree_rep (tree_label op2): op (op2) {}
>     friend class tree;
>   };
>
> That makes sure that tree_rep.op is never modified after object
> creation (BTW, I propose this patch for inclusion). If there is some
> buggy assignation to tree_rep.op, it will fail to compile.
>
> But, to my dismay, that caused no compilation error.

What can you do with guile pointer chase? (I can be as well wrong here).

--
Regards,
Igor V. Kovalenko    mailto: iko at crec dot mipt dot ru