Re: [PATCH] libgfortran: avoid duplicate libraries in spec
On 12/19/23 1:10 PM, FX Coudert wrote: Hi, I am getting side notes about people having these issues with gfortran 13. Is this something that should be backported. I have already backported it in the latest Homebrew package (because we have many users complaining about it). I intend to backport but will wait for a conservative amount of time before doing so. Apparently it is causing some none gfortran compilations to break, but I do not know if this is the same issue. Don’t think so. I can have a look if you give me a pointer. FX See: https://github.com/vmagnin/gtk-fortran/issues/280#issuecomment-1863377748 Thanks ahead of time if you have time. Jerry
Re: [PATCH] libgfortran: avoid duplicate libraries in spec
Hi, > I am getting side notes about people having these issues with gfortran 13. Is > this something that should be backported. I have already backported it in the latest Homebrew package (because we have many users complaining about it). I intend to backport but will wait for a conservative amount of time before doing so. > Apparently it is causing some none gfortran compilations to break, but I do > not know if this is the same issue. Don’t think so. I can have a look if you give me a pointer. FX
Re: [PATCH] libgfortran: avoid duplicate libraries in spec
On 12/19/23 12:02 AM, FX Coudert wrote: When gfortran invokes the linker, it reads the linking spec from libgfortran. This ends up doing things like: -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This wasn’t a problem, until the new macOS linker, which gives a warning for this: the warning is innocuous, but having a warning for every time you call gfortran for linking clutters the terminal, and makes all the testsuite fail. And linking twice is superfluous, so removing it will not be a problem. I am the author of the original commit to the spec, in 2010, but honestly I have no memory: I think I vaguely remember saying “better safe than sorry”, but 13 years later it could just be a false memory ;) Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as *-*-solaris2.11 by Rainer. OK to commit? (seems admissible in stage 3 because it fixes regtesting on darwin22 and darwin23). FX libgfortran/ChangeLog: PR libfortran/110651 * libgfortran.spec.in: Remove duplicate libraries. --- libgfortran/libgfortran.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) I am getting side notes about people having these issues with gfortran 13. Is this something that should be backported. Apparently it is causing some none gfortran compilations to break, but I do not know if this is the same issue. I say OK for trunk. Jerry
[PATCH] libgfortran: avoid duplicate libraries in spec
When gfortran invokes the linker, it reads the linking spec from libgfortran. This ends up doing things like: -lm -lgcc_s -lgcc -lc -lgcc_s -lgcc where you can see that libgcc (both -lgcc and -lgcc_s) is linked in twice. This wasn’t a problem, until the new macOS linker, which gives a warning for this: the warning is innocuous, but having a warning for every time you call gfortran for linking clutters the terminal, and makes all the testsuite fail. And linking twice is superfluous, so removing it will not be a problem. I am the author of the original commit to the spec, in 2010, but honestly I have no memory: I think I vaguely remember saying “better safe than sorry”, but 13 years later it could just be a false memory ;) Anyway, this was tested on x86_64-darwin and x64_86-linux, as well as *-*-solaris2.11 by Rainer. OK to commit? (seems admissible in stage 3 because it fixes regtesting on darwin22 and darwin23). FX libgfortran/ChangeLog: PR libfortran/110651 * libgfortran.spec.in: Remove duplicate libraries. --- libgfortran/libgfortran.spec.in | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) 0001-libgfortran-avoid-duplicate-libraries-in-spec.patch Description: Binary data