From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-ed1-x536.google.com (mail-ed1-x536.google.com [IPv6:2a00:1450:4864:20::536]) by sourceware.org (Postfix) with ESMTPS id 15F373858C3A for ; Wed, 29 Dec 2021 18:18:28 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org 15F373858C3A Received: by mail-ed1-x536.google.com with SMTP id z29so89212044edl.7 for ; Wed, 29 Dec 2021 10:18:28 -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=RU4H7zjG+yQbbhXlVRc7Ghm/ck+ezJZPnvPKuMR/OB8=; b=Pkv8jl5g11JnRDWZv8/6fe+/g0kCNsYA6Fa1Szrrp9gte5lTnrGPi5+MUqTKeYOmpR kpevGP9+2COaCsBOCanutdUkPVNlzac+xY5f3H/9SVkbbfEKJCOZDult59/ZCXfSVgKg eQfsVVPqi0k0cjOWKVZkSISz4p942nIMmlrZbHm+LD9a5YkGvP5676IrhnBvjHPLSOQf YDGCURKX5nsQ+5lxYZyd6Qam1bcYL5a3jvtjZfjz/nuW+pTEUrHCQdlgvu23y53lE6xI T3ACpV2vYeM+SNywdFhls28+4h3KfNsDI/pmUAvcGywA9uUcpvysgndBeaWjucZXxpWY OWAA== X-Gm-Message-State: AOAM533+9slVr5ujNqeYquZ2rmzgYGnNgwPYento71fAwRQ5Sj7ETUAp B6IKdEW4FxPqX8xW0T8THz6CVLLe+3+DA6tA2uQ= X-Google-Smtp-Source: ABdhPJxWnqV71sreSQFMVB+CLtlW/x8wF3DxFVKIEQGREsAijL/gb3yvG2E+IDoueARftDF5I4fPEHhapFTnEwM9FLU= X-Received: by 2002:a17:906:a2c7:: with SMTP id by7mr21389465ejb.439.1640801906826; Wed, 29 Dec 2021 10:18:26 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Tom Kacvinsky Date: Wed, 29 Dec 2021 13:18:15 -0500 Message-ID: Subject: Re: GCC 8.3.0, -flto and violation of C++ One Definition Rule To: Jonathan Wakely Cc: gcc-help Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Status: No, score=-0.9 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 18:18:29 -0000 On Wed, Dec 29, 2021 at 12:04 PM Jonathan Wakely wr= ote: > > 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 tr= y. 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 = that > > > >> some of our code violates the C++ One Definition Rule (-Werror=3Do= dr). 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 li= kely that the LTO violation is always present, but only detected when using= LTO. > > > > > > > > > > > >> 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 o= ne > > > >> needs to use gcc-nm to examine them (which I know is a wrapper aro= und nm, > > > >> and passes an option to load the LTO plugin). how can I leverage t= hat to > > > >> see if there are other translation units that define the class tha= t ODR > > > >> violation is complaining about? I did do a fairly thorough analys= is of > > > >> the object files and did not see there the particular class and me= thods > > > >> would be multiply defined, > > > > > > > > > > > > It would help if you tell us the actual error/warning you get. -Wod= r can warn about various different things. It does not warn about multiple = definitions, 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 [-W= error=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 uni= t > > > 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_cor= e.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 typ= e > > =E2=80=98boost::python::api::object=E2=80=99. I have two guesses how th= at 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 th= at. OK, I'll try that. What we had done is some hackery with boost/python.hpp = being include in the C++ file and not the header (with the header in essence "for= ward declaring" the boost namespace. We did this because of a conflict between = Qt having an "#undef slots" but Python's object.h using slots in a struct definition. I worked around that, but I can try your suggestion - it just might work ar= ound the issue with having to play the #undef game before including the header t= hat pulls in boost/python.hpp Thanks for the help with this, it is much appreciated! Tom