From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wr1-x434.google.com (mail-wr1-x434.google.com [IPv6:2a00:1450:4864:20::434]) by sourceware.org (Postfix) with ESMTPS id B7B233858D39 for ; Wed, 29 Dec 2021 19:36:47 +0000 (GMT) DMARC-Filter: OpenDMARC Filter v1.4.1 sourceware.org B7B233858D39 Received: by mail-wr1-x434.google.com with SMTP id j18so46320606wrd.2 for ; Wed, 29 Dec 2021 11:36:47 -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; bh=ywG12g3ndzAjlzzx/qeQ+6ybZwaid1k9YQkkolxbYRc=; b=3z2TxUJhsnnUQ1lZP5AwH6JUNlr9P/XcOOhEhtehGG3TUQMA7shk1yQanuQq1VjVzj 2GDxbd07f4a56JE0S3t8pbq37Ts9Tyb5o2tS0OiL8/VmHy5bJ3esL2YvM/okSJmncdNM bqXcqLEOpjSaF/NsofWWMXKp+GRYElOdxVIHelKSo1dS480rUQC9HbCo/upW2kgDXzZv AEPdbJSehI445C+13FPFiQ5qG+np6f8V8hIDrSif+zwD/N5vTQeqWOJrThI1UJKPfPnV kvBditILgGIxp3O83oWLYJm5GbasIvFXM1Lx0TpcS5RbdgYNFWF0RQc/gfR2SlJHU+x5 qQzQ== X-Gm-Message-State: AOAM532TTzDUKe6HXKmrRMvZ49/7SJrn3pvIdHxlWUfUyQ5jDj3OYo+O hpJmbMKoePKmmvMZyJ1ngIbv7GzQg3Xlq83Z7Is= X-Google-Smtp-Source: ABdhPJxaRdyVaLJUPa1aDmGcLNloQ3duG+qWxp/kqVLoRZQjI2h7n78NPJjmv3QqNuASyHcYNH6i+iwG3Sq0Gof9rSQ= X-Received: by 2002:a5d:64a2:: with SMTP id m2mr22039788wrp.102.1640806606726; Wed, 29 Dec 2021 11:36:46 -0800 (PST) MIME-Version: 1.0 References: In-Reply-To: From: Jonathan Wakely Date: Wed, 29 Dec 2021 19:36:33 +0000 Message-ID: Subject: Re: GCC 8.3.0, -flto and violation of C++ One Definition Rule To: Tom Kacvinsky Cc: gcc-help 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, HTML_MESSAGE, 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 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.29 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 19:36:49 -0000 On Wed, 29 Dec 2021, 18:18 Tom Kacvinsky, wrote: > On Wed, Dec 29, 2021 at 12:04 PM Jonathan Wakely > wrote: > > > > 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 < > jwakely.gcc@gmail.com> wrote: > > > > > > > > > > > > > > > > > > > > On Wed, 29 Dec 2021, 11:45 Tom Kacvinsky via Gcc-help, < > gcc-help@gcc.gnu.org> 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 i= s > that > > > > >> 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 > likely 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 > one > > > > >> needs to use gcc-nm to examine them (which I know is a wrapper > around nm, > > > > >> and passes an option to load the LTO plugin). how can I leverage > that 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 > methods > > > > >> 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 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 [= -Werror=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 fie= ld > > > > 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.hp= p: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 t= ype > > > =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. > > OK, I'll try that. What we had done is some hackery with boost/python.hp= p > being > include in the C++ file and not the header (with the header in essence > "forward > declaring" the boost namespace. So exactly what I guessed from the error messages :-) There is no need to debug the LTO objects, just read the errors. If you really *must* play games like this, you need to do it correctly. Declare the type in the correct namespace (as the object_fwd.hpp header does).