Bug 1589382

That missing symbol is not defined by the library, instead it defines:
_ZNSt13basic_filebufIcSt11char_traitsIcEE7seekoffElSt12_Ios_SeekdirSt13_Ios_Openmode

i.e. basic_filebuf<char>::seekoff(long, std::_Ios_Seekdir, std::_Ios_Openmode) with first parameter of long, not long long.

This suggests you've done something odd to your copy of the headers.

Please compile with -save-temps and attach the .ii file here.

Created attachment 1450063 [details]
.ii file for testcase

Attaching .ii file from the affected system.

I will install a fresh rawhide VM and double-check that the problem recurs.

Your preprocessed source shows:

# 90 "/usr/include/c++/8/bits/postypes.h" 3
  typedef long long streamoff;

Which comes from this code:

#ifdef _GLIBCXX_HAVE_INT64_T_LONG
  typedef long          streamoff;
#elif defined(_GLIBCXX_HAVE_INT64_T_LONG_LONG)
  typedef long long     streamoff;
#elif defined(_GLIBCXX_HAVE_INT64_T) 
  typedef int64_t       streamoff;
#else
  typedef long long     streamoff;
#endif


On rawhide x86_64 you should have _GLIBCXX_HAVE_INT64_T_LONG defined:

# g++ -E -dM -include ext/stdio_filebuf.h -x c++ /dev/null | fgrep INT64_T_LONG
#define _GLIBCXX_HAVE_INT64_T_LONG 1


So I still think you've messed something up on your system.

Thank you for looking into this. I found that conditions to reproduce the problem are more complex, and it has something to do with having both libstdc++-devel.x86_64 and libstdc++-devel.i686 installed on the same system. According to rpm -ql both packages claim to own the file /usr/include/c++/8/ext/stdio_filebuf.h. (The actual problem is in some other header which they include.)

The version of the package for .i686 has:

[root@Fedora-rawhide-64 smakarov]# g++ -E -dM -include ext/stdio_filebuf.h -x c++ /dev/null | fgrep INT64_T_LONG
#define _GLIBCXX_HAVE_INT64_T_LONG_LONG 1

The header file is also owned by both packages on my Fedora 28 machine, but there stdio_filebuf.h contains the correct #define, and everything seems to coexist correctly.

Doing `dnf reinstall libstdc++-devel.x86_64` on the affected Rawhide machine fixed the problem for me. So the issue has a simple if not immediately obvious workaround.

My attempt trying to reproduce the problem on a fresh install only yielded a different error:

- Boot https://kojipkgs.fedoraproject.org/compose/rawhide/Fedora-Rawhide-20180608.n.1/compose/Workstation/x86_64/iso/Fedora-Workstation-Live-x86_64-Rawhide-20180608.n.1.iso
- dnf update
- dnf install libstdc++-devel.i686
- dnf group install "C Development Tools and Libraries"
- Create reproducer2.cxx and compile it. Fails as follows:

[liveuser@localhost-live ~]$ g++ reproducer2.cxx -o reproducer2 -save-temps
In file included from /usr/include/c++/8/ios:38,
                 from /usr/include/c++/8/istream:38,
                 from /usr/include/c++/8/fstream:38,
                 from /usr/include/c++/8/ext/stdio_filebuf.h:34,
                 from reproducer2.cxx:1:
/usr/include/c++/8/iosfwd:38:10: fatal error: bits/c++config.h: No such file or directory
 #include <bits/c++config.h>
          ^~~~~~~~~~~~~~~~~~
compilation terminated.

(Will attach preprocessed data as error1.ii)

Such a sequence of install steps is strange (a user is more likely to install the native x86_64 development tools first) but as far as I understand not obviously insane / unsupported.

I suspect (but haven't proven yet) that the problem on my original system could have been the result of a similar weird sequence of package installs, or possibly an unlucky dnf update on a system with both packages. I don't recall doing anything to those header files outside of standard dnf install/update operations.

Created attachment 1450159 [details]
.ii file from second reproduction attempt

You of course can have just libstdc++-devel.i686 and not libstdc++-devel.x86_64 installed on x86_64 box, but then you shouldn't try to compile 64-bit C++ programs, only 32-bit ones.  If you want both, install both.

You've changed the title to "installing both libstdc++-devel.x86_64 and libstdc++-devel.i686 may break ext/stdio_filebuf.h" but as far as I can tell, you haven't installed both.

If you install libstdc++-devel.i686 first, then the dependencies for the gcc-c++ package and the "C Development Tools and Libraries" group will be satisfied, and so the x86_64 version won't be installed. That explains the error you get: you don't have the 64-bit headers.

The fix is to install libstdc++-devel.x86_64

I still have no idea what your first error was caused by, there should be no sequence of installation steps that can cause it.

I am still unable to reproduce this problem on a new rawhide install. There are still peculiarities on the affected system (after doing 'dnf reinstall libstdc++-devel.x86_64', 'rpm -qa' claims 'libstdc++-devel.i686' is no longer installed, even though the reinstall command does not claim to have erased it, the package files are present and both 64-bit and 32-bit compiles use the correct headers) but at this point I've worked around my original problem and it seems whatever sequence of events caused this in the first place is improbable.

Thank you again for looking into this; it would have taken a lot of trial and error on my part to understand what was going on.

Let's close this, then.