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.
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. :)
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 ?
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?)
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.
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.
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.
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.
(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.
> 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.
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(-)
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.
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.
(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.
(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?
(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.
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.
(emacs' config.log might provide more information)
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 . .
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.
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(-)
(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.
(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.
(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?)
(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
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.
> 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.
(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.
(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.
(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
(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.
(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?
(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.
I'm here now. Let's do it.
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(-)
(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.
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(-)
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.
(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...
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(-)
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.
^Triage: committed back in 2022.
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(-)