This is the mail archive of the gcc@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]

Re: Bug?


At 02:48 PM 2/28/99 +0100, you wrote:
>Hi all.  Here's another bug that is probably useless to you because
>you can't reproduce it :(.  Nevertheless:
>
>What could possibly be causing this (I am still using egcs-1.1.1 release,
>and binutils-2.9.1.0.15):
>
>g++ -shared -Wl,-soname,libr.so.0 -o libr.so.0.2.5 -fpic  version.o
>./buffers/dbstreambuf.o ./crosslink/crosslink.o ./ffstl/ffstl.o
>./io/file.o ./io/pipe.o ./io/sock.o ./io/traits.o
>./kernel/debugdaemon.o ./kernel/events.o ./kernel/execve.o
>./kernel/select.o ./kernel/timing.o ./kernel/signals.o
>./kernel/libr_app.o ./llists/cbll.o ./llists/expire.o >./llists/sbll.o
./net/inet_support.o
>./support/debugdebugcheckpoint.o ./support/debugmalloc.o
>./support/ostream_operators.o ./support/support.o ./support/sys.o
>./support/syslog.o ./support/debug.o ./support/demangle.o
>./utils/bcd2str.o ./utils/buf2str.o ./utils/char2str.o
>./utils/strerrno.o
>../support/debugdebugcheckpoint.o: In function `global constructors

Hmm. Looks like someone's explanation for the double dot goofiness
was a tad simplistic. Twelve lines with dots at the start, and one gets a
duplication and the others don't. If my ISP were stripping duplicates,
would this mean I'd have had eleven *missing* dots instead of one extra?

>keyed to int lexicographical_compare_3way<signed char const *,
>signed char const *>(signed char const *, signed char const *,
>signed char const *, signed char const *)':
>/usr/local/egcs/include/g++/stl_algobase.h:427: multiple definition
>of `global constructors keyed to int
>lexicographical_compare_3way<signed char const *, signed char const
>*>(signed char const *, signed char const *, signed char const *,
>signed char const *)'
>../llists/cbll.o:/home/carlo/c++/libr/src/llists/../../include/libr/

Well, we're now 2 for 13...

>debug.h:102: first defined here
>collect2: ld returned 1 exit status

>I think this must be a bug because I didn't change really anything big
>when this suddenly started to happen :/.

Not to mention, it's a bug to get duplicate symbols for "hidden" stuff like
init code and virtual tables, period.

[snip]

>00000004 T global constructors keyed to int
lexicographical_compare_3way<signed char const *, signed char const
*>(signed char const *, signed char const *, signed char const *, signed
char const *)

[snip]

>00000004 T global constructors keyed to int
lexicographical_compare_3way<signed char const *, signed char const
*>(signed char const *, signed char const *, signed char const *, signed
char const *)

Yup, it's in there twice, and so were a bunch of other things. A lot of
things were only in there once though.

>#ifdef __GNUG__
>#pragma implementation
>#endif

[Several #includes snipped]

That damn pragma again. I think it was causing someone else trouble a while
back. Try commenting it out. Also, you don't by chance have two inclusions
of the header with lexicographical_compare_threeway in two translation
units both with the "#pragma implementation"? That might confuse the
compiler enough to cause these duplicate symbol errors even for "hidden"
C++ symbols.

Also, you put "#pragma implementation" in a *header*, which may have been
included in more than one source file. (Was it?)

Pragmas are eeevil.

[#ifdef DEBUGDEBUG and everything after snipped]

>Note: debugdebugcheckpoint.h is completely empty (everything is between
>      #ifdef DEBUGDEBUG, which isn't defined).

Except for the damn pragma and the stuff #included after it.

>      sys.h and debug.h both start with a "#pragma interface" and should
>      be generating any code therefore...

...except that the compiler sees

#pragma implementation
...
#pragma interface
...
[templates]

and , I suspect, implements them. That generates code.

I am beginning to suspect that those particular pragmas are especially bad
for your health and sanity. Maybe there ought to be a surgeon general's
warning or something.

>"libr/cbll.h" and "llists_crosslink.h" do NOT contain a "#pragma interface"
>because that only made the total code grow.  Commenting out the
>"#pragma implementation ..." lines aboves doesn't make a difference.

Really? All of them, including in debugdebugcheckpoint.h?

Then it is definitely a bug and not a pragma problem (still a bug IMO since
pragmas are eeevil).

>_Adding_ a "#pragma interface" to "cbll.h" anyway removed the problem though;
>but as posted before - that makes the total size of the code grow ;).

I don't see how that can be. Either
* cbll.h is duplicated except with the "#pragma interface", in which
  case the code emitted should *shrink* with the pragma, or
* cbll.h is not duplicated, in which case the code emitted should not
  change AND there should be no duplicate symbol errors.

This means there's a bug that causes completely bogus, non-sensical
behavior revolving around the pragmas. Try commenting out all of the
pragmas everywhere in all of the sources and headers, and using the repo
thing instead. If the code size shrinks and the problem goes away, the
culprit is that bunch of eeevil pragmas.

>I'll add the "#pragma interface" to "cbll.h" as a work around for now.

I still think that removing all kinds of pragmas might do more good in the
long run than adding more pragmas whose observed behavior is, at the
minimum, difficult to understand.

[Bigger pragma-generated symbol table snipped]

>The reason that this helped is probably the fact that
>
>00000004 T global constructors keyed to int
lexicographical_compare_3way<signed char const *, signed char const
*>(signed char const *, signed char const *, signed char const *, signed
char const *)
>
>disappeared from cbll.o.

Damned freaky, since my (probably not-quite-complete) understanding of
"#pragma interface" is that it should be a no-op with "#pragma
implementation" and should reduce code size without it. So either the same
symbols should pop up, or a proper subset. I think there must be a weird,
poorly-or-un-documented interaction when a preprocessed sourcefile has
multiple pragmas of both kinds mixed around template code. I don't think it
was ever intended for a preprocessed sourcefile to have more than just one
of these pragmas or one of each, or at least more than just one occurrence
of "#pragma implementation".


-- 
   .*.  "Clouds are not spheres, mountains are not cones, coastlines are not
-()  <  circles, and bark is not smooth, nor does lightning travel in a
   `*'  straight line."    -------------------------------------------------
        -- B. Mandelbrot  |http://surf.to/pgd.net
_____________________ ____|________     Paul Derbyshire     pderbysh@usa.net
Programmer & Humanist|ICQ: 10423848|


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