From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x435.google.com (mail-wr1-x435.google.com [IPv6:2a00:1450:4864:20::435]) by sourceware.org (Postfix) with ESMTPS id 693193858D35 for ; Wed, 29 Dec 2021 17:04:34 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 693193858D35 Received: by mail-wr1-x435.google.com with SMTP id v7so45517328wrv.12 for ; Wed, 29 Dec 2021 09:04:34 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=QGGhVQqOo2jQLthKE1EZlsmRft2zE0O5HaMClniC8IE=; b=azNuzEiFiTUUhZfn6NVoldh7hrPDuwoi143ClFiUKIKtJ9OQLyIs5rZDuM/A0uXO6O C06pZlfcbybp31FxPCBcwZIKzpH+3C4LHo9LyDCfDtYbSY+L0SXrmn2LYhTt+xjOZrLf +GW2yXvQ4N1suif3PazcJbvTotmuqWLhsrGZH14Zyi28BlHteIZRd/IWeprpoaLa6qrv /dmlsRb4V/1y5Lkmd/2cLzVyFIbpT61vMAA6oaKJExMSgN1rD6SygPBzWjcRn5/BshZm APGBvGAOnxLUVsQ1NdAGMwuuGAo0qErTka2iMu63vNYyFNbkICzp+p2LpmKu+yd9llK2 GQDA== X-Gm-Message-State: AOAM533+Tkw5OHpoVYq0Y7V6/wJ3rrmf1nqEIzih3XWxAJemRbtZ07gE M3QH6ngJ+dNtm04d9+TfsWeji/ygoOVTkCDr/Sg= X-Google-Smtp-Source: ABdhPJyplAGjL3SfQJLJL8XcLL7yHQm2AcMZWYywhhfMj5gsYVlGH60oSfMM3JK2T7CuYSF5qYiCdmeuNRdfu7CPOUA= X-Received: by 2002:a5d:64a2:: with SMTP id m2mr21556874wrp.102.1640797473319; Wed, 29 Dec 2021 09:04:33 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 29 Dec 2021 17:04:22 +0000 Message-ID: Subject: Re: GCC 8.3.0, -flto and violation of C++ One Definition Rule To: Tom Kacvinsky Cc: gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-1.2 required=5.0 tests=BAYES_00, DKIM_SIGNED, DKIM_VALID, DKIM_VALID_AU, DKIM_VALID_EF, FREEMAIL_FROM, RCVD_IN_DNSWL_NONE, SPF_HELO_NONE, SPF_PASS, TXREP autolearn=ham autolearn_force=no version=3.4.4 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on server2.sourceware.org X-BeenThere: gcc-help@gcc.gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Gcc-help mailing list List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 29 Dec 2021 17:04:35 -0000 On Wed, 29 Dec 2021 at 17:01, Jonathan Wakely wrote: > > On Wed, 29 Dec 2021 at 16:16, Tom Kacvinsky wrote: > > > > On Wed, Dec 29, 2021 at 10:39 AM Jonathan Wakely wrote: > > > > > > > > > > > > On Wed, 29 Dec 2021, 11:45 Tom Kacvinsky via Gcc-help, wrote: > > >> > > >> Hi, > > >> > > >> First, using GCC 8.3.0 and binutils 2.37.I am trying to increase > > >> performance of linking our product, so I thought I'd give LTO a try.= So > > >> I am compiling all object files with -flto, and passing -flto to g++ > > >> (which we use as our link driver). However, what I have found is th= at > > >> some of our code violates the C++ One Definition Rule (-Werror=3Dodr= ). This > > >> only happens when building with LTO - without LTO, the C++ rule is > > >> not violated. > > > > > > > > > As already explained, this is almost certainly wrong. It is more like= ly that the LTO violation is always present, but only detected when using L= TO. > > > > > > > > >> The problem exists with LTO using both the BFD and gold > > >> linkers. > > >> > > >> So, my question is, since the LTO object files are now such that one > > >> needs to use gcc-nm to examine them (which I know is a wrapper aroun= d nm, > > >> and passes an option to load the LTO plugin). how can I leverage tha= t to > > >> see if there are other translation units that define the class that = ODR > > >> violation is complaining about? I did do a fairly thorough analysis= of > > >> the object files and did not see there the particular class and meth= ods > > >> would be multiply defined, > > > > > > > > > It would help if you tell us the actual error/warning you get. -Wodr = can warn about various different things. It does not warn about multiple de= finitions, it warns about *inconsistent* definitions. > > > > > > > This is long. Not sure of the attachment fule for this, so I am > > pasting it in email. Ib obfuscated the actual source file > > names, but this is the general gist of the link error. I wonder if > > the error is coming from boost::python::api::object. > > > > /home/home/tkacvins/project/libbar/include/Bar.h:38:7: error: type > > =E2=80=98struct Bar=E2=80=99 violates the C++ One Definition Rule [-Wer= ror=3Dodr] > > You said it was defined in one C++ file, but it's clearly defined in a > header. So the problem is that the definition is different in > different translation units. > > > > > class Bar { > > ^ > > /home/home/tkacvins/project/libbar/include/Bar.h:38:7: note: a > > different type is defined in another translation unit > > class Bar { > > ^ > > /home/home/tkacvins/project/libbar/include/Bar.h:40:32: note: the > > first difference of corresponding definitions is field =E2=80=98api=E2= =80=99 > > boost::python::object* api; > > ^ > > /home/home/tkacvins/project/libbar/include/Bar.h:40:32: note: a field > > of same name but different type is defined in another translation unit > > boost::python::object* api; > > ^ > > /home/home/tkacvins/project/libbar/include/Bar.h:15:11: note: type > > name =E2=80=98boost::python::object=E2=80=99 should match type name > > =E2=80=98boost::python::api::object=E2=80=99 > > class object; > > ^ > > /home/BUILD64/lib/boost-1.69.0-py39-1/include/boost/python/object_core.= hpp:238:9: > > note: the incompatible type is defined here > > class object : public object_base > > ^ > > As it says, one definition has a member of type > =E2=80=98boost::python::object=E2=80=99 and another has a member of type > =E2=80=98boost::python::api::object=E2=80=99. I have two guesses how that= could > happen: either you're compiling with two different versions of boost > (which seems unlikely because I think boost::python::api::object has > been in that namespace for 20 years), or you are using a forward > declaration of boost::python::object in your own files, instead of > including the correct boost header to define it properly. > > The most likely explanation is that somebody tried to "optimize" the > build by cheating, and not including the right boost header for the > type. Including would be the correct way to do that= .