public inbox for gcc-prs@sourceware.org help / color / mirror / Atom feed
From: Matthias Klose <doko@klose.in-berlin.de> To: gcc-gnats@gcc.gnu.org, debian-gcc@lists.debian.org Cc: chris@debian.org Subject: c/7853: gcc reports multiple symbol definitions on the wrong line Date: Sun, 08 Sep 2002 00:06:00 -0000 [thread overview] Message-ID: <E17nvuB-0005Cn-00@gate.local> (raw) >Number: 7853 >Category: c >Synopsis: gcc reports multiple symbol definitions on the wrong line >Confidential: no >Severity: non-critical >Priority: medium >Responsible: unassigned >State: open >Class: sw-bug >Submitter-Id: net >Arrival-Date: Sun Sep 08 00:06:00 PDT 2002 >Closed-Date: >Last-Modified: >Originator: Andrew Suffield <aps100@doc.ic.ac.uk> >Release: 3.2.1 CVS (Debian) (Debian unstable) >Organization: The Debian Project >Environment: System: Debian GNU/Linux (unstable) Architecture: i686 >Description: [ Reported to the Debian BTS as report #159838. Please CC 159838@bugs.debian.org on replies. Log of report can be found at http://bugs.debian.org/159838 ] Andrew Suffield writes: (I am not sure whether this is a bug in gcc or binutils) aps100@cyclone:~/tmp$ cat foo.c int x = 0; aps100@cyclone:~/tmp$ cat bar.c int x = 0; void foo(void) {} aps100@cyclone:~/tmp$ gcc -shared -g -o foo.so foo.c bar.c /tmp/cc0wTF8S.o: In function `foo': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /home/aps100/tmp/bar.c:3: multiple definition of `x' ^ /tmp/ccpK9pwb.o(.data+0x0):/home/aps100/tmp/foo.c: first defined here collect2: ld returned 1 exit status aps100@cyclone:~/tmp$ gcc-3.2 -shared -g -o foo.so foo.c bar.c /tmp/ccBwlA8f.o: In function `foo': ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ /home/aps100/tmp/bar.c:3: multiple definition of `x' ^ /tmp/cckwx9Kb.o(.data+0x0): first defined here collect2: ld returned 1 exit status Note the indicated parts. Function 'foo' has got nothing to do with the problem, and that's the wrong place to be highlighting the error. More generally, it appears that symbol conflicts in the global scope will always be reported as being in the first function in the compilation unit (not thoroughly tested, but that's what I noticed). This means the error message might not even be pointing at the correct file, let alone the right line. (Needless to say, this is quite irritating). >How-To-Repeat: >Fix: >Release-Note: >Audit-Trail: >Unformatted:
next reply other threads:[~2002-09-08 7:06 UTC|newest] Thread overview: 3+ messages / expand[flat|nested] mbox.gz Atom feed top 2002-09-08 0:06 Matthias Klose [this message] 2002-10-09 15:31 ljrittle 2002-10-09 18:25 ljrittle
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=E17nvuB-0005Cn-00@gate.local \ --to=doko@klose.in-berlin.de \ --cc=159838@bugs.debian.org \ --cc=chris@debian.org \ --cc=debian-gcc@lists.debian.org \ --cc=gcc-gnats@gcc.gnu.org \ /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: linkBe 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).