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

[David Allouche]

On Thu, Nov 07, 2002 at 01:53:44AM +0300, Igor V. Kovalenko wrote:
> David Allouche wrote:
> >
> >What would you like me to tell???
> 
> I personally like to see the output of 'ld -V' :)

address@hidden home$ ld -V
GNU ld version 2.13.90.0.10 20021010 Debian GNU/Linux
  Supported emulations:
   elf_i386
   i386linux
address@hidden home$ 


> 
> >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.

Compiling the canonical C++ hello.cc:

Reading specs from /usr/lib/gcc-lib/i386-linux/2.95.4/specs
gcc version 2.95.4 20011002 (Debian prerelease)
 /usr/lib/gcc-lib/i386-linux/2.95.4/cpp0 -lang-c++ -v -D__GNUC__=2 -D__GNUG__=2 
-D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ 
-D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) 
-D__EXCEPTIONS -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ hello.cc 
/tmp/cc5BLuQI.ii
GNU CPP version 2.95.4 20011002 (Debian prerelease) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../include/g++-3
 /usr/local/include
 /usr/lib/gcc-lib/i386-linux/2.95.4/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
 /usr/lib/gcc-lib/i386-linux/2.95.4/../../../../i386-linux/include
End of omitted list.
 /usr/lib/gcc-lib/i386-linux/2.95.4/cc1plus /tmp/cc5BLuQI.ii -quiet -dumpbase 
hello.cc -version -o /tmp/ccivmGYC.s
GNU C++ version 2.95.4 20011002 (Debian prerelease) (i386-linux) compiled by 
GNU C version 2.95.4 20011002 (Debian prerelease).
 as -V -Qy -o /tmp/cc2QO0u1.o /tmp/ccivmGYC.s
GNU assembler version 2.13.90.0.10 (i386-linux) using BFD version 2.13.90.0.10 
20021010 Debian GNU/Linux
 /usr/lib/gcc-lib/i386-linux/2.95.4/collect2 -m elf_i386 -dynamic-linker 
/lib/ld-linux.so.2 -o hello /usr/lib/crt1.o /usr/lib/crti.o 
/usr/lib/gcc-lib/i386-linux/2.95.4/crtbegin.o 
-L/usr/lib/gcc-lib/i386-linux/2.95.4 /tmp/cc2QO0u1.o -lstdc++ -lm -lgcc -lc 
-lgcc /usr/lib/gcc-lib/i386-linux/2.95.4/crtend.o /usr/lib/crtn.o


> >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.

You seem more knowledgeable than I in this matter.

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

What do you mean? Pointer chase? Is that a GUILE option? Or are you
referring to something similar to freemem-poisoning?

-- 
David Allouche         | GNU TeXmacs -- Writing is a pleasure
Free software engineer |    http://www.texmacs.org
   http://ddaa.net     |    http://alqua.com/tmresources
   address@hidden  |    address@hidden
TeXmacs is NOT a LaTeX front-end and is unrelated to emacs.