Hey Eric,

I found this bug too in gcc3 (in build 1154). As a workaround, compile that file without -g. The bug is that a .stabs debug symbol is getting inserted into the common section of the .o.

Andy


Message: 15
Date: Mon, 15 Jul 2002 17:43:06 -0700 (PDT)
From: Eric Albert <[EMAIL PROTECTED]>
To: [EMAIL PROTECTED]
Subject: Common symbol emitted despite -fno-common

I have a rather complicated library that I'm trying to build without
optimizations so I can debug. When I build it, though, I get this line
from ld when linking a collection of .libs together into my dylib:
foo.lib definition of common delegate:v(1,99) (size 136)
and ld refuses to link.

That's typically not that big of a deal -- common symbols are easy to
eliminate. I can't figure out how to get rid of this one, though. Here's
what I know:
-I'm already compiling with -fno-common, if that matters.
-The problem does not happen if I build with -O1.
-I don't have a variable in my code called 'v'.
-Only one .o file contains the symbol, so it isn't really a "common"
symbol.
-nm prints this when given that .o file:
00000088 C delegate:v(1,99)
-nm -m prints this for the symbol:
00000088 (common) [referenced dynamically] external delegate:v(1,99)
-If I comment out two lines in a non-inlined, completely normal member
function in the class defined in the .o file, the common symbol
disappears. Unfortunately, I need those lines for error checking.

Does anyone know how I can keep the compiler from emitting a symbol that
it thinks is common even though it's only in one object file? Is the fact
that this doesn't happen when the optimizer is enabled a bug? And what
exactly is a delegate, or, for that matter, a compiler-defined common
symbol?

Thanks in advance,
Eric

--
Eric Albert [EMAIL PROTECTED]
http://rescomp.stanford.edu/~ejalbert/



-----------
Andrew Begel
Ph.D. Candidate
Computer Science Division
University of California, Berkeley

Reply via email to