|
Bugzilla – Full Text Bug Listing |
| Summary: | Packages pulling gcc14 (like emacs-x11 and emacs-nox) break clang | ||
|---|---|---|---|
| Product: | [openSUSE] openSUSE Tumbleweed | Reporter: | David Keaton <dmk> |
| Component: | Other | Assignee: | Richard Biener <rguenther> |
| Status: | NEW --- | QA Contact: | E-mail List <qa-bugs> |
| Severity: | Normal | ||
| Priority: | P3 - Medium | CC: | aaronpuchert, chcao, dmk, martin.liska, matz, rguenther |
| Version: | Current | ||
| Target Milestone: | --- | ||
| Hardware: | x86-64 | ||
| OS: | openSUSE Tumbleweed | ||
| Whiteboard: | |||
| Found By: | --- | Services Priority: | |
| Business Priority: | Blocker: | --- | |
| Marketing QA Status: | --- | IT Deployment: | --- |
And why is this a bug of GNU Emacs? I can fix here exactly nothing as maintainer of GNU Emacs. The new gcc is pulled by the build system. In the end this is a bug of clang, not verifying there's a standard library installed in the place it is detecting a GCC install. clang requires libstdc++-devel which pulls the default (GCC 13) variant but it still seems to prefer a variant provided by a different compiler that has just the C language parts installed. I think for reproducability one might want to force clang to use the version libstdc++-devel is at. For example on Leap the default would be from gcc7 but you can install gcc13 there just fine and this should eventually reproduce the issue there as well. The resolution would force Leap clang to always use the standard library from gcc7 which might not exactly be intended(?), a more specific requires to a newer version might be better there. I've meanwhile fixed the dependence issue that pulls in GCC 14, that avoids the issue when you do not manually install gcc14 (but not gcc14-c++). Of course if you do clang will misbehave as well AFAICS. (In reply to David Keaton from comment #0) > There is an unacceptable workaround. It is possible to work around the > problem by installing libstdc++6-devel-gcc14 . The reason this is > unacceptable is that then, a stable, released clang depends on an unstable, > unreleased gcc installation. It would not be possible to trust the binaries > compiled and linked by this configuration. If your Tumbleweed installation is reasonably up-to-date, you should already have libstdc++6 = 14.0.1+gitXXXX. So you're already using the new runtime library. At this point bringing in the new header files doesn't seem like such a big step to me. > 3. Modify the clang package not to find unstable, unreleased versions of > gcc. Clang doesn't know which GCC releases are unstable or unreleased. It's going to trust whatever version it finds, and I think that's Ok. There is another workaround: use --gcc-install-dir= or --gcc-toolchain= to force whatever version you want. [1] It seems that the former is preferred, but I don't know the details. [2] (In reply to Richard Biener from comment #2) > In the end this is a bug of clang, not verifying there's a standard library > installed in the place it is detecting a GCC install. This should be possible to fix, I believe the relevant function is Generic_GCC::GCCInstallationDetector::init in clang/lib/Driver/ToolChains/Gnu.cpp [3]. It looks for GCC installations, and then chooses the highest version. ("GCC installs are ranked by version number.") But it's relatively complex, and I'm not sure I'll be able to find time for this. The question is how far to go in detecting the "completeness" of a GCC installation. Any idea which files specifically to look for? > clang requires libstdc++-devel which pulls the default (GCC 13) variant > but it still seems to prefer a variant provided by a different compiler > that has just the C language parts installed. I think for reproducability > one might want to force clang to use the version libstdc++-devel is at. Not anymore: clang only recommends libstdc++-devel, because you can also use it with libc++-devel, or another version of libstdc++. Clang should work reasonably well with most (relatively recent) C++ standard library versions. Of course if you're going to build something for the distribution, it might make sense to use the distribution default libstdc++-devel. But you might need a more recent version, for example when building packages on Leap. What happens if I get a transitive dependency on libstdc++6-devel-gccX with X greater than the default version? Of course Clang will choose the newer library then. Well, if a package requires that (and not just BuildRequires it), it's probably because newer C++ features are being used in a public interface, and then my package must also build against the newer version of libstdc++. So in that case, using the newest available version doesn't seem like a bad idea. > For example on Leap the default would be from gcc7 but you can install > gcc13 there just fine and this should eventually reproduce the issue there > as well. The resolution would force Leap clang to always use the standard > library from gcc7 which might not exactly be intended(?), a more specific > requires to a newer version might be better there. It should be possible to use Clang both with Leap's default gcc7 or a newer version, depending on the C++ standard version that you intend to target. So it would probably not be very user-friendly to hardcode a libstdc++ version there: either we make it hard to use it with the default libstdc++, or we make it hard to use with a newer libstdc++ version. Both are valid use cases: if you have something C++11, libstdc++6-devel-gcc7 should be fine and allows you to run the compiled code on older versions of Leap (or more interestingly, older SPs of SLE 15 that are still supported), while if you have something C++20 or newer, you'll probably want libstdc++6-devel-gcc13. Given all that, choosing the newest version doesn't seem like a bad choice to me. It's just that the detection currently doesn't check for completeness of the GCC installation. [1] <https://clang.llvm.org/docs/ClangCommandLineReference.html#cmdoption-clang-gcc-install-dir> [2] <https://discourse.llvm.org/t/add-gcc-install-dir-deprecate-gcc-toolchain-and-remove-gcc-install-prefix/65091> [3] <https://github.com/llvm/llvm-project/blob/llvmorg-17.0.6/clang/lib/Driver/ToolChains/Gnu.cpp#L2064-L2196> @Richard Biener > I've meanwhile fixed the dependence issue that pulls in GCC 14, that > avoids the issue when you do not manually install gcc14 (but not gcc14-c++). > Of course if you do clang will misbehave as well AFAICS. Thanks. A zypper dup currently does not pull in this fix, but I will continue to watch for it so I can try it. @Aaron Puchert > If your Tumbleweed installation is reasonably up-to-date, you should already > have libstdc++6 = 14.0.1+gitXXXX. So you're already using the new runtime > library. At this point bringing in the new header files doesn't seem like such > a big step to me. Thanks for pointing that out. I am new to Tumbleweed and I am surprised to learn that it depends on an unstable version of the library. Even if the system does that, though, I would rather not depend on it for my own work. > There is another workaround: use --gcc-install-dir= or --gcc-toolchain= to > force whatever version you want. In general that sounds like a good idea. However, in my case I am working with a complex source tree with parts pulled in from different projects. It is controlled by a combination of make and cmake at different levels depending on the subproject. Consequently, a command-line option would be difficult to get right everywhere in the tree. Thanks to everyone for considering this issue. I appreciate all the helpful information. (In reply to Aaron Puchert from comment #3) > (In reply to Richard Biener from comment #2) > > In the end this is a bug of clang, not verifying there's a standard library > > installed in the place it is detecting a GCC install. > > This should be possible to fix, I believe the relevant function is > Generic_GCC::GCCInstallationDetector::init in > clang/lib/Driver/ToolChains/Gnu.cpp [3]. It looks for GCC installations, and > then chooses the highest version. ("GCC installs are ranked by version > number.") But it's relatively complex, and I'm not sure I'll be able to find > time for this. > > The question is how far to go in detecting the "completeness" of a GCC > installation. Any idea which files specifically to look for? This bug is because it fails to link to libstdc++ which means it didn't find the libstdc++.so symlink. The simplest testcase was likely not using any part of the standard library because it should have failed earlier when looking up standard library includes (unless it falls back transparently to libc++ headers somehow?). For SUSE clang should look for 'libstdc++.so' in for example /usr/lib64/gcc/x86_64-suse-linux/13/ (I assume that's it's "prefix"). Note that some distros might install libstd++.so in /usr/lib64/ along the libstdc++.so.6 link. I think clang++ will in the end add /usr/include/c++/13/ to it's include path and that doesn't exist when libstdc++-devel of the respective version isn't installed. Checking for a file is likely better than just for a directory so checking for /usr/include/c++/13/vector for example would be best. The GCC finding code you point to doesn't seem to look for the standard library include directory though, so I guess it might be invoked also for 'clang', not just 'clang++'. I suppose filing an issue upstream might be a good thing to do. (In reply to David Keaton from comment #4) > In general that sounds like a good idea. However, in my case I am working > with a complex source tree with parts pulled in from different projects. It > is controlled by a combination of make and cmake at different levels > depending on the subproject. Consequently, a command-line option would be > difficult to get right everywhere in the tree. Check out https://clang.llvm.org/docs/UsersManual.html#configuration-files. (In reply to Richard Biener from comment #5) > unless it falls back transparently to libc++ headers somehow? I might be wrong, but I think the default C++ standard library depends on the triple and there is no fallback. I've seen Clang silently drop non-existing default include directories, so I assume that happens here and the minimal example doesn't #include any C++ standard library headers. @David, maybe you can run the compilation with -v? Here it prints #include <...> search starts here: /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13 /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/x86_64-suse-linux /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/13/backward /usr/lib64/clang/18/include /usr/local/include /usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../x86_64-suse-linux/include /usr/include Would be interesting what you're seeing. > For SUSE clang should look for 'libstdc++.so' in for example > /usr/lib64/gcc/x86_64-suse-linux/13/ (I assume that's it's "prefix"). Note > that some distros might install libstd++.so in /usr/lib64/ along the > libstdc++.so.6 link. Checking for libstdc++.so sounds like a good idea. I guess we already know where to look because at some point we'll need to pass library directories to the linker. > I think clang++ will in the end add /usr/include/c++/13/ to it's include > path and that doesn't exist when libstdc++-devel of the respective version > isn't installed. Checking for a file is likely better than just for a > directory so checking for /usr/include/c++/13/vector for example would be > best. This might also be an idea. > The GCC finding code you point to doesn't seem to look for the standard > library > include directory though, so I guess it might be invoked also for 'clang', > not just 'clang++'. That might be. I think Clang needs the GCC toolchain for C as well, specifically for /usr/lib64/gcc/x86_64-suse-linux/*/crt{begin,end}*.o. @Aaron Puchert > Check out https://clang.llvm.org/docs/UsersManual.html#configuration-files. Thanks. I have looked into those. They seem to have different properties in different distros. Compounding the problem is that some of the subprojects in my tree use their own configuration files, and I would override those or they would override mine. It looks like command-line options, whether in a configuration file or not, probably won't help with my situation. > @David, maybe you can run the compilation with -v? It does find gcc13, but discards it because gcc14 is present. Here is a complete log. > $ grep '^CPE_NAME' /etc/os-release > CPE_NAME="cpe:2.3:o:opensuse:tumbleweed:20240307:*:*:*:*:*:*:*" > $ clang++ -v hello.cpp > clang version 17.0.6 > Target: x86_64-suse-linux > Thread model: posix > InstalledDir: /usr/bin > Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/13 > Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/14 > Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/14 > Candidate multilib: .;@m64 > Selected multilib: .;@m64 > "/usr/bin/clang-17" -cc1 -triple x86_64-suse-linux -emit-obj -mrelax-all -dumpdir a- -disable-free -clear-ast-before-backend -disable-llvm-verifier -discard-value-names -main-file-name hello.cpp -mrelocation-model pic -pic-level 2 -pic-is-pie -mframe-pointer=all -fmath-errno -ffp-contract=on -fno-rounding-math -mconstructor-aliases -funwind-tables=2 -target-cpu x86-64 -tune-cpu generic -debugger-tuning=gdb -v -fcoverage-compilation-dir=/home/dmk -resource-dir /usr/lib64/clang/17 -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../include/c++ -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../include/c++/x86_64-suse-linux -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../include/c++/backward -internal-isystem /usr/lib64/clang/17/include -internal-isystem /usr/local/include -internal-isystem /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/include -internal-externc-isystem /include -internal-externc-isystem /usr/include -fdeprecated-macro -fdebug-compilation-dir=/home/dmk -ferror-limit 19 -fgnuc-version=4.2.1 -fcxx-exceptions -fexceptions -fcolor-diagnostics -faddrsig -D__GCC_HAVE_DWARF2_CFI_ASM=1 -o /tmp/hello-00bf71.o -x c++ hello.cpp > clang -cc1 version 17.0.6 based upon LLVM 17.0.6 default target x86_64-suse-linux > ignoring nonexistent directory "/usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../include/c++/x86_64-suse-linux" > ignoring nonexistent directory "/usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../include/c++/backward" > ignoring nonexistent directory "/include" > #include "..." search starts here: > #include <...> search starts here: > /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../include/c++ > /usr/lib64/clang/17/include > /usr/local/include > /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/include > /usr/include > End of search list. > "/usr/bin/ld" -pie -z relro --hash-style=both --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../lib64/Scrt1.o /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crti.o /usr/bin/../lib64/gcc/x86_64-suse-linux/14/crtbeginS.o -L/usr/bin/../lib64/gcc/x86_64-suse-linux/14 -L/usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../x86_64-suse-linux/lib -L/lib -L/usr/lib /tmp/hello-00bf71.o -lstdc++ -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc /usr/bin/../lib64/gcc/x86_64-suse-linux/14/crtendS.o /usr/bin/../lib64/gcc/x86_64-suse-linux/14/../../../../lib64/crtn.o > /usr/bin/ld: cannot find -lstdc++: No such file or directory > clang++: error: linker command failed with exit code 1 (use -v to see invocation) > $ sudo zypper remove gcc14 > Reading installed packages... > Resolving package dependencies... > > The following 11 packages are going to be REMOVED: > emacs emacs-auctex emacs-compat emacs-el emacs-eln emacs-jinx emacs-vterm > emacs-x11 gcc14 libgccjit0 vagrant-emacs > > 11 packages to remove. > After the operation, 389.0 MiB will be freed. > Continue? [y/n/v/...? shows all options] (y): n > $ (In reply to Richard Biener from comment #5) > I suppose filing an issue upstream might be a good thing to do. That was my initial thought. The clang upstream might see this as a gcc packaging problem, though, over which they have no control. They have no way of knowing how a distro divides up a gcc installation among packages, so they won't know what files to test for, unless they test for all of them. That could be time consuming on each invocation of clang++. I think it would be nice if a clang install could be nailed down to use a particular GCC install. The simplest solution might be a symlink to the GCC install directory placed somewhere in the clang install. As a clang user I would find it disturbing that the standard library in use depends on what random GCC compiler is or is not installed. The same program might build on one machine and not another with the same clang version due to this. Btw, I've confirmed that having gcc12-c++ but only gcc13 installed on Leap 15.5 breaks a clang15 install: > clang++-15 -S t.C t.C:1:11: fatal error: 'string' file not found #include <string> ^~~~~~~~ 1 error generated. > clang++-15 -S t.C -v clang version 15.0.7 Target: x86_64-suse-linux Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/11 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/12 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/13 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/7 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/13 ... ignoring nonexistent directory "/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/x86_64-suse-linux" ignoring nonexistent directory "/usr/bin/../lib64/gcc/x86_64-suse-linux/13/../../../../include/c++/backward" ... It's true that how packages are split isn't known to clang but it doesn't give the ability to configure itself to a static GCC version the package could require either. IMO that would be the most sensible way to do this, have a LLVM_GCC_VERSION=13 cmake configury so the clang++ package could Require libstdc++-devel-gcc13 and then also always use that particular standard library includes version. (In reply to Richard Biener from comment #9) > I think it would be nice if a clang install could be nailed down to use a > particular GCC install. That idea makes a lot of sense. It would improve reproducibility immensely, something that is currently a problem across different distros. GCC 13 has been fixed, a gcc14 submission depends on a lapack fix which is blocked on review in science. From my side this is fixed (the libgccjit update should no longer pull gcc14). I've re-assigned to Aaron, not sure if you want to do anything - I think this is a problem in upstream (and IMO a bigger general usability one that will require some extensive discussion). Feel free to close. (In reply to Richard Biener from comment #11) > GCC 13 has been fixed, a gcc14 submission depends on a lapack fix which is > blocked on review in science. From my side this is fixed (the libgccjit > update should no longer pull gcc14). Thank you! Aaron, since the short-term problem is fixed, I am OK with seeing this issue closed, unless you want to keep it open to do more for the long-term case. Bah, back to me. Not pulling gcc14 breaks emacs. That's because the gcc14 libgccjit upon linking invokes an internal copy of the compilers driver which expects libgcc and startfiles in the gcc14 install path or in /usr/lib64 but when gcc14 isn't installed it doesn't find them since we put no copies in /usr/lib64. That's likely why the requirement to the gcc package was there (but as we see this will break a clang++ install). The gcc requirement is of course overly big, but at least in theory startfiles and libgcc up-to-date with the jit code might be actually required. For gcc14 I'm going to try splitting things up but this will still end up populating /usr/lib64/gcc/x86_64-suse-linux/14 and thus derail the clang check for a GCC install. So, I'm going to revert the GCC change. Tried to find my way through Generic_GCC::GCCInstallationDetector::init but this is total undocumented spaghetti :/ Eventually ScanGCCForMultilibs could be used to invalidate a candidate but it feels wrong but for a SUSE specific hack. There's Generic_GCC::addGCCLibStdCxxIncludePaths that seems to compose the C++ standard library path and it can fail but it's nowhere used where it could fail. I'd still say we want, after the --gcc-triple and --gcc-install-dir handling in Generic_GCC::GCCInstallationDetector::init handle a pre-configured (at clang build time) directory we stick to. Like on Leap we'd not want recent clang++ to run against libstdc++ headers from GCC 7 but require something newer, matching for example the %product_libs_gcc_ver version (the installed shared library). With that proper Requires can be set up and unless people use --gcc-triple or --gcc-install-dir it should give a nice experience. This is an autogenerated message for OBS integration: This bug (1220724) was mentioned in https://build.opensuse.org/request/show/1157436 Factory / gcc14 https://build.opensuse.org/request/show/1157437 Factory / gcc13 (In reply to David Keaton from comment #7) > @Aaron Puchert > > Check out https://clang.llvm.org/docs/UsersManual.html#configuration-files. > > Thanks. I have looked into those. They seem to have different properties > in different distros. Compounding the problem is that some of the > subprojects in my tree use their own configuration files, and I would > override those or they would override mine. It looks like command-line > options, whether in a configuration file or not, probably won't help with my > situation. I haven't used configuration files, but the documentation says: > Configuration files can be either specified on the command line or loaded > from default locations. If both variants are present, the default > configuration files are loaded first. So a config file in a default location should not override the config file of the project, they should just be appended. You can get your options in without overriding the project, and the project would only override your options if they specifically choose another GCC toolchain for whatever reason. Currently clang doesn't require any version of libstdc++-devel, and I'd like to leave it that way: * Clang is a combined C/C++/OpenCL/... frontend, so we don't know if it was installed for C or C++ or something else. If you're just working in C, you don't need a C++ standard library. * Clang can also work with libc++, it's just not the default on most Linux distributions. Checking for libstdc++.so when detecting toolchains probably makes sense, since that should correlate with the availability of the full standard library. But I'm not sure if there is something more to it than going through the paths that Clang passes to the linker, or if linkers have their own mechanisms on top of that (I hope not). And as mentioned, I probably won't have the time for this in the near future. Though pure C programmers again complicate the picture: for them the tool chain without libstdc++.so is complete, they only care about the *crt*.o object files. So they wouldn't want Clang to reject a toolchain just because it doesn't have a C++ standard library. Are the C++ standard library and the *crt*.o object files coupled in any way? Or could the detection of GCC toolchain and libstdc++ be decoupled, potentially detecting different versions? (In reply to Aaron Puchert from comment #17) > I haven't used configuration files, but the documentation says: > > > Configuration files can be either specified on the command line or loaded > > from default locations. If both variants are present, the default > > configuration files are loaded first. > > So a config file in a default location should not override the config file > of the project, they should just be appended. You can get your options in > without overriding the project, and the project would only override your > options if they specifically choose another GCC toolchain for whatever > reason. Ah, I missed that. Thanks. I was looking later where the documentation says "The first file found is used." Apparently they were just talking about the defaults there. (Also the source code in Driver.cpp seemed to agree that only the first file found was used, but the first time around I missed the fact that those functions return "true" when they fail and "false" when they succeed.) So now the question is where to put the default config files. It turns out that Tumbleweed does not set the CLANG_CONFIG_FILE_USER_DIR or CLANG_CONFIG_FILE_SYSTEM_DIR cmake options when building clang. Gentoo sets CLANG_CONFIG_FILE_SYSTEM_DIR to /etc/clang, so they have a good place to put system-wide default files. Perhaps Tumbleweed should do the same. Also, Gentoo notes that "Technically, the build system also permits specifying 'user' configuration directory but it’s not practically useful, as it provides no way of referencing the user’s home directory." https://blogs.gentoo.org/mgorny/2022/10/07/clang-in-gentoo-now-sets-default-runtimes-via-config-file/ In other words, there is no way to put a reference to $HOME in the cmake configuration for clang. That creates a problem for multi-user systems where some users want a default config file and some don't. Given that neither of the cmake configuration options are set, that just leaves the directory where clang and clang++ live -- very ugly and error-prone for a user of the system to do. I did it anyway, and put a clang.cfg and clang++.cfg in /usr/bin with the following contents. > --gcc-install-dir=/usr/lib64/gcc/x86_64-suse-linux/13 That did indeed work, and the projects' config files were read as well. In a way that only works on a single-user system, then, and in a very dirty way that is not a long-term solution, I got it to work. For the specific problem we are working on here, it might be OK that only CLANG_CONFIG_FILE_SYSTEM_DIR makes any sense to use, because this is a system-wide problem. I hope that Tumbleweed will follow Gentoo's example and set it to /etc/clang instead of leaving it unset. Remember, though, this is just an unsustainable workaround for the problem that emacs-nox and emacs-x11 pull in an unreleased, unstable version of gcc that then interferes with clang++. (In reply to Aaron Puchert from comment #18) > Though pure C programmers again complicate the picture: for them the tool > chain without libstdc++.so is complete, they only care about the *crt*.o > object files. So they wouldn't want Clang to reject a toolchain just because > it doesn't have a C++ standard library. Remember that what we're talking about here is that it is pointing to an unreleased, unstable build of gcc. It really shouldn't be called gcc14 because it isn't good for *either* C or C++ users to pick it up unless they have a very specific need for that unstable build. Also, if a codebase has some C code and some C++ code, we wouldn't want the C code to be compiled with a reference to gcc14 and the C++ code to be compiled with a reference to gcc13. They should be consistent with each other, and should also point to an actual release rather than an unstable build. > Are the C++ standard library and the *crt*.o object files coupled in any > way? Or could the detection of GCC toolchain and libstdc++ be decoupled, > potentially detecting different versions? I don't think they're coupled, but I think I've shown why we wouldn't want them to detect different versions, especially when one of those versions is not a real release. (In reply to Aaron Puchert from comment #18) > Though pure C programmers again complicate the picture: for them the tool > chain without libstdc++.so is complete, they only care about the *crt*.o > object files. So they wouldn't want Clang to reject a toolchain just because > it doesn't have a C++ standard library. > > Are the C++ standard library and the *crt*.o object files coupled in any > way? Or could the detection of GCC toolchain and libstdc++ be decoupled, > potentially detecting different versions? They are not coupled in odd ways. I think it's reasonable and not a problem if an invocation of 'clang' picks a up a different GCC install than an invocation of 'clang++'. Note the crt files and the .so link of libgcc do not yet live in a separate package like libgcc-devel, but I plan to work on this when time permits so a libgccjit install (like that from emacs) doesn't pull in a C compiler but only the required libgcc .so link and the crt files. (In reply to David Keaton from comment #20) > (In reply to Aaron Puchert from comment #18) > > Though pure C programmers again complicate the picture: for them the tool > > chain without libstdc++.so is complete, they only care about the *crt*.o > > object files. So they wouldn't want Clang to reject a toolchain just because > > it doesn't have a C++ standard library. > > Remember that what we're talking about here is that it is pointing to an > unreleased, unstable build of gcc. It really shouldn't be called gcc14 > because it isn't good for *either* C or C++ users to pick it up unless they > have a very specific need for that unstable build. I think that's a mis-characterization, the GCC 14 packages are not "unstable", if they were we would not have introduced them (and make them provide the system runtime libraries). Yes, GCC 14 isn't released yet but it's in deep feature freeze. (In reply to Richard Biener from comment #21) > I think it's reasonable and not a problem > if an invocation of 'clang' picks a up a different GCC install than an > invocation of 'clang++'. It actually is a problem. GCC has been known to change ABIs between major compiler versions, so a project that contains both C and C++ would be unable to link if it happens to pick up different versions of GCC that straddle an ABI change boundary. (In reply to Richard Biener from comment #22) > I think that's a mis-characterization, the GCC 14 packages are not > "unstable", if they were we would not have introduced them (and make them > provide the system runtime libraries). Yes, GCC 14 isn't released yet but > it's in deep feature freeze. Unfortunately, features are not the most important measure of stability. The most recent status report on gcc.gnu.org still points here. https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html There remain significant regressions. In any case, it would not be good for a released version of Clang to be affected by an unreleased version of GCC, especially if the C and C++ compilers point to different versions of GCC. (In reply to David Keaton from comment #23) > (In reply to Richard Biener from comment #21) > > > I think it's reasonable and not a problem > > if an invocation of 'clang' picks a up a different GCC install than an > > invocation of 'clang++'. > > It actually is a problem. GCC has been known to change ABIs between major > compiler versions, so a project that contains both C and C++ would be unable > to link if it happens to pick up different versions of GCC that straddle an > ABI change boundary. Huh, not sure what you are talking about - this is just FUD, the C/C++ ABI boundary is completely stable. Even more so when just considering the startfiles (which is what matters here). (In reply to David Keaton from comment #24) > (In reply to Richard Biener from comment #22) > > > I think that's a mis-characterization, the GCC 14 packages are not > > "unstable", if they were we would not have introduced them (and make them > > provide the system runtime libraries). Yes, GCC 14 isn't released yet but > > it's in deep feature freeze. > > Unfortunately, features are not the most important measure of stability. > The most recent status report on gcc.gnu.org still points here. > > https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html > > There remain significant regressions. So does GCC 13 have significant regressions towards earlier versions. There's no compiler without bugs. But remember there are different classes of bugs (and regressions). > In any case, it would not be good for a released version of Clang to be > affected by an unreleased version of GCC, especially if the C and C++ > compilers point to different versions of GCC. Well, sure - I'm all for configuring a specific clang version to use a specific GCC version C++ standard library and C startfiles. But others think picking a random installed compiler is better. It's not for me to make this decision. (In reply to Richard Biener from comment #25) > (In reply to David Keaton from comment #23) > > It actually is a problem. GCC has been known to change ABIs between major > > compiler versions, so a project that contains both C and C++ would be unable > > to link if it happens to pick up different versions of GCC that straddle an > > ABI change boundary. > > Huh, not sure what you are talking about - this is just FUD, the C/C++ ABI > boundary is completely stable. Even more so when just considering the > startfiles (which is what matters here). Describing it as fear is somewhat correct, though it is based on experience. There is more to it than the C/C++ boundary or the startfiles. There have been two known versions of the psABI which affected both C and C++, and therefore programs that called back and forth between them. (See the documentation for GCC's -Wabi flag.) The psABI does not change often, especially when compared to the 18 versions of GCC's C++ ABI, but it has happened. (In reply to Richard Biener from comment #26) > (In reply to David Keaton from comment #24) > > https://gcc.gnu.org/pipermail/gcc/2024-March/243407.html > > > > There remain significant regressions. > > So does GCC 13 have significant regressions towards earlier versions. > There's > no compiler without bugs. But remember there are different classes of > bugs (and regressions). Exactly what I had in mind. A new GCC is not released until all P1 regressions are fixed, making an unreleased version inherently less stable. > > In any case, it would not be good for a released version of Clang to be > > affected by an unreleased version of GCC, especially if the C and C++ > > compilers point to different versions of GCC. > > Well, sure - I'm all for configuring a specific clang version to use a > specific GCC version C++ standard library and C startfiles. But others > think picking a random installed compiler is better. > > It's not for me to make this decision. OK, thanks for clarifying that. (In reply to David Keaton from comment #19) > So now the question is where to put the default config files. It turns out > that Tumbleweed does not set the CLANG_CONFIG_FILE_USER_DIR or > CLANG_CONFIG_FILE_SYSTEM_DIR cmake options when building clang. Gentoo sets > CLANG_CONFIG_FILE_SYSTEM_DIR to /etc/clang, so they have a good place to put > system-wide default files. Perhaps Tumbleweed should do the same. Good point, I thought they were available by default. Any thoughts about placing? I guess the natural choices are /etc/clang and ~/.config/clang? > Also, Gentoo notes that "Technically, the build system also permits > specifying 'user' configuration directory but it’s not practically useful, > as it provides no way of referencing the user’s home directory." > > https://blogs.gentoo.org/mgorny/2022/10/07/clang-in-gentoo-now-sets-default- > runtimes-via-config-file/ > > In other words, there is no way to put a reference to $HOME in the cmake > configuration for clang. That creates a problem for multi-user systems > where some users want a default config file and some don't. It seems we can use a tilde since https://reviews.llvm.org/D136940: #if defined(CLANG_CONFIG_FILE_USER_DIR) { SmallString<128> P; llvm::sys::fs::expand_tilde(CLANG_CONFIG_FILE_USER_DIR, P); UserConfigDir = static_cast<std::string>(P); } #endif But I haven't tried that yet. (In reply to David Keaton from comment #20) > Also, if a codebase has some C code and some C++ code, we wouldn't want the > C code to be compiled with a reference to gcc14 and the C++ code to be > compiled with a reference to gcc13. They should be consistent with each > other, and should also point to an actual release rather than an unstable > build. But doing that would mean we have to reject a toolchain without libstdc++ when compiling C, and I don't think we want that. (In reply to Richard Biener from comment #21) > They are not coupled in odd ways. I think it's reasonable and not a problem > if an invocation of 'clang' picks a up a different GCC install than an > invocation of 'clang++'. That's good to hear, then this would be a feasible option. > Note the crt files and the .so link of libgcc do not yet live in a separate > package like libgcc-devel, but I plan to work on this when time permits so > a libgccjit install (like that from emacs) doesn't pull in a C compiler but > only the required libgcc .so link and the crt files. That sounds reasonable. I did something similar with clang: the builtin header files are part of the libclang-cpp package, so that applications using clang as library can use them without requiring the compiler driver executable. (In reply to David Keaton from comment #23) > It actually is a problem. GCC has been known to change ABIs between major > compiler versions, so a project that contains both C and C++ would be unable > to link if it happens to pick up different versions of GCC that straddle an > ABI change boundary. That shouldn't be the case, or if it is, it is a compiler bug. That's true not only for GCC, it's also true for Clang between major versions, and you should even be able to mix compilers, i.e. compile parts of a project with GCC and other parts with Clang and link them together (without LTO of course). Of course compilers have bugs, and the ABI has gaps (I remember one about lambdas: https://itanium-cxx-abi.github.io/cxx-abi/cxx-abi-dev/archives/2013-January/002536.html), but that is what they strive to guarantee. Mixing binaries produced by different compilers should be possible, and is definitely "supported". (That is, you can file a bug if it breaks.) (In reply to David Keaton from comment #28) > Exactly what I had in mind. A new GCC is not released until all P1 > regressions are fixed, making an unreleased version inherently less stable. Not necessarily, sometimes a new compiler fixes bugs "by accident", or a bug fix was too large to be backported to an older version. Google for example apparently compile their internal code base with relatively recent snapshots of Clang, taken directly from the development branch. I've gotten a few comments on changes of mine that they break their code, mostly by generating additional warnings, within a few days of landing them. (I work on the frontend most of the time.) (In reply to Aaron Puchert from comment #29) > (In reply to David Keaton from comment #19) > > So now the question is where to put the default config files. It turns out > > that Tumbleweed does not set the CLANG_CONFIG_FILE_USER_DIR or > > CLANG_CONFIG_FILE_SYSTEM_DIR cmake options when building clang. Gentoo sets > > CLANG_CONFIG_FILE_SYSTEM_DIR to /etc/clang, so they have a good place to put > > system-wide default files. Perhaps Tumbleweed should do the same. > > Good point, I thought they were available by default. Any thoughts about > placing? I guess the natural choices are /etc/clang and ~/.config/clang? Those seem like good places to put them. I don't know of any better. > > In other words, there is no way to put a reference to $HOME in the cmake > > configuration for clang. That creates a problem for multi-user systems > > where some users want a default config file and some don't. > > It seems we can use a tilde since https://reviews.llvm.org/D136940: > > #if defined(CLANG_CONFIG_FILE_USER_DIR) > { > SmallString<128> P; > llvm::sys::fs::expand_tilde(CLANG_CONFIG_FILE_USER_DIR, P); > UserConfigDir = static_cast<std::string>(P); > } > #endif > > But I haven't tried that yet. Good. I hope that works. > (In reply to David Keaton from comment #23) > > It actually is a problem. GCC has been known to change ABIs between major > > compiler versions, so a project that contains both C and C++ would be unable > > to link if it happens to pick up different versions of GCC that straddle an > > ABI change boundary. > > That shouldn't be the case, or if it is, it is a compiler bug. That's true > not only for GCC, it's also true for Clang between major versions, and you > should even be able to mix compilers, i.e. compile parts of a project with > GCC and other parts with Clang and link them together (without LTO of > course). No, an ABI change requires incompatible compiler output; that isn't a bug in the compiler. Think about it. If the ABI passes certain arguments in registers, and then the ABI changes to pass those arguments in memory, then linking code compiled to the old version of the ABI with code compiled to the new version of the ABI will result in non-working code. If the compiler does not do anything to prevent those incompatible object files from linking successfully, then that would be a compiler bug. I did not pick that example at random. It happens to have been a real change in the psABI that required new versions of gcc after the change to generate code that will not work with code compiled under the old ABI. Submit request https://build.opensuse.org/request/show/1164981 adds the configuration file directories to llvm18. (In reply to David Keaton from comment #30) > No, an ABI change requires incompatible compiler output; that isn't a bug in > the compiler. Sure, but a compiler update should in general not change the ABI. Also we're actually talking about libstdc++, since Clang does not use the GCC compiler but only the standard library. That library has some guidelines: https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html. (Not that the compiler doesn't, but that's not relevant here.) > I did not pick that example at random. It happens to have been a real > change in the psABI that required new versions of gcc after the change to > generate code that will not work with code compiled under the old ABI. Mistakes have been made in the past. The goal is definitely to allow a seamless transition between compiler/library versions, for example by exposing ABI changes via compiler flags. ABI tags were used to enable coexistence of C++98 and C++11 ABIs. (https://developers.redhat.com/blog/2015/02/05/gcc5-and-the-c11-abi) (In reply to Aaron Puchert from comment #32) > Submit request https://build.opensuse.org/request/show/1164981 adds the > configuration file directories to llvm18. I notice that the directory does not contain the llvm version and the llvm docs do not indicate the config files searched have version specific names. That means the config is shared between installed llvm versions which makes it unsuitable to eventually hardwire a llvm-N -> GCC-M dependence (but that might not have been the intention). It opens up the possibility to have GCCs libstdc++-devel package to populate /etc/clang/clang++.cfg but then this would stick to GCC 7 headers on Leap. SUSE-RU-2024:1253-1: An update that has nine fixes can now be installed. Category: recommended (moderate) Bug References: 1210959, 1214934, 1217450, 1217667, 1218492, 1219031, 1219520, 1220724, 1221239 Maintenance Incident: [SUSE:Maintenance:33128](https://smelt.suse.de/incident/33128/) Sources used: openSUSE Leap Micro 5.3 (src): gcc13-13.2.1+git8285-150000.1.9.1 openSUSE Leap Micro 5.4 (src): gcc13-13.2.1+git8285-150000.1.9.1 openSUSE Leap 15.5 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP2 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP3 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise High Performance Computing 15 SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Manager Server 4.3 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server for SAP Applications 15 SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Desktop 15 SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Manager Retail Branch Server 4.3 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Manager Proxy 4.3 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise High Performance Computing 15 SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server for SAP Applications 15 SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Desktop 15 SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro for Rancher 5.3 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro 5.3 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro for Rancher 5.4 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro 5.4 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro 5.5 (src): gcc13-13.2.1+git8285-150000.1.9.1 Basesystem Module 15-SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1 Development Tools Module 15-SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Package Hub 15 15-SP5 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise High Performance Computing 15 SP2 LTSS 15-SP2 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP3 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise High Performance Computing ESPOS 15 SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise High Performance Computing LTSS 15 SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Desktop 15 SP4 LTSS 15-SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP2 LTSS 15-SP2 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP3 LTSS 15-SP3 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server 15 SP4 LTSS 15-SP4 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server for SAP Applications 15 SP2 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Server for SAP Applications 15 SP3 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Enterprise Storage 7.1 (src): gcc13-13.2.1+git8285-150000.1.9.1, cross-nvptx-gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro 5.1 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro 5.2 (src): gcc13-13.2.1+git8285-150000.1.9.1 SUSE Linux Enterprise Micro for Rancher 5.2 (src): gcc13-13.2.1+git8285-150000.1.9.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. SUSE-RU-2024:2087-1: An update that has 10 fixes can now be installed. Category: recommended (moderate) Bug References: 1188441, 1210959, 1214934, 1217450, 1217667, 1218492, 1219031, 1219520, 1220724, 1221239 Maintenance Incident: [SUSE:Maintenance:34272](https://smelt.suse.de/incident/34272/) Sources used: Toolchain Module 12 (src): cross-nvptx-gcc13-13.3.0+git8781-1.13.1, gcc13-13.3.0+git8781-1.13.1 SUSE Linux Enterprise High Performance Computing 12 SP5 (src): gcc13-13.3.0+git8781-1.13.1 SUSE Linux Enterprise Server 12 SP5 (src): gcc13-13.3.0+git8781-1.13.1 SUSE Linux Enterprise Server for SAP Applications 12 SP5 (src): gcc13-13.3.0+git8781-1.13.1 NOTE: This line indicates an update has been released for the listed product(s). At times this might be only a partial fix. If you have questions please reach out to maintenance coordination. |
When emacs is installed, clang++ cannot find the C++ library. To reproduce this: 1. Install emacs. It does not matter whether you install the X or non-X version. 2. Install clang. 3. Try to compile and link a C++ program. ``` $ clang++ hello.cpp /usr/bin/ld: cannot find -lstdc++: No such file or directory clang++: error: linker command failed with exit code 1 (use -v to see invocation) $ ``` The problem: The latest stable, released version of gcc is gcc13. I have this installed. When clang++ is run, it looks for the latest gcc it can find, to use its C++ library. However, both the emacs-x11 and emacs-nox packages depend on gcc14, which is unstable and unreleased. ``` $ zypper info --requires emacs-x11 | grep 14 libgccjit.so.0(LIBGCCJIT_ABI_14)(64bit) $ zypper info --requires emacs-nox | grep 14 libgccjit.so.0(LIBGCCJIT_ABI_14)(64bit) $ ``` Consequently, installing emacs causes gcc14 to be installed. Clang++ then finds this and tries to use it. ``` $ clang++ -v clang version 17.0.6 Target: x86_64-suse-linux Thread model: posix InstalledDir: /usr/bin Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/13 Found candidate GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/14 Selected GCC installation: /usr/bin/../lib64/gcc/x86_64-suse-linux/14 Candidate multilib: .;@m64 Selected multilib: .;@m64 $ ``` Since emacs does not require the C++ library, that is not installed. Clang++ tries to use gcc14 and finds libc++ missing. How to fix this: There is an unacceptable workaround. It is possible to work around the problem by installing libstdc++6-devel-gcc14 . The reason this is unacceptable is that then, a stable, released clang depends on an unstable, unreleased gcc installation. It would not be possible to trust the binaries compiled and linked by this configuration. I see a few possible ways to fix it in acceptable ways. Any one of them would work. 1. Do not make emacs-x11 and emacs-nox depend on a gcc14 library. 2. Install unstable, unreleased versions of gcc in a different location so clang++ cannot find them. 3. Modify the clang package not to find unstable, unreleased versions of gcc.