public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] libgfortran: avoid duplicate libraries in spec
@ 2023-12-19  8:02 FX Coudert
  2023-12-19 21:04 ` Jerry D
  0 siblings, 1 reply; 4+ messages in thread
From: FX Coudert @ 2023-12-19  8:02 UTC (permalink / raw)
  To: fortran; +Cc: GCC Patches, ro@cebitec.uni-bielefeld.de , Iain Sandoe

[-- Attachment #1: Type: text/plain, Size: 1158 bytes --]

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(-)



[-- Attachment #2: 0001-libgfortran-avoid-duplicate-libraries-in-spec.patch --]
[-- Type: application/octet-stream, Size: 990 bytes --]

From e06aa9670dda36b141e3c67bf11ad743f59a6370 Mon Sep 17 00:00:00 2001
From: Francois-Xavier Coudert <fxcoudert@gcc.gnu.org>
Date: Mon, 18 Dec 2023 16:17:22 +0100
Subject: [PATCH] libgfortran: avoid duplicate libraries in spec

The linking of libgcc is already present in %(liborig), so the current
situation duplicates libraries. This was not an issue until macOS's new
linker started giving warnings for such cases.

libgfortran/ChangeLog:

	PR libfortran/110651
	* libgfortran.spec.in: Remove duplicate libraries.
---
 libgfortran/libgfortran.spec.in | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/libgfortran/libgfortran.spec.in b/libgfortran/libgfortran.spec.in
index 367d485c230..058ee5775bf 100644
--- a/libgfortran/libgfortran.spec.in
+++ b/libgfortran/libgfortran.spec.in
@@ -5,4 +5,4 @@
 #
 
 %rename lib liborig
-*lib: @LIBQUADSPEC@ @LIBM@ %(libgcc) %(liborig)
+*lib: @LIBQUADSPEC@ @LIBM@ %(liborig)
-- 
2.39.3 (Apple Git-145)


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] libgfortran: avoid duplicate libraries in spec
  2023-12-19  8:02 [PATCH] libgfortran: avoid duplicate libraries in spec FX Coudert
@ 2023-12-19 21:04 ` Jerry D
  2023-12-19 21:10   ` FX Coudert
  0 siblings, 1 reply; 4+ messages in thread
From: Jerry D @ 2023-12-19 21:04 UTC (permalink / raw)
  To: fortran

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] libgfortran: avoid duplicate libraries in spec
  2023-12-19 21:04 ` Jerry D
@ 2023-12-19 21:10   ` FX Coudert
  2023-12-19 21:12     ` Jerry D
  0 siblings, 1 reply; 4+ messages in thread
From: FX Coudert @ 2023-12-19 21:10 UTC (permalink / raw)
  To: Jerry D; +Cc: fortran

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] libgfortran: avoid duplicate libraries in spec
  2023-12-19 21:10   ` FX Coudert
@ 2023-12-19 21:12     ` Jerry D
  0 siblings, 0 replies; 4+ messages in thread
From: Jerry D @ 2023-12-19 21:12 UTC (permalink / raw)
  To: FX Coudert; +Cc: fortran

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

^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-12-19 21:12 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-12-19  8:02 [PATCH] libgfortran: avoid duplicate libraries in spec FX Coudert
2023-12-19 21:04 ` Jerry D
2023-12-19 21:10   ` FX Coudert
2023-12-19 21:12     ` Jerry D

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).