Re: GCC 8.3.0, -flto and violation of C++ One Definition Rule

[Jonathan Wakely <jwakely.gcc@gmail.com>]

On Wed, 29 Dec 2021 at 17:01, Jonathan Wakely wrote:
>
> On Wed, 29 Dec 2021 at 16:16, Tom Kacvinsky <tkacvins@gmail.com> 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 is that
> > >> some of our code violates the C++ One Definition Rule (-Werror=odr). 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
> > ‘struct Bar’ violates the C++ One Definition Rule [-Werror=odr]
>
> 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 ‘api’
> >          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 ‘boost::python::object’ should match type name
> > ‘boost::python::api::object’
> >      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
> ‘boost::python::object’ and another has a member of type
> ‘boost::python::api::object’. 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 <boost/python/object_fwd.hpp> would be the correct way to do that.