Problem with binary upgrade 13.2-13.3

ogogon

ogogon

Colleagues, after the binary upgrade 13.2-13.3 ( freebsd-update -r 13.3-RELEASE upgrade), I have a problem that causes the C++ compiler to refuse to start.
During the upgrade process, after rebooting and restarting freebsd-update, the following messages appear on the console:
Code: 
root@smarthome:/home/ogogon # /usr/sbin/freebsd-update install
Creating snapshot of existing boot environment... done.
Installing updates...install: ///usr/include/c++/v1/__string exists but is not a directory
install: ///usr/include/c++/v1/__tuple exists but is not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__string exists but is not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple exists but is not a directory
install: ///usr/include/c++/v1/__string/char_traits.h: Not a directory
install: ///usr/include/c++/v1/__string/constexpr_c_functions.h: Not a directory
install: ///usr/include/c++/v1/__string/extern_template_lists.h: Not a directory
install: ///usr/include/c++/v1/__tuple/make_tuple_types.h: Not a directory
install: ///usr/include/c++/v1/__tuple/pair_like.h: Not a directory
install: ///usr/include/c++/v1/__tuple/sfinae_helpers.h: Not a directory
install: ///usr/include/c++/v1/__tuple/tuple_element.h: Not a directory
install: ///usr/include/c++/v1/__tuple/tuple_indices.h: Not a directory
install: ///usr/include/c++/v1/__tuple/tuple_like.h: Not a directory
install: ///usr/include/c++/v1/__tuple/tuple_like_ext.h: Not a directory
install: ///usr/include/c++/v1/__tuple/tuple_size.h: Not a directory
install: ///usr/include/c++/v1/__tuple/tuple_types.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__string/char_traits.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__string/constexpr_c_functions.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__string/extern_template_lists.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/make_tuple_types.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/pair_like.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/sfinae_helpers.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_element.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_indices.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_like.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_like_ext.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_size.h: Not a directory
install: ///usr/src/contrib/llvm-project/libcxx/include/__tuple/tuple_types.h: Not a directory

I believe that this means some kind of disorder in the operation of the scripts. Obviously, the developers of the binary upgrade system should adjust something in them.

Subsequently, after the completion of the binary upgrade, during compilation, an abnormal termination occurs:
Code: 
===>  Building for ninja-1.11.1,4
/usr/ports/devel/ninja/work/ninja-1.11.1/configure.py:26: DeprecationWarning: 'pipes' is deprecated and slated for removal in Python 3.13
  import pipes
bootstrapping ninja...
"./src/inline.sh" kBrowsePy < ./src/browse.py > build/browse_py.h
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.11"' -O2 -DNDEBUG -fdiagnostics-color -I/usr/local/include -DUSE_PPOLL -DNINJA_HAVE_BROWSE -I. -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -O2 -pipe -fstack-protector-strong -fno-strict-aliasing   -c ./src/browse.cc -o build/browse.o
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.11"' -O2 -DNDEBUG -fdiagnostics-color -I/usr/local/include -DUSE_PPOLL -DNINJA_HAVE_BROWSE -I. -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -O2 -pipe -fstack-protector-strong -fno-strict-aliasing   -c ./src/browse.cc -o build/browse.o
Traceback (most recent call last):
  File "/usr/ports/devel/ninja/work/ninja-1.11.1/configure.py", line 470, in <module>
    objs += cxx('browse', order_only=built('browse_py.h'))
            ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/ports/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/ports/devel/ninja/work/ninja-1.11.1/configure.py", line 169, in build
    self._run_command(self._expand(cmd, local_vars))
  File "/usr/ports/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.11/subprocess.py", line 413, 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.11"' -O2 -DNDEBUG -fdiagnostics-color -I/usr/local/include -DUSE_PPOLL -DNINJA_HAVE_BROWSE -I. -O2 -pipe  -fstack-protector-strong -fno-strict-aliasing  -O2 -pipe -fstack-protector-strong -fno-strict-aliasing   -c ./src/browse.cc -o build/browse.o' returned non-zero exit status 1.
*** Error code 1

Stop.
make[14]: stopped in /usr/ports/devel/ninja
*** Error code 1

This happened on two computers. How can I solve this problem?

Thanks in advance for your advice,
Ogogon.
 
Last edited by a moderator:
I got maybe the first one or two lines of output, but not all the rest.

So looks like something you've done on both your two machines upsets freebsd-update.

Do you have those directories or files it didn't like? Can you rename them or try and make freebsd-update happier?
 
T-Daemon said:
First hit in web search of usr/include/c++/v1/__string exists but is not a directory:

Bug 273661 - freebsd-update install: ///usr/include/c++/v1/__string exists but is not a directory

Status of bug is "Fixed", but apparently still needs manual intervention, see comment 31
Click to expand...
Obviously, I don't have such directories. There are files with similar names, but without two underscores at the beginning of the name.
Code: 
ogogon@gw:/usr/include/c++/v1# ls -alg __string __tuple
ls: __string: No such file or directory
ls: __tuple: No such file or directory
ogogon@gw:/usr/include/c++/v1# ls -alg string tuple
-r--r--r--  1 root  wheel  194899  3 jul  01:21 string
-r--r--r--  1 root  wheel   76740  3 jul  01:21 tuple
ogogon@gw:/usr/include/c++/v1#
How was I supposed to know that I needed to create these directories?
Why weren’t they created by the upgrade script?!

T-Daemon said:
/usr/src can be re-populated otherwise, extract distribution tarball, then run freebsd-update again, git.
Click to expand...
How is it re-populated otherwise?
Where can I get a distribution tarball and what kind?
What does git mean in this case?

I am very grateful for your recommendations, but I would be even more grateful if they were specific and understandable. (Since I’m asking questions like this here, it’s already clear that I’ve never done this before.)
 
ogogon said:
Why weren’t they created by the upgrade script?!
Click to expand...
There was a bug in the upgrade script - if you read the link T-Daemon sent.

That link also has a comment 31 that explains a possible workaround for the bug and subsequent issues that may be encountered.

If you didn't upgrade 13.2 itself before the upgrade to 13.3 you may have had more issues with the upgrade.
 
richardtoohey2 said:
There was a bug in the upgrade script - if you read the link T-Daemon sent.

That link also has a comment 31 that explains a possible workaround for the bug and subsequent issues that may be encountered.

If you didn't upgrade 13.2 itself before the upgrade to 13.3 you may have had more issues with the upgrade.
Click to expand...
Thank you. I acted in accordance with comment 31 and C++ worked. But besides him, LLVM was still dissatisfied.
Should I also replace his /usr/src/contrib/llvm-project/libcxx/include/ directory from src.txz?
 
What is the error you are getting? I don't know the answer to your question, but there might be some clues in the output/error messages that will indicate things that you could try.
 
ogogon said:
I am very grateful for your recommendations, but I would be even more grateful if they were specific and understandable. (Since I’m asking questions like this here, it’s already clear that I’ve never done this before.)
Click to expand...
Sometimes it's not that obvious which degree of experience a forums user has on FreeBSD. Here on forums there are users between with no familiarity about the system at all to very skilled users, private / professional programmers, coders, system administrators, FreeBSD developers.

I had the impression that you were a seasoned FreeBSD user and what I wrote makes sense to you (you joined forums earlier than me in 2011).

ogogon said:
How is it re-populated otherwise?
Where can I get a distribution tarball and what kind?
What does git mean in this case?
Click to expand...
The FreeBSD source tree is maintained by Git, it means, /usr/src can be re-populated (after deleting the content) by using Git to fetch the source code with one of the packages available on FreeBSD:

devel/git ( it comes in 3 flavors, package names: git, git-lite, git-tiny )
devel/gitup
devel/got

Git is the preferred method to fetch, update source files, well documented in the handbook chapter 26.6.3. Updating the Source (and optaining the source).

Another method, not that known and not documented (as far I can tell), is to extract the distribution tarball (or distribution set, src.txz) and run freebsd-update to update (see Components src in /etc/freebsd-update.conf). You have apparently already found out where to get src.txz. Make sure that src.txz is from the same version as the installed system.

Probably you have installed the source files during installation of the system from distribution tarball, choosing that installation option.

ogogon said:
Should I also replace his /usr/src/contrib/llvm-project/libcxx/include/ directory from src.txz?
Click to expand...

Don't bother copying/replacing files extracted from src.txz into current /usr/src, just empty /usr/src and re-populete with one of the mentioned methods.

Even without knowing about distribution tarballs, Git, it's very easy to find an answer to all questions you asked web searching.

For example, it took me 5 seconds to find the bug report with information for the solution to the freebsd-update error.
 
You must log in or register to reply here.
Back
Top