Updated ports tree (MAIN) There is a "tuple.h" in "/usr/include/c++/v1/__fwd" FreeBSD 13.3p1-RELEASE ===> Building for ninja-1.11.1,2 bootstrapping ninja... In file included from ./src/browse.cc:21: In file included from /usr/include/c++/v1/vector:304: In file included from /usr/include/c++/v1/__algorithm/copy.h:12: In file included from /usr/include/c++/v1/__algorithm/copy_move_common.h:14: In file included from /usr/include/c++/v1/__algorithm/unwrap_range.h:19: In file included from /usr/include/c++/v1/__utility/pair.h:17: /usr/include/c++/v1/__fwd/get.h:18:10: fatal error: '__tuple/tuple_element.h' file not found 18 | #include <__tuple/tuple_element.h> | ^~~~~~~~~~~~~~~~~~~~~~~~~ 1 error generated. when running: c++ -MMD -MT build/browse.o -MF build/browse.o.d -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="python3.9"' -O2 -DNDEBUG -fdiagnostics-color -I/usr/local/include -DUSE_PPOLL -DNINJA_HAVE_BROWSE -I. -O2 -pipe -fno-strict-aliasing -c ./src/browse.cc -o build/browse.o Traceback (most recent call last): File "/usr/home/john/FreeBSD/hiawatha/src/devel/ninja/work/ninja-1.11.1/configure.py", line 470, in <module> objs += cxx('browse', order_only=built('browse_py.h')) File "/usr/home/john/FreeBSD/hiawatha/src/devel/ninja/work/ninja-1.11.1/configure.py", line 287, in cxx return n.build(built(name + objext), 'cxx', src(name + '.cc'), **kwargs) File "/usr/home/john/FreeBSD/hiawatha/src/devel/ninja/work/ninja-1.11.1/configure.py", line 169, in build self._run_command(self._expand(cmd, local_vars)) File "/usr/home/john/FreeBSD/hiawatha/src/devel/ninja/work/ninja-1.11.1/configure.py", line 194, in _run_command subprocess.check_call(cmdline, shell=True) File "/usr/local/lib/python3.9/subprocess.py", line 373, in check_call raise CalledProcessError(retcode, cmd) subprocess.CalledProcessError: Command 'c++ -MMD -MT build/browse.o -MF build/browse.o.d -Wall -Wextra -Wno-deprecated -Wno-missing-field-initializers -Wno-unused-parameter -fno-rtti -fno-exceptions -fvisibility=hidden -pipe '-DNINJA_PYTHON="python3.9"' -O2 -DNDEBUG -fdiagnostics-color -I/usr/local/include -DUSE_PPOLL -DNINJA_HAVE_BROWSE -I. -O2 -pipe -fno-strict-aliasing -c ./src/browse.cc -o build/browse.o' returned non-zero exit status 1. *** Error code 1
Moin moin A bit more context would be helpful :) mfg Tobias
This occurred when building hiawatha with default options. I'm kind of new to bug reporting, so I am happy to provide any other details as requested.
(In reply to John Darrah from comment #2) Moin moin Are you by chance not building in a clean environment (poudriere) and have devel/re2c installed? mfg Tobias
(In reply to Tobias C. Berner from comment #3) That is correct - not building with Poudriere. I have a machine I can install Poudriere on and try it that way. Does this need to happen? Rec2 is not installed.
(In reply to John Darrah from comment #4) Ok, then my first guess about re2c was not correct -- could you provide a full configure run output of the build. I think it picks something up from the environment that it should not. mfg Tboias
(In reply to Tobias C. Berner from comment #5) I appreciate your help with this.... ===> The following configuration options are available for hiawatha-11.5_1: CACHE=on: Caching support CGIWRAPPER=on: Install cgi-wrapper(1) (needs setuid bit) LEFH=off: Install Let's Encrypt For Hiawatha script LOADCHECK=on: Load check support (experimental) MONITOR=off: Hiawatha Monitor support RPROXY=on: Reverse proxy support TOMAHAWK=off: Tomahawk command shell support TOOLKIT=on: URL toolkit support XSLT=on: XSLT support ===> Use 'make config' to modify these settings Again, I am happy to try and build in Poudriere if you think it would help? John
(In reply to John Darrah from comment #6) Moin moin I meant the output of the port during its build phase :) Could you provide the full buildlog of make (after having run make clean) mfg Tobias
Created attachment 250024 [details] hiawatha fails at ninja
(In reply to John Darrah from comment #0) > There is a "tuple.h" in "/usr/include/c++/v1/__fwd" > FreeBSD 13.3p1-RELEASE That's not the same thing, but that file should still be there. > /usr/include/c++/v1/__fwd/get.h:18:10: fatal error: '__tuple/tuple_element.h' > file not found On FreeBSD 13.3, /usr/include/c++/v1/__tuple is directory containing several files including "tuple_element.h" [1] whereas on 13.2, /usr/include/c++/v1/__tuple is a single file. [2] I suspect your libcxx installation may have been corrupted when you upgraded from 13.2 to 13.3. [1] https://cgit.freebsd.org/src/tree/contrib/llvm-project/libcxx/include/__tuple?h=releng/13.3 [2] https://cgit.freebsd.org/src/tree/contrib/llvm-project/libcxx/include/__tuple?h=releng/13.2
See also: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=273661
(In reply to Jason E. Hale from comment #9) I appreciate the insight and I will research accordingly.
just adding a data point here, I experienced a similar problem resulting from a bad freebsd-update from somewhere around the time of 12.x -> 13.3 I think. My fix was to manually repopulate the partially broken headers on my system like so: # Assuming you are using /bin/sh as your FreeBSD root shell and # you are now on 14.1 # I think this was a bad update because a file changed to a directory or vice-versa in clang at some point root# mkdir /usr/include/c++/v1/__tuple # if it doesn't exist root# cd /usr/include/c++/v1/__tuple root# for i in make_tuple_types.h pair_like.h tuple_element.h tuple_indices.h tuple_like.h tuple_like_ext.h tuple_size.h tuple_types.h sfinae_helpers.h; do fetch https://raw.githubusercontent.com/freebsd/freebsd-src/release/14.1.0/contrib/llvm-project/libcxx/include/__tuple/${i} ; done and my __string/ include directory was similarly broken: root# mkdir /usr/include/c++/v1/__string root# cd /usr/include/c++/v1/__string root# for i in char_traits.h constexpr_c_functions.h extern_template_lists.h; do fetch https://raw.githubusercontent.com/freebsd/freebsd-src/release/14.1.0/contrib/llvm-project/libcxx/include/__string/${i} ; done I was then able to build a new release of FreeBSD from source and the re-install of the OS during a buildworld worked again for me. Worked for me, your mileage may vary, make a backup etc ...
I'm closing this since this is ultimately a problem with upgrading the c++ headers in base and not with the devel/ninja port, specifically. OP also hasn't responded in 6 months to report whether the situation has improved.