This simple program can't be compiled on 14.1: #include <csetjmp> int main() { } $ c++ x.cpp In file included from x.cpp:2: /usr/include/c++/v1/csetjmp:40:6: error: "If libc++ starts defining <setjmp.h>, the __has_include check should move to libc++'s <setjmp.h>" 40 | # error "If libc++ starts defining <setjmp.h>, the __has_include check should move to libc++'s <setjmp.h>" | ^ 1 error generated. The error message doesn't explain what is wrong with the program. The C++ standard says that <csetjmp> should be included for the C++ feature std::jmp_buf. See here: https://en.cppreference.com/w/cpp/utility/program/jmp_buf
I can't reproduce this on freshly installed 14.1-RELEASE. The program compiles just fine. How have you installed your system?
I had a similar issue recently on CURRENT. In my case the cause was that I had built base from sources forgetting to run "make delete-old". After running it everything was fixed.
(In reply to Lorenzo Salvadore from comment #2) Ah yes, this is because the old copy of /usr/include/c++/v1/setjmp.h must be deleted upon an upgrade. A fresh install will never have this issue.
*** Bug 281257 has been marked as a duplicate of this bug. ***
Thanks, deleting the above mentioned file appears to fix everything related to csetjmp please add this info to UPDATING regarding setjmp.h and csetjmp also there are two setjmp.h files in "/usr/include/c++/v1" - shouldn't BOTH be deleted? (/usr/include/c++/v1/tr1/setjmp.h is a symlink to /usr/include/c++/v1/setjmp.h) NOTE: in some cases, like a massive ports upgrade, using "make delete-old" might not be desirable until after many ports have already been re-built. I did not use 'portupgrade' but it could very likely break something (so I do this step last). But this is a nit as long as UPDATING covers the topic, I'd think.
(In reply to Bob Frazier from comment #5) $ grep setjmp.h ObsoleteFiles.inc OLD_FILES+=usr/include/c++/v1/setjmp.h OLD_FILES+=usr/include/c++/v1/tr1/setjmp.h Both of these are in ObsoleteFiles.inc, the latter has been there for quite a long time, since the tr1 directory was cleaned up. Everybody should run make delete-old after upgrading, this is the only supported mechanism. Adding notes to UPDATING might work, but if people don't follow instructions then it might not make much difference. :)
(In reply to Bob Frazier from comment #5) QUOTE NOTE: in some cases, like a massive ports upgrade, using "make delete-old" might not be desirable until after many ports have already been re-built. END QUOTE Avoiding running "make delete-old" leads to the risk of silently finding and using out-of-date content in some of the upgrade's build activity. Such can make it harder to discover that there are problems to fix to be sure that the right content is used. "make delete-old-libs" is somewhat different for the criteria relative to keeping programs that do not yet have updated installs operational (still using old .so files and such). "make delete-old-libs" is appropriate after the upgrades to versions that use the newer .so libraries are in use instead.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=157802238b5aa7722aff40317fe6d05f5c975d71 commit 157802238b5aa7722aff40317fe6d05f5c975d71 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2024-09-05 19:58:51 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days UPDATING | 7 +++++++ 1 file changed, 7 insertions(+)
A commit in branch stable/14 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=28ff3ab2ab064224cd1fc0885040c3c47ed5ef4d commit 28ff3ab2ab064224cd1fc0885040c3c47ed5ef4d Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2024-09-08 07:48:57 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days (cherry picked from commit 157802238b5aa7722aff40317fe6d05f5c975d71) UPDATING | 7 +++++++ 1 file changed, 7 insertions(+)
A commit in branch stable/13 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=6b147f693b91f16db7ba6193611f6f4d2ed762a5 commit 6b147f693b91f16db7ba6193611f6f4d2ed762a5 Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2024-09-08 07:51:37 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days (cherry picked from commit 157802238b5aa7722aff40317fe6d05f5c975d71) UPDATING | 7 +++++++ 1 file changed, 7 insertions(+)
A commit in branch releng/13.4 references this bug: URL: https://cgit.FreeBSD.org/src/commit/?id=5096328dd7cbe79628098f10ab92eb4ab70d5fce commit 5096328dd7cbe79628098f10ab92eb4ab70d5fce Author: Dimitry Andric <dim@FreeBSD.org> AuthorDate: 2024-09-05 19:55:44 +0000 Commit: Dimitry Andric <dim@FreeBSD.org> CommitDate: 2024-09-09 17:49:39 +0000 Add UPDATING note about running make delete-old after libc++ 18 upgrade PR: 279692 MFC after: 3 days (cherry picked from commit 157802238b5aa7722aff40317fe6d05f5c975d71) (cherry picked from commit 6b147f693b91f16db7ba6193611f6f4d2ed762a5) Approved by: re (cperciva) UPDATING | 7 +++++++ 1 file changed, 7 insertions(+)
I get a similar error when installing the libheif port. How can I fix it? My system FreeBSD 14.1-RELEASE-p5 amd64 root@test_site:/usr/ports/graphics/libheif # make MAKE_JOBS_UNSAFE=yes install clean ===> Building for libheif-1.18.2 [ 6% 1/15] /usr/bin/c++ -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DENABLE_PLUGIN_LOADING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_FFMPEG_DECODER=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X265=1 -DLIBHEIF_EXPORTS -Dheif_EXPORTS -I/usr/ports/graphics/libheif/work/.build -I/usr/ports/graphics/libheif/work/libheif-1.18.2/libheif -I/usr/ports/graphics/libheif/work/libheif-1.18.2/libheif/api -I/usr/ports/graphics/libheif/work/libheif-1.18.2/include/libheif -I/usr/ports/graphics/libheif/work/libheif-1.18.2/include -I/usr/local/include/webp -O2 -pipe -march=nocona -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -march=nocona -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -DNDEBUG -std=c++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o -MF libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o.d -o libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o -c /usr/ports/graphics/libheif/work/libheif-1.18.2/libheif/plugins/encoder_jpeg.cc FAILED: libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o /usr/bin/c++ -DENABLE_MULTITHREADING_SUPPORT=1 -DENABLE_PARALLEL_TILE_DECODING=1 -DENABLE_PLUGIN_LOADING=1 -DHAVE_AOM_DECODER=1 -DHAVE_AOM_ENCODER=1 -DHAVE_FFMPEG_DECODER=1 -DHAVE_JPEG_DECODER=1 -DHAVE_JPEG_ENCODER=1 -DHAVE_LIBSHARPYUV=1 -DHAVE_UNISTD_H -DHAVE_VISIBILITY -DHAVE_X265=1 -DLIBHEIF_EXPORTS -Dheif_EXPORTS -I/usr/ports/graphics/libheif/work/.build -I/usr/ports/graphics/libheif/work/libheif-1.18.2/libheif -I/usr/ports/graphics/libheif/work/libheif-1.18.2/libheif/api -I/usr/ports/graphics/libheif/work/libheif-1.18.2/include/libheif -I/usr/ports/graphics/libheif/work/libheif-1.18.2/include -I/usr/local/include/webp -O2 -pipe -march=nocona -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -O2 -pipe -march=nocona -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -isystem /usr/local/include -DNDEBUG -std=c++11 -fPIC -fvisibility=hidden -fvisibility-inlines-hidden -Wall -Wsign-compare -Wconversion -Wno-sign-conversion -Wno-error=conversion -Wno-error=unused-parameter -Wno-error=deprecated-declarations -Wno-error=tautological-compare -Wno-error=tautological-constant-out-of-range-compare -Wno-error=potentially-evaluated-expression -MD -MT libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o -MF libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o.d -o libheif/CMakeFiles/heif.dir/plugins/encoder_jpeg.cc.o -c /usr/ports/graphics/libheif/work/libheif-1.18.2/libheif/plugins/encoder_jpeg.cc In file included from /usr/ports/graphics/libheif/work/libheif-1.18.2/libheif/plugins/encoder_jpeg.cc:30: /usr/include/c++/v1/csetjmp:40:6: error: "If libc++ starts defining <setjmp.h>, the __has_include check should move to libc++'s <setjmp.h>" 40 | # error "If libc++ starts defining <setjmp.h>, the __has_include check should move to libc++'s <setjmp.h>" | ^ 1 error generated. ninja: build stopped: subcommand failed. *** Error code 1 Stop. make[1]: stopped in /usr/ports/graphics/libheif *** Error code 1 Stop. make: stopped in /usr/ports/graphics/libheif
(In reply to bagas from comment #12) Run make delete-old from /usr/src.
(In reply to Dimitry Andric from comment #13) > Run make delete-old from /usr/src. Of course I did this after updating the system. I always do this after updating the system. # yes | make delete-old # yes | make delete-old-libs
(In reply to bagas from comment #14) I'm sorry, but I cannot provide a better explanation or workaround. I would suggest a fresh installation.
*** Bug 282178 has been marked as a duplicate of this bug. ***
(In reply to Dimitry Andric from comment #15) root@test_site:~ # cd /usr/src/ root@test_site:/usr/src # yes | make delete-old >>> Removing old files (only deletes safe to delete libs) >>> Old files removed >>> Removing old directories >>> Old directories removed To remove old libraries run 'make delete-old-libs'. root@test_site:/usr/src # yes | make delete-old-libs >>> Removing old libraries Please be sure no application still uses those libraries, else you can not start such an application. Consult UPDATING for more information regarding how to cope with the removal/revision bump of a specific library. >>> Old libraries removed root@test_site:/usr/src # Previously the system version was 14.0, updated to 14.1. Updates went without errors as always,. At the end of the update I cleaned (make delete-old/make delete-old-libs) and then rebooted the server. > __has_include check should move to libc++'s <setjmp.h>" > 40 | # error "If libc++ starts defining <setjmp.h>, the __has_include check should move to libc++'s <setjmp.h>" This error is on the vps server which is in jail. After updating the system and rebooting the server I did ezjail-admin update -i and started the vps server.
Had to abandon libheif. Rebuilt ImageMagick without libheif.
For any other people running into this issue, try deleting the following files manually (backing them up if you are paranoid): /usr/include/c++/v1/limits.h /usr/include/c++/v1/setjmp.h This should solve the problem. You can also delete these files manually from a poudriere jail, if necessary.
(In reply to Dimitry Andric from comment #19) Thanks, I'll try.
(In reply to Dimitry Andric from comment #19) Perhaps this is really a bug that's related to jail management ports then? They should make sure stale files/libs are removed from the jails as well.
(In reply to Bob Frazier from comment #21) I'm unsure of all the tools people are using, so I cannot answer that question. If you would use make installworld to upgrade a jail, then you would also have to run etcupdate and make delete-old in it. And I guess a similar thing applies to jails upgraded with freebsd-update. As far as I know, freebsd-update also does equivalent steps, but directly with etcupdate or make delete-old.
How to clean jail? I use after each system update, jail environment update ezjail-admin update -i. but this is apparently not enough.
(In reply to bagas from comment #23) I don't know anything about ezjail, but it looks like a bug to me if the tool doesn't run the equivalents of "etcupdate" and "make delete-old" after a jail upgrade.
In instructions for ezjail-admin update. -i As above but only perform a “make installworld”, assuming the world has already been built. That is highly likely since it is recommended to update the basejail along with the host system.
host system # ls -l /usr/include/c++/v1/{setjmp.h,limits.h} ls: /usr/include/c++/v1/limits.h: No such file or directory ls: /usr/include/c++/v1/setjmp.h: No such file or directory jail (vps server) # ls -l /usr/include/c++/v1/{setjmp.h,limits.h} -r--r--r-- 1 root wheel 1627 Oct 5 09:55 /usr/include/c++/v1/limits.h -r--r--r-- 1 root wheel 847 Oct 5 09:55 /usr/include/c++/v1/setjmp.h # ls -l /usr/ | grep include lrwxr-xr-x 1 root wheel 21 Jan 13 2024 include -> /basejail/usr/include