: c cpp_installation.md

[tege17]

: c cpp_installation.md

[jackorp]

This does not seem to be a problem of Fedora but rather something you did judging by the provided information.

On a fresh F38 image I am able to install gcc-c++ as described and then compile and run the following program like so:

$ sudo dnf install -y gcc-c++
$ cat hello.c
#include <iostream>

int main() {
  std::cout << "Hello" << std::endl;
  return 0;
}
$ g++ -std=c++14 ./hello.c
$ echo $?
0
$  ./a.out
Hello

I am noticing that the package that provides the gnu/stubs-64.h header is actually available after I install the gcc-c++ as described in the guide. From my POV the instructions are still right at least for a minimal environment.

I am curious how did your install of the compiler miss out on the glibc-devel package.
What version of Fedora Linux are you using? Perhaps it is not reproducible on rawhide but rather the lower Fedora versions.

I agree with you that probably adding the "magical" sudo dnf group install "C Development Tools and Libraries" could be appropriate for the C and C++ sections.

[tege17]

I have a fresh Fedora 37 install. I don't have a lot of Fedora experience (I have used Gentoo and Debian for 20 years) so I am not sure how well its "dnf" command or the package format handles dependencies. I resolved this particular problem by manually doing *dnf install glibc-devel.x86_64* which now allows me to compile both C and C++. Weirdly, 32-bit compiles only work for C, despite the presence of the relevant libs. *fed64$** gcc hello/hello.c -m64* *fed64$** gcc hello/hello.c -m32* *fed64$** g++ hello/hello.C -m64* *fed64$** g++ hello/hello.C -m32* */usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/12/libstdc++.so when searching for -lstdc++* */usr/bin/ld: cannot find -lstdc++: No such file or directory* */usr/bin/ld: skipping incompatible /usr/lib/gcc/x86_64-redhat-linux/12/libstdc++.so when searching for -lstdc++* *collect2: error: ld returned 1 exit status* This is surely unrelated, but indicates that the compiler/library deps are not done right.

…

On Sat, Jan 7, 2023 at 3:13 PM Jarek Prokop ***@***.***> wrote: This does not seem to be a problem of Fedora but rather something you did judging by the provided information. On a fresh F38 image I am able to install gcc-c++ as described and then compile and run the following program like so: $ sudo dnf install -y gcc-c++ $ cat hello.c#include <iostream> int main() { std::cout << "Hello" << std::endl; return 0;} $ g++ -std=c++14 ./hello.c $ echo $?0 $ ./a.outHello I am noticing that the package that provides the gnu/stubs-64.h header is actually available after I install the gcc-c++ as described in the guide. From my POV the instructions are still right at least for a minimal environment. I am curious how did your install of the compiler miss out on the glibc-devel package. What version of Fedora Linux are you using? Perhaps it is not reproducible on rawhide but rather the lower Fedora versions. I agree with you that probably adding the "magical" sudo dnf group install "C Development Tools and Libraries" could be appropriate for the C and C++ sections. — Reply to this email directly, view it on GitHub <#468 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWZ7WGUVHSSTIHHZLTPAVTTWRF2W3ANCNFSM6AAAAAATT6XBIE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jackorp]

This is surely unrelated, but indicates that the compiler/library deps are
not done right.

That is matter of opinion IMHO. The x86_64 and i686 (64bit and 32bit respectively) are 2 "different" sets of architectures in Fedora and I'd say 32bit is rarely needed these days for most use cases, so the default install is x86_64. For 32bit packages you can always append .i686 to receive the correct deps. In our example here you can run: $ sudo dnf install gcc-c++.i686 and you'll receive the 32bit capable compiler. In any case, glibc-devel should've been installed, and is pulled in as a dependency of gcc-c++ in a fresh F37 container.

[tege17]

I am sorry but adding various .i686 packages does not resolve that other problem. My new install does not have a working build environment. It is very clear that I am in good company, there are lots and lots of google matches for the same problems I see. I am at a loss understanding why it works for you and not for me. My installs finished without error messages. My disk partitions are far from full. I have plenty of RAM. I am a former GCC developer (at Cygnus) and far from a newbee when it comes to OS installs, compilers, libraries and their interworkings. My goal here was adding Fedora to the GMP automated testing setup. It would have been nice to get that going, but it is not a big deal that it failed. It defeats the purpose of doing a lot of manual steps as I want to mimic what end users will see. Case closed with multiple fundamental failures.

…

On Sat, Jan 7, 2023 at 3:49 PM Jarek Prokop ***@***.***> wrote: This is surely unrelated, but indicates that the compiler/library deps are not done right. That is matter of opinion IMHO. The x86_64 and i686 (64bit and 32bit respectively) are 2 "different" sets of architectures in Fedora and I'd say 32bit is rarely needed these days for most use cases, so the default install is x86_64. For 32bit packages you can always append .i686 to receive the correct deps. In our example here you can run: $ sudo dnf install gcc-c++.i686 and you'll receive the 32bit capable compiler. In any case, glibc-devel should've been installed, and is pulled in as a dependency of gcc-c++ in a fresh F37 container. — Reply to this email directly, view it on GitHub <#468 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AWZ7WGRYV6SKOJ3TVIYA4ATWRF67NANCNFSM6AAAAAATT6XBIE> . You are receiving this because you authored the thread.Message ID: ***@***.***>

[jackorp]

Thanks for collaborating. We cannot solve it from the side of Fedora Developer Portal.

Consider asking the community here: https://ask.fedoraproject.org/ , people there might know much better what is going on or maybe see about better way of providing the dependencies for automated testing.