Summary: | sys-devel/gcc-3.4.6-r2 fails to compile with gcc-4.4.2: .../build/gcc/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/gcc/i686-pc-linux-gnu/4.4.2/libstdc++.so.6) | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Andrew Savchenko <bircoph> |
Component: | [OLD] Core system | Assignee: | Gentoo Toolchain Maintainers <toolchain> |
Status: | RESOLVED OBSOLETE | ||
Severity: | normal | CC: | alunduil, bircoph, duncanphilipnorman, j6yNRdsH5Fc3, jlec, johannes.hirte, kentnl, marcin.wandas, Martin.vGagern, mgorny, mmokrejs |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=357173 https://bugs.gentoo.org/show_bug.cgi?id=843119 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
build.log
environment build.log gcc:4.1 using gcc:4.9 |
Description
Andrew Savchenko
2009-12-02 19:16:32 UTC
Created attachment 211807 [details]
build.log
Created attachment 211809 [details]
environment
With the same setup gcc-3.3.6-r1 compiles ok. So please fix stable. (What I really need from those old compilers is g77, because I must work with outdated undocumented braindead fortran software which cannot be compiled with gfortran because it use a lot of nonstandard g77 features removed in gfortran.) gfortran should compile F77 programs just fine in all of their crappy glory. Just make sure the extension is correct so that gfortan knows to use the deprecated stuff. Your file extension should be .f77 or .F77 depending on whether you want the preprocessor run or not. If this doesn't work please post back the results of the build so we can potentially check that as well. (In reply to comment #4) > gfortran should compile F77 programs just fine in all of their crappy glory. > Just make sure the extension is correct so that gfortan knows to use the > deprecated stuff. Your file extension should be .f77 or .F77 depending on > whether you want the preprocessor run or not. > > If this doesn't work please post back the results of the build so we can > potentially check that as well. This has nothing to do with file extensions. Applications I use depends on libg2c. This library is not present in gfortran, but was present in g77. (In reply to comment #5) > (In reply to comment #4) > This has nothing to do with file extensions. Applications I use depends on > libg2c. This library is not present in gfortran, but was present in g77. After taking libg2c from g77 and linking against it with gfortran applications work as expected. So what I really need is libg2c, not g77, but the only way to install it in Gentoo is to install gcc-3.{34} with USE=gfortran [sorry, sent previous message too early] *** This bug has been marked as a duplicate of bug 287667 *** not a dupe after all *** Bug 301156 has been marked as a duplicate of this bug. *** *** Bug 372377 has been marked as a duplicate of this bug. *** (In reply to comment #10) > *** Bug 372377 has been marked as a duplicate of this bug. *** Just a note for anyone looking for a workaround: gcc-4.1.2 will compile for me with the following use flags: USE="doc fortran gtk mudflap multilib nptl" Specifically, I needed to add USE=-nls to compile. This may work for gcc-3.4.6-r2 as well (I'm not sure; I haven't tried). Bug #372377 comment #7 has a patch by me to solve that problem, i.e. errors by msgfmt. It won't solve the errors by cc1 that comment #0 quotes, though. So I suppose that bug isn't necessarily a duplicate of this one here. Perhaps a similar solution can be applied to the cc1 case as well, but as I fail to reproduce that here on my system in the first case, I'm not sure. (In reply to comment #12) > Bug #372377 comment #7 has a patch by me to solve [...] errors by msgfmt. Bit me again today. Any chance of getting this patch applied? It's really short, and easy to verify. So please either apply that patch, or un-dupe and re-open bug #372377 so that the patch and possible alternatives can be discussed there. *** Bug 391247 has been marked as a duplicate of this bug. *** Has the status of this bug changed in the last three years? Is the patch still needed to solve an issue? If I don't hear anything by Sept 20, I'll assume this is no longer an issue and mark it invalid. *** Bug 523028 has been marked as a duplicate of this bug. *** (In reply to Alex Brandt from comment #15) > Has the status of this bug changed in the last three years? Is the patch > still needed to solve an issue? > > If I don't hear anything by Sept 20, I'll assume this is no longer an issue > and mark it invalid. it is valid for different old gcc. (In reply to Justin Lecher from comment #17) > (In reply to Alex Brandt from comment #15) > > Has the status of this bug changed in the last three years? Is the patch > > still needed to solve an issue? > > > > If I don't hear anything by Sept 20, I'll assume this is no longer an issue > > and mark it invalid. > > it is valid for different old gcc. Bug #372377 comment #7 fixes the issue for me ATM I use gcc-4.8.3 and I'm able to compile gcc-3.4.6-r2 successfully. I no longer use gcc:4.4. (In reply to Alex Brandt from comment #15) > Has the status of this bug changed in the last three years? Is the patch > still needed to solve an issue? > > If I don't hear anything by Sept 20, I'll assume this is no longer an issue > and mark it invalid. Though I'd like to mention one point. Statement "if you will not test it, I'll mark it as invalid" is both offensive and invalid itself. If developer needs user's feedback either NEEDINFO or TEST-REQUEST status should be used (for this and similar cases TEST-REQUEST looks like a better choice). Hey Andrew, Am I understanding your last comment correctly? I understand your comment to mean the issue has been resolved and we can potentially mark this bug as solved. If not, could you please let me know what action might get this issue moving forward again? Thanks! Hi Alex, the issue has been solved for gcc:4.8. But gcc:4.4 is still in tree and people may use it. I had not tested gcc-4.4.7, so I'm not sure that this issue is closed. Anyway it will not affect most of users, because use case when old gcc version (4.4.7) is being used to build even older one (3.4.6-r2) is quite odd. Created attachment 387450 [details]
build.log gcc:4.1 using gcc:4.9
I cannot build gcc:4.1 with gcc:4.0
*** Bug 529500 has been marked as a duplicate of this bug. *** Hi, Just thought I'd add that gcc-3.4.6-r2 will only compile with gcc-4.8.3 if I disable the NLS use flag. With the NLS use flag enabled, msgfmt (from gettext-0.18.3.2) errors out with this message: msgfmt: /var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/build/gcc/libgcc_s.so.1: version `GCC_4.2.0' not found (required by /usr/lib/gcc/x86_64-pc-linux-gnu/4.8.3/libstdc++.so.6) Thanks, Dyweni (In reply to Justin Lecher from comment #18) > (In reply to Justin Lecher from comment #17) > > > > it is valid for different old gcc. > > Bug #372377 comment #7 fixes the issue for me (In reply to Justin Lecher from comment #23) > Created attachment 387450 [details] > build.log gcc:4.1 using gcc:4.9 > > I cannot build gcc:4.1 with gcc:4.0 There are two related but distinct issues going on here. Both occur because the system libstdc++.so.6 (found at /usr/lib/gcc/<tuple>/<current-gcc-version>/libstdc++.so.6) is linking against the instance of libgcc_s.so just built as part of the current build process of gcc (found at /var/tmp/portage/sys-devel/gcc-3.4.6-r2/work/build/gcc/libgcc_s.so.1 in this example). This is not the system libgcc_s.so.1 which is found at /usr/lib/gcc/<tuple>/<current-gcc-version>/libgcc_s.so.1. Because system libstdc++.so.6 is newer than the currently built libgcc_s.so.1, it doesn't find the correction symbol versioning in libgcc_s.so and craps out. The patch in Bug #372377 comment #7 deals with msgfmt hitting this as it consumes the system libstdc++.so.6. Here the problem is due to cc1 consuming libstdc++.so.6. The same trick of unsetting LD_LIBRARY_PATH may work here too. The effect of unsetting LD_LIBRARY_PATH is to have the system libstdc++.so.6 link against the system libgcc_s.so.1 which had better work else you have a seriously broken system. Note: above <current-gcc-version> can be chosen by gcc-config. Needed an ancient GCC to compile some 16-year-old C-Code. Was impossible to build GCC 3.4.6 with GCC 5.3.0 with USE="-* ntpl" GCC 4.1.2 however does build with GCC 5.3.0 with USE="-* ntpl" And GCC 3.4.6 builds with GCC 4.1.2 *** Bug 599330 has been marked as a duplicate of this bug. *** EUNSUPPORTED The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/gcc-patches.git/commit/?id=6fb906ef2da01327d64cea263887ef34c97c1bbf commit 6fb906ef2da01327d64cea263887ef34c97c1bbf Author: Alfredo Tupone <tupone@gentoo.org> AuthorDate: 2022-09-18 07:15:53 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2022-09-30 00:13:22 +0000 10.3.0: backport glibc 2.36, gettext/msgfmt patch from 10.4.0 Bug: https://bugs.gentoo.org/295480 Bug: https://bugs.gentoo.org/372377 Bug: https://bugs.gentoo.org/843119 Bug: https://bugs.gentoo.org/864717 Bug: https://bugs.gentoo.org/865879 Closes: https://github.com/gentoo/gcc-patches/pull/2 Signed-off-by: Sam James <sam@gentoo.org> 10.3.0/gentoo/36_all_msgfmt-libstdc++-link.patch | 39 ++++++++++++++ 10.3.0/gentoo/37_all_glibc_236.patch | 68 ++++++++++++++++++++++++ 10.3.0/gentoo/README.history | 4 ++ 3 files changed, 111 insertions(+) |