public inbox for gcc@gcc.gnu.org
 help / color / mirror / Atom feed
From: Paul Derbyshire <pderbysh@usa.net>
To: egcs@egcs.cygnus.com
Subject: Re: Bug?
Date: Sun, 28 Feb 1999 22:53:00 -0000	[thread overview]
Message-ID: <3.0.6.32.19990228110237.00980540@pop.globalserve.net> (raw)
In-Reply-To: <199902281348.OAA03093@jolan.ppro>

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|

  parent reply	other threads:[~1999-02-28 22:53 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
1999-02-28  5:51 Bug? Carlo Wood
     [not found] ` < 199902281348.OAA03093@jolan.ppro >
1999-02-28 10:32   ` Bug? Martin v. Loewis
1999-02-28 22:53     ` Bug? Martin v. Loewis
1999-02-28 22:53 ` Bug? Carlo Wood
1999-02-28 22:53 ` Paul Derbyshire [this message]
2004-07-11 16:37 bug? Katsuya TANAKA
2004-07-12 11:35 ` bug? Dave Korn
2004-12-12  0:58 Bug? Sam Lauber
2004-12-12  1:49 ` Bug? Giovanni Bajo
2004-12-12  3:24 ` Bug? Aaron W. LaFramboise

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3.0.6.32.19990228110237.00980540@pop.globalserve.net \
    --to=pderbysh@usa.net \
    --cc=egcs@egcs.cygnus.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).