Bug 257060 - lang/gcc*: conflicts on libgccjit.h and libgccjit++.h
Summary: lang/gcc*: conflicts on libgccjit.h and libgccjit++.h
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Lorenzo Salvadore
URL: https://reviews.freebsd.org/D37242
Keywords:
Depends on:
Blocks:
 
Reported: 2021-07-08 17:20 UTC by Ting-Wei Lan
Modified: 2024-04-06 19:15 UTC (History)
7 users (show)

See Also:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ting-Wei Lan 2021-07-08 17:20:17 UTC
Installing gcc12-devel-12.0.0.s20210627...
pkg-static: gcc12-devel-12.0.0.s20210627 conflicts with gcc11-11.1.0 (installs files into the same place).  Problematic file: /usr/local/include/libgccjit++.h

I am not sure if it is an expected behevior. Previous versions of gcc ports don't conflict as long as they have different major version numbers.
Comment 1 Dimitry Andric freebsd_committer freebsd_triage 2021-07-17 19:23:45 UTC
Yeah, just a "me too" here:

===>  Installing for gcc12-devel-12.0.0.s20210711
===>  Checking if gcc12-devel is already installed
===>   Registering installation for gcc12-devel-12.0.0.s20210711
Installing gcc12-devel-12.0.0.s20210711...
pkg-static: gcc12-devel-12.0.0.s20210711 conflicts with gcc11-11.1.0 (installs files into the same place).  Problematic file: /usr/local/include/libgccjit++.h
*** Error code 1

I regularly install most of the gcc ports, and gcc11 can't coexist with gcc12. :)
Comment 2 Dimitry Andric freebsd_committer freebsd_triage 2021-07-17 19:58:08 UTC
Hm at first sight these two headers are new for gcc 11 and 12. But they seem to be a slightly different case than other gcc 'internal' headers, such as in:

/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd14.0/11.1.0/include/

Maybe these should be put in something like /usr/local/include/gcc11 instead, like the gcc11 specific libraries are now put in /usr/local/lib/gcc11 ?
Comment 3 Gerald Pfeifer freebsd_committer freebsd_triage 2021-07-17 20:31:06 UTC
I filed this upstream at https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
Let's see what comes out of that before we add a local hack.

(Should we add CONFLICTS among these ports for now? lang/gcc12-devel is very
early still, not meant for regular users, so maybe that's okay-ish?)
Comment 4 John Hein 2022-06-30 23:11:14 UTC
Now that the default gcc is 11, we may see this problem more often.  I had gcc12 installed (I don't remember why at the moment), and just tried to build for the recent math/R update.  This pulled in the default gcc (for gfortran) which is now 11.  And this triggered the failure.

There is a suggestion for a different location of the libgccjit++.h in the upstream bug.  Maybe we should try using that and report back to upstream.  Given that there has been no motion in a year, a report of what works might spur them to accept the change upstream.

Does anyone know of a consumer in the ports tree that uses the libgccjit++.h or libgccjit.h header files?  If there is one, we can check whether moving the header  breaks it.  Hmm, it looks like emacs will use it if you build emacs with the NATIVECOMP option.
Comment 5 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-10-06 22:15:54 UTC
Gerald, I am taking the bug as I am now the maintainer of the gcc ports, but please feel free to keep working on it if you want.

I also encountered the bug installing both lang/gcc11 and lang/gcc12.

I am going to study the bug reported upstream and see how to fix the issue.
Comment 6 Gerald Pfeifer freebsd_committer freebsd_triage 2022-10-13 12:09:36 UTC
Thank you, Lorenzo!

One pragmatic idea: How about only packaging this with the default 
version of GCC (aka GCC_DEFAULT), at least for now?

That avoids the conflict and, frankly, anyone who is using something
different is going to run into "funny" moments sooner or later anyway.

(And, more than frankly, simply ignore powerpcspe which has GCC_DEFAULT
set to 8 since GCC removed that port afterwards for lack of future and
use.
Comment 7 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-02 22:46:18 UTC
A patch is ready for trying to fix the issue, applied only to GCC_DEFAULT for now as suggested by gerald@: https://reviews.freebsd.org/D37242.

Gerald: I do not think we need an exp-run for this change, do we? I guess that any port needing those two headers will still find them in the new location, isn't it? I trust your experience more than my intuition: if you think that this needs more testing I am going to ask for the exp run.
Comment 8 Gerald Pfeifer freebsd_committer freebsd_triage 2022-11-03 07:16:52 UTC
(In reply to Lorenzo Salvadore from comment #7)
> A patch is ready for trying to fix the issue

Very cool!

> applied only to GCC_DEFAULT for now as suggested by gerald@:

With the switch of GCC_DEFAULT to GCC 12 pending, it's probably now a
good idea to also consider that?

> Gerald: I do not think we need an exp-run for this change, do we?

Agreed, that would be too heavy. Building the port mentioned in
comment #4 here could be a good test, though.

Are you then planning to submit this upstream, too? Essentially share
the patch with gcc-patches@gcc.gnu.org (with a GNU ChangeLog). I can
help with that.
Comment 9 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-03 08:56:02 UTC
> With the switch of GCC_DEFAULT to GCC 12 pending, it's probably now a good idea to also consider that?

Sure, I agree. Moreover, if I patch GCC 12 before the next exp-run for GCC_DEFAULT update, we will get a full exp-run for this change too.

> Building the port mentioned in comment #4 here could be a good test, though.

I will do it before committing the change.

> Are you then planning to submit this upstream, too? Essentially share
the patch with gcc-patches@gcc.gnu.org (with a GNU ChangeLog). I can
help with that.

Yes, I am planning to share with upstream assuming everything goes as expected. And your help is most welcome.
Comment 10 commit-hook freebsd_committer freebsd_triage 2022-11-03 12:30:35 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=dc67e7d3009de2b78d96136c8ad09cf186e553df

commit dc67e7d3009de2b78d96136c8ad09cf186e553df
Author:     Lorenzo Salvadore <salvadore@FreeBSD.org>
AuthorDate: 2022-11-02 22:24:57 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2022-11-03 12:29:06 +0000

    lang/gcc11: Fix conflict on libgccjit.h and libgccjig++.h

    GCC 11, GCC 12 and GCC 13 install libgccjit.h and libgccjit++.h in the
    same directory.

    Fix conflict for GCC 11, which is GCC_DEFAULT, by installing those files
    in a directory specific to GCC 11.

    PR:             257060
    Reported by:    Ting-Wei Lan <lantw44@gmail.com>
    Reviewed by:    gerald, dim
    Differential Revision:  https://reviews.freebsd.org/D37242
    See also:       https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491

 lang/gcc11/Makefile                               |  2 +-
 lang/gcc11/files/patch-gcc_Makefile.in (new)      | 19 +++++++++++++++++++
 lang/gcc11/files/patch-gcc_jit_Make-lang.in (new) | 14 ++++++++++++++
 lang/gcc11/pkg-plist                              |  2 --
 4 files changed, 34 insertions(+), 3 deletions(-)
Comment 11 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-03 12:35:15 UTC
The commit in comment #10 should fix the main conflict for now. I keep the bug open as work on the other gcc ports and with upstream is still needed for a complete fix.
Comment 12 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-04 17:48:04 UTC
Unfortunately the commit in comment #10 has a mistake, so progress on this bug report will go slower than planned.

After that commit emacs fails to find libgccjit.h. I did test emacs before committing as recommended, but unfortunately I had a misconfiguration in my make.conf in my poudriere jail, so I tested it wrongly and missed the bug.

I have corrected the mistake in revision https://reviews.freebsd.org/D37266 but I have not committed it yet because this is not enough to have emacs building successfully. I have proposed in the revision to modify the emacs ports so that they search the header in the right directory.
Comment 13 John Hein 2022-11-04 19:40:50 UTC
(In reply to Gerald Pfeifer from comment #8)
Regarding an exp-run...  I have been building ports updates since July 1 with something very similar to the patch that was just committed to the FreeBSD ports tree (see [[1]]).  It's not quite the coverage of a formal exp-run, but it covers about 3000 ports built daily-ish from source as the ports change.

I should have reported that success in the upstream bug.  Anyway, this is just some anecdotal evidence that this change has worked fine in a real world case.  Thanks for following up on this issue.

[[1]] My patch was:

 % cat files/patch-gcc-jit-Make-lang.in
Change where libgccjit*.h is installed.

See:
 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101491
 https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=257060

--- gcc/jit/Make-lang.in.orig   2022-04-21 07:58:53 UTC
+++ gcc/jit/Make-lang.in
@@ -355,9 +355,10 @@ selftest-jit:
 # Install hooks:
 jit.install-headers: installdirs
+       mkdir $(DESTDIR)$(libsubdir)/include
        $(INSTALL_DATA) $(srcdir)/jit/libgccjit.h \
-         $(DESTDIR)$(includedir)/libgccjit.h
+         $(DESTDIR)$(libsubdir)/include/libgccjit.h
        $(INSTALL_DATA) $(srcdir)/jit/libgccjit++.h \
-         $(DESTDIR)$(includedir)/libgccjit++.h
+         $(DESTDIR)$(libsubdir)/include/libgccjit++.h

 ifneq (,$(findstring mingw,$(target)))
 jit.install-common: installdirs jit.install-headers


In that version of the patch, I didn't need to rely on libsubincludedir in gcc/Makefile, so I don't have the mistake referred to in comment 12.
Comment 14 John Hein 2022-11-04 19:51:29 UTC
(In reply to John Hein from comment #13)
p.s. I have had no trouble building emacs with my gcc11 patch to install libgccgit*.h in /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd12.3/11.3.0/include (emacs was last built Sep 22 here with NATIVECOMP on).  What problem did you have with emacs?
Comment 15 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-04 20:11:01 UTC
(In reply to John Hein from comment #14)

My emacs build fails in configure with the following log:

checking for gcc_jit_context_acquire in -lgccjit... yes                    
checking libgccjit.h usability... no                                       
checking libgccjit.h presence... no                                        
checking for libgccjit.h... no
configure: error: ELisp native compiler was requested, but libgccjit header
 files were
not found.
Please try installing libgccjit-dev or a similar package.
If you are sure you want Emacs be compiled without ELisp native compiler,
pass the --without-native-compilation option to configure.

After applying the patch in https://reviews.freebsd.org/D37266, I install the headers in exactly the same directory than you. Any idea what else could be different on our machines?

I add jrm to CC from the Phabricator review, who also has his emacs build failing in configure.
Comment 16 John Hein 2022-11-04 20:42:53 UTC
From my 'make -C editors/emacs WITH=NATIVECOMP configure'...

.
.
checking build system type... amd64-portbld-freebsd12.3
checking host system type... amd64-portbld-freebsd12.3
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether we are using the GNU C compiler... yes
checking whether gcc11 accepts -g... yes
checking for gcc11 option to enable C11 features... none needed
checking whether the compiler is clang... no
checking for compiler option needed when checking for declarations... none
checking whether gcc11 and cc understand -c and -o together... yes
checking how to run the C preprocessor... cpp11
.
.
checking for gcc_jit_context_acquire in -lgccjit... yes
checking libgccjit.h usability... yes
checking libgccjit.h presence... yes
checking for libgccjit.h... yes
.
.

% find /usr/local -name libgccjit.h
/usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd12.3/11.3.0/include/libgccjit.h


So it is using gcc11 and gcc11 is, of course built to be able to find headers in that location.  I don't understand why yours would fail if you are also using gcc11 from ports.
Comment 17 John Hein 2022-11-04 20:44:24 UTC
(emacs' config.log might provide more information)
Comment 18 John Hein 2022-11-04 20:50:27 UTC
Here is the relevant excerpt from emacs-28.2/config.log here...

.
.
configure:16557: checking for gcc_jit_context_acquire in -lgccjit
configure:16582: gcc11 -o conftest -I/usr/local/include -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc11 -isystem /usr/local/include -fno-strict-aliasing  -I/usr/local/include/librsvg-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -D_THREAD_SAFE -pthread  -I/usr/local/include   -isystem /usr/local/include  -L/usr/local/lib/gcc11 -Wl,-rpath=/usr/local/lib -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc11 -L/usr/local/lib/gcc11 -L/usr/local/lib  -L/usr/local/lib conftest.c -lgccjit  -lX11 -lutil  >&5
configure:16582: $? = 0
configure:16591: result: yes
configure:16610: checking libgccjit.h usability
configure:16610: gcc11 -c -I/usr/local/include -O2 -pipe  -fstack-protector-strong -Wl,-rpath=/usr/local/lib/gcc11 -isystem /usr/local/include -fno-strict-aliasing  -I/usr/local/include/librsvg-2.0 -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/local/include/libpng16 -D_THREAD_SAFE -pthread  -I/usr/local/include   -isystem /usr/local/include conftest.c >&5
configure:16610: $? = 0
configure:16610: result: yes
configure:16610: checking libgccjit.h presence
configure:16610: cpp11 -I/usr/local/include   -isystem /usr/local/include conftest.c
configure:16610: $? = 0
configure:16610: result: yes
configure:16610: checking for libgccjit.h
configure:16610: result: yes
.
.
Comment 19 John Hein 2022-11-04 21:09:48 UTC
If it's still failing for you, try building a simple foo.c with just "#include <libgccjit.h>" using 'gcc11 -v' to show where it's looking.
Comment 20 commit-hook freebsd_committer freebsd_triage 2022-11-04 21:24:02 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=9f0cd13014d0962aedfa016c86a5af07ca3ba814

commit 9f0cd13014d0962aedfa016c86a5af07ca3ba814
Author:     Lorenzo Salvadore <salvadore@FreeBSD.org>
AuthorDate: 2022-11-04 21:13:09 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2022-11-04 21:22:03 +0000

    lang/gcc11: Revert "Fix conflict on libgccjit.h and libgccjit++.h"

    This reverts commit dc67e7d3009de2b78d96136c8ad09cf186e553df.

    The revert is necessary as

    - lang/gcc11/files/patch-gcc_Makefile.in was wrong: it should have used
      $(version) instead of $(gcc_version);

    - even after correcting the above mistake, the patch still does not
      work: lang/emacs fails to configure and hence to build. See also
      https://reviews.freebsd.org/D37266 .

    PR:     257060
    Reported by:    yasu

 lang/gcc11/Makefile                                |  2 +-
 lang/gcc11/files/patch-gcc_Makefile.in (gone)      | 19 -------------------
 lang/gcc11/files/patch-gcc_jit_Make-lang.in (gone) | 14 --------------
 lang/gcc11/pkg-plist                               |  2 ++
 4 files changed, 3 insertions(+), 34 deletions(-)
Comment 21 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-04 21:27:20 UTC
(In reply to commit-hook from comment #10)

The commit has been reverted for now, so that editors/emacs now builds successfully again.

(In reply to John Hein from comment #19)

I am testing your patch. I will let you know how it goes as soon as I have some results.
Comment 22 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-04 23:39:50 UTC
(In reply to John Hein from comment #18)

I have tried to apply exactly your patch, but it still fails. Here is my config.log.

---

configure:16610: checking libgccjit.h usability                                                                                                                                                
configure:16610: cc -c -I/usr/local/include -O2 -pipe  -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing  -I/usr/local/include/librsvg-2.0 -I/usr/local/include/glib-2.
0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include -I/usr/local/include/gdk-pixbuf-2.0 -I/usr/local/include/cairo -I/usr/local/include/pixman-1 -I/usr/local/include/freetype2 -I/usr/loc
al/include/libpng16 -D_THREAD_SAFE -pthread  -I/usr/local/include/cairo -I/usr/local/include -I/usr/local/include/glib-2.0 -I/usr/local/lib/glib-2.0/include -I/usr/local/include/pixman-1 -I/u
sr/local/include/freetype2 -I/usr/local/include/libpng16 -D_THREAD_SAFE -pthread  -I/usr/local/include   -isystem /usr/local/include conftest.c >&5                                            
conftest.c:188:10: fatal error: 'libgccjit.h' file not found                                                                                                                                   
#include <libgccjit.h>                                                                                                                                                                         
         ^~~~~~~~~~~~~                                                                                                                                                                         
1 error generated.                                                                             
configure:16610: $? = 1                                                                                                                                                                        
configure: failed program was:                                                                                                                                                                 
| /* confdefs.h */                                                                                                                                                                             
| #define PACKAGE_NAME "GNU Emacs"                                                                                                                                                             
| #define PACKAGE_TARNAME "emacs"
| #define PACKAGE_VERSION "28.2"
| #define PACKAGE_STRING "GNU Emacs 28.2"
| #define PACKAGE_BUGREPORT "bug-gnu-emacs@gnu.org"
--
| #endif
| #ifdef HAVE_INTTYPES_H
| # include <inttypes.h>
| #endif
| #ifdef HAVE_STDINT_H
| # include <stdint.h>
| #endif
| #ifdef HAVE_UNISTD_H
| # include <unistd.h>
| #endif
| #include <libgccjit.h>
configure:16610: result: no
configure:16610: checking libgccjit.h presence
configure:16610: cpp -I/usr/local/include   -isystem /usr/local/include conftest.c
conftest.c:155:10: fatal error: 'libgccjit.h' file not found
#include <libgccjit.h>                                                                                                                                                                         
         ^~~~~~~~~~~~~                                                                                                                                                                         
1 error generated.                                                                                                                                                                             
configure:16610: $? = 1                                                                                                                                                                        
configure: failed program was:                                                                                                                                                                 
| /* confdefs.h */                                                                                                                                                                             
| #define PACKAGE_NAME "GNU Emacs"                                                                                                                                                             
| #define PACKAGE_TARNAME "emacs"                                                                                                                                                              
| #define PACKAGE_VERSION "28.2"                                                                                                                                                               
| #define PACKAGE_STRING "GNU Emacs 28.2"                                                                                                                                                      
| #define PACKAGE_BUGREPORT "bug-gnu-emacs@gnu.org"                                                                                                                                            
--                                                                                                                                                                                             
| #define HAVE_XPM 1                                                                                                                                                                           
| #define HAVE_JPEG 1                                                                                                                                                                          
| #define HAVE_LCMS2 1                                                                                                                                                                         
| #define HAVE_ZLIB 1                                                                                                                                                                          
| #define HAVE_DLADDR 1                                                                                                                                                                        
| #define HAVE_DLFUNC 1                                                                                                                                                                        
| #define HAVE_MODULES 1                                                                       
| #define MODULES_SUFFIX ".so"
| #define HAVE_LIBGCCJIT 1                    
| /* end confdefs.h.  */                                                                       
| #include <libgccjit.h>                                                                       
configure:16610: result: no   
configure:16610: checking for libgccjit.h
configure:16610: result: no
configure:16622: error: ELisp native compiler was requested, but libgccjit header files were
not found.
Please try installing libgccjit-dev or a similar package.
If you are sure you want Emacs be compiled without ELisp native compiler,
pass the --without-native-compilation option to configure.

---

> If it's still failing for you, try building a simple foo.c with just "#include <libgccjit.h>" using 'gcc11 -v' to show where it's looking.

Here is what I find in the output:

#include "..." search starts here:
#include <...> search starts here:
 /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd12.3/11.3.0/include
 /usr/local/include    
 /usr/include         
End of search list.

---

It seems the difference between your build and jrm's and mine is that you are building using GCC while we are using clang.

jrm: Can the emacs ports be switched to use GCC? Or can clang be instructed to search the headers in /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd12.3/11.3.0/include?

Considering that emacs is GNU software, it would probably make sense to have it compile with GCC.
Comment 23 Gerald Pfeifer freebsd_committer freebsd_triage 2022-11-05 00:44:27 UTC
(In reply to Lorenzo Salvadore from comment #22)
> It seems the difference between your build and jrm's and mine is
> that you are building using GCC while we are using clang.

Wow, wow, wow! Are you saying the problem is that clang is used and
should use GCC-specific headers?

I'd declare this NOTABUG, not a supported (and hardly supportable)
use case. (And also looks like only the tip of an iceberg?)
Comment 24 John Hein 2022-11-05 02:19:26 UTC
(In reply to Lorenzo Salvadore from comment #22)
The emacs port already is set to use gcc11 (or later) if the NATIVECOMP option is on:

NATIVECOMP_USE=                 GCC=11+

I don't know why that's not working for you.  But I think the lang/gcc11 patch that I used or the similar one you used are fine.  And whatever is breaking for you is unrelated to this gcc11 change (rather it's because gcc11 is NOT being used).

If you build emacs with the NATIVECOMP option on and cc is used instead of gcc11, then something is broke in your environment or something is broke with the emacs and/or option processing.  Is it possible you have something in make.conf that might be interfering?  Maybe it's specific to some combination of OPTIONS?  Here, the default emacs options + NATIVECOMP is working (gcc11 is used).

The following SHOULD be happening:

% make -C editors/emacs -V CC WITHOUT=NATIVECOMP
cc
% make -C editors/emacs -V CC WITH=NATIVECOMP
gcc11
Comment 25 Joseph Mingrone freebsd_committer freebsd_triage 2022-11-05 03:28:56 UTC
See https://reviews.freebsd.org/D37275.  Initial tests show that everything is fine with the patch referenced in comment #13.  I'll report back tomorrow when gcc finishes building in more jails.
Comment 26 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-05 10:08:12 UTC
> See https://reviews.freebsd.org/D37275.  Initial tests show that everything is fine with the patch referenced in comment #13.  I'll report back tomorrow when gcc finishes building in more jails.

Thanks Joseph. I have also tested my original patch (with the mistake corrected) as it can now be found in https://reviews.freebsd.org/D37266 and this also works, so I think we managed to fix things.

John: I will wait for Joseph's latest result and then commit a patch. Now the question is: should I commit yours or mine?

My point of view is that yours is much better than mine as far as the FreeBSD ports tree is concerned, as it modifies only one file and gets the job done in the easiest way, so it would be much easier to maintain long term. However, it would be nice to upstream the patch quickly enough, so I would not think about it long term. I think mine is more consistent with GCC's style of coding and is probably nearer to what is likely to be the patch upstream, so the GCC developers might prefer to see it committed to the ports tree as this would be a good test for it (from the GCC point of view).

So, I am sorry, but I think I should commit mine. What are your thoughts about it? Do you have some more elements that might make me change my mind? Please mind that I have never contributed to GCC code before, so my considerations about GCC's style of coding might be wrong: if you have experience with it and you are confident your patch would be better suited for the GCC devs, then I will commit your patch instead.
Comment 27 John Hein 2022-11-05 15:47:26 UTC
(In reply to Lorenzo Salvadore from comment #26)
The two patches are very minimally different.  Since this patch will be hopefully temporary (i.e., upstream will commit something), I don't think it matters that much.  For local patches, I tend to favor patches that differ from upstream the least, even if it means something that is not quite a perfect stylistic fit.  But every situation is different.  The important part is to engage upstream (as we have) with useful input, and let them address it.  If they reject the change of the libgccjit*.h location (hopefully not), then we might consider what to do more carefully.

I would probably pick the patch that doesn't require defining a new variable that upstream doesn't have.  But I don't think it matters much.
Comment 28 John Hein 2022-11-05 15:54:48 UTC
(In reply to Joseph Mingrone from comment #25)
Many apologies for my [unintentionlly] misleading comments here... I had COMPLETELY forgotten that I added the NATIVECOMP_USE=GCC=11+ to editors/emacs/Makefile here locally.  Now that I realize this, of course it makes sense that emacs with NATIVECOMP was breaking for others (NATIVECOMP being off by default, so most people had no problems).  I think I meant to submit that editors/emacs change here and that just fell off the plate, so to speak.

Thanks Joseph, for picking up on that and submitting the change for review.
Comment 29 Joseph Mingrone freebsd_committer freebsd_triage 2022-11-06 03:26:57 UTC
(In reply to John Hein from comment #28)

I think there is still a problem.  I'll try to take a closer look tomorrow.

This is a 14-CURRENT poudriere jail.  lang/gcc11 was built with dc67e7d3.

# pkg info -l gcc11 | grep 'jit.*\.h'
  /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd14.0/include/libgccjit++.h
  /usr/local/lib/gcc11/gcc/x86_64-portbld-freebsd14.0/include/libgccjit.h

# make -C /usr/ports/editors/emacs-devel -V CC
gcc11

# make -C /usr/ports/editors/emacs-devel configure
root@14amd64-default:/usr/ports/editors/emacs-devel # make -C /usr/ports/editors/emacs-devel configure
===>   emacs-devel-29.0.50.20221031,2 depends on package: texinfo>=6.5,1 - found
===>   emacs-devel-29.0.50.20221031,2 depends on package: gmake>=4.3 - found
===>   emacs-devel-29.0.50.20221031,2 depends on package: pkgconf>=1.3.0_1 - found
===>   emacs-devel-29.0.50.20221031,2 depends on executable: update-desktop-database - found
===>   emacs-devel-29.0.50.20221031,2 depends on executable: gcc11 - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/bin/as - found
===>   emacs-devel-29.0.50.20221031,2 depends on package: autoconf>=2.71 - found
===>   emacs-devel-29.0.50.20221031,2 depends on package: automake>=1.16.5 - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/ice.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/sm.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/x11.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xcb.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xcomposite.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xext.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xfixes.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xi.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xinerama.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xmu.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xrandr.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xrender.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/libdata/pkgconfig/xt.pc - found
===>   emacs-devel-29.0.50.20221031,2 depends on file: /usr/local/bin/ccache - found
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libgmp.so - found (/usr/local/lib/libgmp.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libgif.so - found (/usr/local/lib/libgif.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libgnutls.so - found (/usr/local/lib/libgnutls.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libfontconfig.so - found (/usr/local/lib/libfontconfig.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libfreetype.so - found (/usr/local/lib/libfreetype.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libharfbuzz.so - found (/usr/local/lib/libharfbuzz.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libjansson.so - found (/usr/local/lib/libjansson.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libpng.so - found (/usr/local/lib/libpng.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libtiff.so - found (/usr/local/lib/libtiff.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libwebp.so - found (/usr/local/lib/libwebp.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libsqlite3.so - found (/usr/local/lib/libsqlite3.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libatk-1.0.so - found (/usr/local/lib/libatk-1.0.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libcairo.so - found (/usr/local/lib/libcairo.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libgdk_pixbuf-2.0.so - found (/usr/local/lib/libgdk_pixbuf-2.0.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libglib-2.0.so - found (/usr/local/lib/libglib-2.0.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libintl.so - found (/usr/local/lib/libintl.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libgtk-3.so - found (/usr/local/lib/libgtk-3.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: librsvg-2.so - found (/usr/local/lib/librsvg-2.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libxml2.so - found (/usr/local/lib/libxml2.so)
===>   emacs-devel-29.0.50.20221031,2 depends on shared library: libpango-1.0.so - found (/usr/local/lib/libpango-1.0.so)
===>  Configuring for emacs-devel-29.0.50.20221031,2
Checking whether you have the necessary tools...
(Read INSTALL.REPO for more details on building Emacs)
Checking for autoconf (need at least version 2.65) ... ok
Your system has the required tools.
Running 'autoreconf -fi -I m4' ...
You can now run './configure'.
configure: loading site script /usr/ports/Templates/config.site
checking for xcrun... no
checking for GNU Make... gmake
checking build system type... amd64-portbld-freebsd14.0
checking host system type... amd64-portbld-freebsd14.0
checking whether the C compiler works... yes
checking for C compiler default output file name... a.out
checking for suffix of executables...
checking whether we are cross compiling... no
checking for suffix of object files... o
checking whether the compiler supports GNU C... yes
checking whether gcc11 accepts -g... yes
checking for gcc11 option to enable C11 features... none needed
checking whether the compiler is clang... no
checking for compiler option needed when checking for declarations... none
checking whether gcc11 and cc understand -c and -o together... yes
checking for stdio.h... (cached) yes
checking for stdlib.h... (cached) yes
checking for string.h... (cached) yes
checking for inttypes.h... (cached) yes
checking for stdint.h... (cached) yes
checking for strings.h... (cached) yes
checking for sys/stat.h... (cached) yes
checking for sys/types.h... (cached) yes
checking for unistd.h... (cached) yes
checking for wchar.h... (cached) yes
checking for minix/config.h... (cached) no
checking for linux/fs.h... no
checking for malloc.h... yes
checking for sys/systeminfo.h... no
checking for sys/sysinfo.h... (cached) no
checking for coff.h... no
checking for pty.h... no
checking for sys/resource.h... (cached) yes
checking for sys/utsname.h... yes
checking for pwd.h... (cached) yes
checking for utmp.h... (cached) no
checking for util.h... no
checking for sanitizer/lsan_interface.h... yes
checking for sys/socket.h... (cached) yes
checking for sys/param.h... (cached) yes
checking for pthread.h... (cached) yes
checking for malloc/malloc.h... no
checking for sys/un.h... (cached) yes
checking for vfork.h... (cached) no
checking for dirent.h... (cached) yes
checking for execinfo.h... yes
checking for stdio_ext.h... no
checking for sys/vfs.h... no
checking for sys/fs_types.h... no
checking for getopt.h... (cached) yes
checking for sys/cdefs.h... (cached) yes
checking for sys/time.h... (cached) yes
checking for ieee754.h... no
checking for limits.h... (cached) yes
checking for sys/select.h... (cached) yes
checking for stdalign.h... yes
checking for stdbool.h... (cached) yes
checking for sys/random.h... yes
checking for stdckdint.h... no
checking whether it is safe to define __EXTENSIONS__... yes
checking whether _XOPEN_SOURCE should be defined... no
checking how to run the C preprocessor... cpp11
checking for grep that handles long lines and -e... (cached) /usr/bin/grep
checking for egrep... (cached) /usr/bin/egrep
checking for Minix Amsterdam compiler... no
checking for ar... /usr/local/bin/ar
checking for special C compiler options needed for large files... no
checking for _FILE_OFFSET_BITS value needed for large files... no
checking whether the compiler is clang... no
checking whether C compiler handles -Werror -Wunknown-warning-option... no
checking for a BSD-compatible install... /usr/bin/install -c
checking command to symlink files in the same directory... ln -s
checking for install-info... /usr/local/bin/install-info
checking for gzip... /usr/bin/gzip
checking for 'find' args to delete a file... -delete
checking for brew... no
checking for -znocombreloc... not needed
checking whether addresses are sanitized... no
checking for math library... -lm
checking pkg-config is at least version 0.9.0... yes
checking for machine/soundcard.h... no
checking for sys/soundcard.h... yes
checking for soundcard.h... no
checking for mmsystem.h... no
checking for ADDR_NO_RANDOMIZE... no
checking for sys/wait.h that is POSIX.1 compatible... (cached) yes
checking for net/if.h... (cached) yes
checking for ifaddrs.h... yes
checking for net/if_dl.h... yes
checking for struct ifreq.ifr_flags... yes
checking for struct ifreq.ifr_hwaddr... no
checking for struct ifreq.ifr_netmask... no
checking for struct ifreq.ifr_broadaddr... yes
checking for struct ifreq.ifr_addr... yes
checking for struct ifreq.ifr_addr.sa_len... yes
checking whether gcc understands -MMD -MF... yes
checking for X... libraries /usr/local/lib, headers /usr/local/include
checking whether malloc is Doug Lea style... no
checking for sbrk... yes
checking for getpagesize... (cached) yes
checking for __lsan_ignore_object... no
checking for fork... (cached) yes
checking for vfork... (cached) yes
checking for fchmod... (cached) yes
checking for canonicalize_file_name... no
checking for faccessat... yes
checking for realpath... (cached) yes
checking for lstat... (cached) yes
checking for readlinkat... (cached) yes
checking for explicit_bzero... yes
checking for memset_s... yes
checking for fchmodat... yes
checking for lchmod... yes
checking for fcntl... (cached) yes
checking for fdopendir... yes
checking for fstatat... (cached) yes
checking for fsync... (cached) yes
checking for futimens... yes
checking for getrandom... yes
checking for gettimeofday... (cached) yes
checking for mkostemp... yes
checking for pipe2... yes
checking for pselect... yes
checking for pthread_sigmask... yes
checking for readlink... (cached) yes
checking for isblank... (cached) yes
checking for iswctype... (cached) yes
checking for strtoimax... yes
checking for symlink... (cached) yes
checking for localtime_r... yes
checking for timegm... yes
checking for utimensat... yes
checking for getdtablesize... (cached) yes
checking for futimes... (cached) yes
checking for futimesat... yes
checking for lutimes... yes
checking for working mmap... (cached) yes
checking for main in -lXbsd... no
checking for pthread library... -lpthread
checking for thread support... yes
checking for Xkb... yes
checking for XkbRefreshKeyboardMapping... yes
checking for XkbFreeNames... yes
checking for XrmSetDatabase... yes
checking for XScreenResourceString... yes
checking for XScreenNumberOfScreen... yes
checking for XDisplayCells... yes
checking for XDestroySubwindows... yes
checking X11 version 6... 6 or newer
checking for XICCallback.callback... yes
checking for librsvg-2.0 >= 2.14.0... yes
checking for libwebpdemux >= 0.6.0... yes
checking for sqlite3_open_v2 in -lsqlite3... yes
checking for sqlite3_load_extension in -lsqlite3... yes
checking for getaddrinfo_a in -lanl... no
checking for gtk+-3.0 >= 3.10 glib-2.0 >= 2.37.5... yes
checking whether GTK compiles... yes
configure: WARNING: Your version of Gtk+ will have problems with
       closing open displays.  This is no problem if you just use
       one display, but if you use more than one and close one of them
       Emacs may crash.
       See https://gitlab.gnome.org/GNOME/gtk/issues/221
checking for malloc_trim... no
checking for gnutls >= 2.12.2... yes
checking for jansson >= 2.7... yes
checking for libkqueue... no
checking for library containing kqueue... none required
checking for XRenderQueryExtension in -lXrender... yes
checking for cairo >= 1.8.0... yes
checking for cairo-xcb >= 1.8.0... yes
checking for freetype2... yes
checking for fontconfig >= 2.2.0... yes
checking for FT_Face_GetCharVariantIndex... yes
checking for harfbuzz >= 0.9.42... yes
checking for X11/Xlib-xcb.h... yes
checking for xcb_translate_coordinates in -lxcb... yes
checking for XGetXCBConnection in -lX11-xcb... yes
checking for xcb_aux_sync in -lxcb-util... no
checking for xcb_aux_sync in -lxcb-aux... no
checking for jpeglib 6b or later... -ljpeg
checking for lcms2... yes
checking for library containing inflateEnd... -lz
checking for dlopen... (cached) yes
checking for dladdr... yes
checking for dlfunc... yes
checking for gcc_jit_context_acquire in -lgccjit... yes
checking for libgccjit.h... no
configure: error: ELisp native compiler was requested, but libgccjit header files were
not found.
Please try installing libgccjit-dev or a similar package.
If you are sure you want Emacs be compiled without ELisp native compiler,
pass the --without-native-compilation option to configure.
===>  Script "configure" failed unexpectedly.
Please report the problem to emacs@FreeBSD.org [maintainer] and attach the
"/wrkdirs/usr/ports/editors/emacs-devel/work-full/emacs-a691e811/config.log"
including the output of the failure of your make command. Also, it might be
a good idea to provide an overview of all packages installed on your system
(e.g. a /usr/local/sbin/pkg-static info -g -Ea).
*** Error code 1

Stop.
make: stopped in /usr/ports/editors/emacs-devel
Comment 30 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-06 08:29:21 UTC
(In reply to Joseph Mingrone from comment #29)

dc67e7d3 contains a mistake indeed: it uses $(gcc_version) instead of $(version) (see also comment #20). Please try applying the patch in https://reviews.freebsd.org/D37266 instead, which is the corrected version.
Comment 31 Joseph Mingrone freebsd_committer freebsd_triage 2022-11-06 14:30:23 UTC
(In reply to Lorenzo Salvadore from comment #30)
The changes in https://reviews.freebsd.org/D37266 look good.  I tested with editors/emacs-devel, which has NATIVECOMP on by default.  Could you let me know when you plan to commit, so I can coordinate?
Comment 32 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-06 15:04:09 UTC
(In reply to Joseph Mingrone from comment #31)

I plan to commit it soon. I can commit it now if you are online or this evening at 22 UTC if you prefer. Also, if it is difficult for us to coordinate, we can have one of us commit both the patches and specify authorship with the --author flag.
Comment 33 Joseph Mingrone freebsd_committer freebsd_triage 2022-11-06 15:07:59 UTC
I'm here now.  Let's do it.
Comment 34 commit-hook freebsd_committer freebsd_triage 2022-11-06 15:16:45 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=0338e04504ee269b7a95e6707f1314bc1c4239fe

commit 0338e04504ee269b7a95e6707f1314bc1c4239fe
Author:     Lorenzo Salvadore <salvadore@FreeBSD.org>
AuthorDate: 2022-11-05 07:55:32 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2022-11-06 15:15:54 +0000

    lang/gcc11: Fix conflict on libgccjit.h and libgccjit++.h again

    This is the second attempt to solve the conflict, see commits
    - dc67e7d3009de2b78d96136c8ad09cf186e553df (first attempt);
    - 9f0cd13014d0962aedfa016c86a5af07ca3ba814 (revert of the first
      attempt).

    GCC 11, GCC 12 and GCC 13 install libgccjit.h and libgccjit++.h in the
    same directory.

    Fix conflict for GCC 11, which is GCC_DEFAULT, by installing those files
    in a directory specific to GCC 11.

    PR:             257060
    Reviewed by:    yasu, jrm
    Differential Revision:  https://reviews.freebsd.org/D37266

 lang/gcc11/Makefile                               |  2 +-
 lang/gcc11/files/patch-gcc_Makefile.in (new)      | 19 +++++++++++++++++++
 lang/gcc11/files/patch-gcc_jit_Make-lang.in (new) | 14 ++++++++++++++
 lang/gcc11/pkg-plist                              |  2 --
 4 files changed, 34 insertions(+), 3 deletions(-)
Comment 35 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-06 15:20:47 UTC
(In reply to Joseph Mingrone from comment #33)

My commit has been done, you can do yours.

I am leaving the bug open to deal with it at least for GCC 12 too, so that we do not get any new issue when we switch GCC_DEFAULT to 12.
Comment 36 commit-hook freebsd_committer freebsd_triage 2022-11-06 15:23:47 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=8882913727d63c2323555bedb6f9c20bd4007ab2

commit 8882913727d63c2323555bedb6f9c20bd4007ab2
Author:     Joseph Mingrone <jrm@FreeBSD.org>
AuthorDate: 2022-11-05 03:01:05 +0000
Commit:     Joseph Mingrone <jrm@FreeBSD.org>
CommitDate: 2022-11-06 15:22:02 +0000

    Emacs ports: Build using GCC when NATIVECOMP is on

    In order to allow concurrent installation, the GCC ports, as of 0338e04,
    moved some header files to internal locations.  Emacs built with
    NATIVECOMP requires GCC jit libraries.  Rather than patching Emacs to
    search in those internal locations, build Emacs with GCC when NATIVECOMP
    is turned on.

    PR:             257060
    Tested by:      jcfyecrayz@liamekaens.com, yasu
    Sponsored by:   The FreeBSD Foundation
    Differential Revision:  https://reviews.freebsd.org/D37275

 editors/emacs-devel/Makefile | 8 ++------
 editors/emacs/Makefile       | 8 ++------
 2 files changed, 4 insertions(+), 12 deletions(-)
Comment 37 Joseph Mingrone freebsd_committer freebsd_triage 2022-11-06 15:26:17 UTC
Thanks all.  Lorenzo, just after committed I realized that accidentally missed you in the 'Tested by:' field of the commit log.  Sorry about that.  You should have been included.
Comment 38 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-06 15:30:38 UTC
(In reply to Joseph Mingrone from comment #37)

Don't worry, it happens, I also forget things sometimes. Indeed, we have three commits on lang/gcc11 instead of one because I had forgotten that I had set DEFAULT_VERSIONS+=gcc=12 in my make.conf, so that, when I tested editors/emacs the first time, I did it with the wrong version of GCC...
Comment 39 commit-hook freebsd_committer freebsd_triage 2022-11-09 13:29:48 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=f1957296ed2dce8a09bb9582e9a5a715bf8b3d4d

commit f1957296ed2dce8a09bb9582e9a5a715bf8b3d4d
Author:     Lorenzo Salvadore <salvadore@FreeBSD.org>
AuthorDate: 2022-11-09 09:05:08 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2022-11-09 13:29:15 +0000

    lang/gcc12: Fix conflict on libgccjit.h and libgccjit++.h

    GCC 11, GCC 12 and GCC 13 install libgccjit.h and libgccjit++.h in the
    same directory.

    Fix conflict for lang/gcc12, which is soon to become GCC_DEFAULT, by
    installing those files in a directory specific to GCC 12.

    See also commit 0338e04504ee269b7a95e6707f1314bc1c4239fe that fixed the
    conflict in the same way for lang/gcc11.

    PR:             257060

 lang/gcc12/Makefile                               |  2 +-
 lang/gcc12/files/patch-gcc_Makefile.in (new)      | 19 +++++++++++++++++++
 lang/gcc12/files/patch-gcc_jit_Make-lang.in (new) | 14 ++++++++++++++
 lang/gcc12/pkg-plist                              |  2 --
 4 files changed, 34 insertions(+), 3 deletions(-)
Comment 40 Lorenzo Salvadore freebsd_committer freebsd_triage 2022-11-09 13:33:52 UTC
Removing block for bug #265948.

The bug still affects the -devel ports, but this should not bother the update of GCC_DEFAULT.

At the moment I do not plan to commit any fix for the -devel ports. I hope that we can manage to have the patch upstreamed in the weekly snapshots and so that such commits will not be needed.
Comment 41 Mark Linimon freebsd_committer freebsd_triage 2024-01-05 03:17:59 UTC
^Triage: committed back in 2022.
Comment 42 commit-hook freebsd_committer freebsd_triage 2024-04-06 19:15:41 UTC
A commit in branch main references this bug:

URL: https://cgit.FreeBSD.org/ports/commit/?id=c43b09081c53651e478e226f77d25562852a8b8b

commit c43b09081c53651e478e226f77d25562852a8b8b
Author:     Trond Endrestøl <Trond.Endrestol@ximalas.info>
AuthorDate: 2024-04-06 12:44:39 +0000
Commit:     Lorenzo Salvadore <salvadore@FreeBSD.org>
CommitDate: 2024-04-06 19:14:53 +0000

    lang/gcc14-devel: Fix conflict on libgccjit.h and libgccjit++.h

    Some GCC ports install libgccjit.h and libgccjit++.h in the
    same directory.

    Fix conflict for lang/gcc14-devel.

    See also commit 0338e04504ee269b7a95e6707f1314bc1c4239fe that fixed the
    conflict in the same way for lang/gcc11.

    PR:             257060, 277383

 lang/gcc14-devel/Makefile                             |  1 +
 lang/gcc14-devel/files/patch-gcc_Makefile.in (new)    | 19 +++++++++++++++++++
 .../files/patch-gcc_jit_Make-lang.in (new)            | 14 ++++++++++++++
 lang/gcc14-devel/pkg-plist                            |  2 --
 4 files changed, 34 insertions(+), 2 deletions(-)