public inbox for ltp@lists.linux.it
 help / color / mirror / Atom feed
From: Cyril Hrubis <chrubis@suse.cz>
To: ltp@lists.linux.it
Subject: [LTP] LTP compilation broken with -fno-common
Date: Wed, 1 Apr 2020 14:01:40 +0200	[thread overview]
Message-ID: <20200401120140.GD23773@yuki.lan> (raw)
In-Reply-To: <fd62323e-3d29-884d-1a0c-bf1adc3e28c2@suse.cz>

Hi!
> >>> The problem here is that gcc10 forbids variables in headers, moving it
> >>> anywhere int the header wouldn't help.
> >>
> >> I don't think GCC cares about where exactly the variable came from. It's
> >> only refusing to link multiple definitions of the same symbol. So if we
> >> move the TCID definition into the TST_NO_DEFAULT_MAIN guard block, GCC
> >> linker should stop complaining because the symbol name will become unique.
> > 
> > See:
> > 
> > https://gcc.gnu.org/gcc-10/porting_to.html
> > 
> 
> This patch fixes the "multiple definition of `TCID'" error. But never
> mind because we'll get the "undefined reference to `TCID'" error instead
> from about 50 programs files that use the new library but define their
> own main().
> 
> Reminder that "multiple definition of `TCID'" is a linker error. If
> defining variables in .h files were really forbidden, it'd be a
> preprocessor error instead.

Well variables in headers are not exactly forbidden by -fno-common but
they are not resolved as a single global variable by the linker anymore,
which was the default before gcc10. So effectivelly this disallows
having variables in headers if the header is included from more than one
compilation unit becuase you end up with a linker error.

The end result is overall the same, no more variables in headers in any
non-trivial codebase.

-- 
Cyril Hrubis
chrubis@suse.cz

  reply	other threads:[~2020-04-01 12:01 UTC|newest]

Thread overview: 17+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-01  8:32 [LTP] LTP compilation broken with -fno-common Petr Vorel
2020-04-01  9:16 ` Richard Palethorpe
2020-04-01  9:39 ` Cyril Hrubis
2020-04-01  9:55   ` Martin Doucha
2020-04-01  9:58     ` Cyril Hrubis
2020-04-01 10:04       ` Martin Doucha
2020-04-01 10:15         ` Petr Vorel
2020-04-01 10:50         ` Cyril Hrubis
2020-04-01 11:42           ` Martin Doucha
2020-04-01 12:01             ` Cyril Hrubis [this message]
2020-04-01 10:14   ` Petr Vorel
2020-04-09  7:45   ` Petr Vorel
2020-04-09  9:18     ` Cyril Hrubis
2020-04-09 10:06     ` Li Wang
2020-04-15  7:00       ` Petr Vorel
2020-04-15 10:19       ` [LTP] hugemmap01 warnings with -i [was Re: LTP compilation broken with -fno-common] Petr Vorel
2020-04-16  9:13         ` Li Wang

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=20200401120140.GD23773@yuki.lan \
    --to=chrubis@suse.cz \
    --cc=ltp@lists.linux.it \
    /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