Solved Can't compile anything anymore since upgrade

Hello everyone,

I'm writing you out of despair, because I've recently upgraded an old server which was hosting my emails.
It was an old server under FreeBSD 10.2 (it was already quite fragile) and I upgraded to 14.2. Process went fine, but when I tried to upgrade my ports with portmaster, I ran into several issues.
I fixed some, but I feel like I'm stuck on this one :


root@vendome:/usr/include # portmaster devel/cmake
[...]
Error when bootstrapping CMake:
Cannot find a C++ compiler that supports both C++11 and the specified C++ flags.
Please specify one using environment variable CXX.
The C++ flags are "-O2 -pipe -I/usr/include -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -D__BSD_VISIBLE -isystem /usr/local/include ".
They can be changed using the environment variable CXXFLAGS.
See cmake_bootstrap.log for compilers attempted.
---------------------------------------------
Log of errors: /usr/ports/devel/cmake-core/work/.build/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------
===> Script "configure" failed unexpectedly.
Please report the problem to kde@FreeBSD.org [maintainer] and attach the
"/usr/ports/devel/cmake-core/work/.build/Bootstrap.cmk/cmake_bootstrap.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


I've looked on that forum to find some help, and verified the upgrade process was terminated :

root@vendome:/usr/include # freebsd-version -kru
14.2-RELEASE
14.2-RELEASE
14.2-RELEASE


Seems fine.
I'm lost where to look here, if anyone could help because few ports can upgrade through portmaster, but most of them don't (apache won't, cyrus-imap won't either...).

Thanks,

--
Léo.
 
Look in /usr/ports/devel/cmake-core/work/.build/Bootstrap.cmk/cmake_bootstrap.log

Most likely you need to clean out old files, namely C++ headers.
 
Y'know, when an upgrade jump is that large (10.2-RELEASE to 14.2-RELEASE), it makes more sense to just install things from scratch, rather than risk messing things up on the existing setup.

The ports system is also not meant to handle such large jumps, either, especially with the dependency hell that is just as bad as on Linux.

A better upgrade strategy would be 'Reproduce the functionality, but don't mess up existing production setups'. I have successful experience moving email from a SCO UNIX server to a 6.2-RELEASE machine. Productivity in the office was not disrupted, thanks to very careful planning of that move, and being able to go back from any step if things don't work out. Yes, planning an upgrade is something that requires a lot of attention and thinking things through, completely.

Being unable to compile is just a symptom of a much larger issue. Especially with KDE, it makes more sense to just start with a fresh copy of the ports tree and compile everything from scratch.That's just my take, though.
 
It'll be fine. The problem with stale C++ includes is well known.
It's far simpler and less time-consuming to do things from ground up and carefully choreograph the switch, step-by-step, than to hunt down and correct errors that arise from dependency hell, especially if you dive blindly into it like OP did.

After all, the UNIX philosophy is Keep It Simple, Stupid...

And, stale C++ includes are not the only issue in the dependency hell to pay attention to...
 
It's far simpler and less time-consuming to do things from ground up and carefully choreograph the switch, step-by-step, than to hunt down and correct errors that arise from dependency hell, especially if you dive blindly into it like OP did.

After all, the UNIX philosophy is Keep It Simple, Stupid...

My philosophy is to diagnose and solve problems instead of rebooting or reinstalling, so that you learned something and so that you can easily recover next time.

This problem doesn't have to do with dependencies. setjmp in C++ is broken if you don't remove the stale headers.
 
My philosophy is to diagnose and solve problems instead of rebooting or reinstalling, so that you learned something and so that you can easily recover next time.

This problem doesn't have to do with dependencies. setjmp in C++ is broken if you don't remove the stale headers.
OP needs email back up and functioning. They don't have the time for diagnostics and learning.

And yes, this is a dependency hell issue. There's tons of things that do depend on having a functional devel/cmake... Paying attention to just one port/component does absolutely nothing when the whole system is in trouble. What do you think should be done when cmake can't find the correct files next? repeat the process of diagnostics?
 
It's the C++ compiler that is broken.

If the OP ever looks up the error in the logfile that the error points him/her to that is a 30 second fix.

(*) of course Cmake shouldn't hide the error in the first place.
 
It's the C++ compiler that is broken.

If the OP ever looks up the error in the logfile that the error points him/her to that is a 30 second fix.

(*) of course Cmake shouldn't hide the error in the first place.
Knowing where to look when things go wrong, and knowing how to fix them is a talent that takes time to hone and develop. Do you seriously think OP has time or talent? People with time on their hands and enough talent - they can do something that would probably never occur to the rest of us, and do that easily.

Yeah, the C++ compiler is broken. But digging out every error it throws is not something that OP has the time for, they just want email server back up and functioning ASAP... OP is not the TempleOS guy with immense talent to fix a software error just like that. OP needs a solution like make clean (instead of cd /usr/ports/category/port/work; rm -rf my_stale_header_[a-h\\*$ 0-9].h ). Awesome skills and deep learning about the issue are too much for OP at this time.

This is like telling someone that they should learn to change their own tires, oh, and to use a top-end brand - while that person is stranded by the roadside and late for an important appointment.
 
Knowing where to look when things go wrong, and knowing how to fix them is a talent that takes time to hone and develop.

Yes, and the hone and develop can happen right now. Otherwise it never happens.

OP is in good hands. The error message, while not printed, is hinted at, and (unless I am mistaken) the problem is well known. The fix is way faster than a reinstall.
 
Yes, and the hone and develop can happen right now. Otherwise it never happens.

OP is in good hands. The error message, while not printed, is hinted at, and (unless I am mistaken) the problem is well known. The fix is way faster than a reinstall.
One quick fix deep inside won't solve all the errors, it won't magically give OP a functioning email server with KDE. And those 'quick fixes' really add up when you have to do one after another, with no end in sight.

Sometimes it's easier and faster to just start with a clean slate. Once the clean slate is done, then sure, do a post-mortem analysis, play and learn. Just like my tire-changing example. Sure, the person just might go sign up for a class, and learn all about tires and how to change them - but that would be the last thing on the mind of someone stranded by the roadside... :rolleyes:
 
Hello again everyone,

astyle You're absolutely right, I shouldn't have tried to upgrade with such a large gap and I've learned my lesson for next time. I will definitely manage things differently from now on. BUT, before upgrading I searched that forum and saw that it shouldn't be a problem, because the upgrade system was smart enough to manage this gap (people from 9.0 RELEASE to 12.0 RELEASE had great results for example). So I moved on, but never again :)
Now that's done, I'm trying to recover things, and I already ordered a new VPS with a fresh 14.2 RELEASE install waiting to welcome the new system. But first, I need to get the email server back online and that's why I posted here.

cracauer@ Thanks for your reply. I'm willing to learn things, definitely :) But I must confess that looking at the logfile didn't help me so much, especially with my level of expertise in that area. I tried to have a look but it's hard (for me) to identify the reason. I know it's a big ask, but could you have a look and guide me how to fix ?
I've put the logfile here : https://cloud.lapousterle.fr/s/DMxXKYFfCb968Gr

Thanks a lot.

--
Léo.
 
Try `make delete-old` in /usr/src

It isn't quite what I had in mind in the logfile, but we'll see.

How did you update, from source or freebsd-update?
 
Thanks a lot :)
I did update with
freebsd-update upgrade -r 14.2-RELEASE

Here's the output after your message.

root@vendome:/usr/src # make delete-old
>>> Removing old files (only deletes safe to delete libs)
remove /etc/host.conf? n
remove /etc/opiekeys? n
>>> Old files removed
>>> Removing old directories
rmdir: /var/db/portsnap: Directory not empty
>>> Old directories removed
To remove old libraries run 'make delete-old-libs'.


Then :

root@vendome:/usr/src # cd /usr/ports/devel/cmake-core/
root@vendome:/usr/ports/devel/cmake-core # make install
===> cmake-core-3.31.2 depends on shared library: libexpat.so - found (/usr/local/lib/libexpat.so)
===> cmake-core-3.31.2 depends on shared library: libidn2.so - found (/usr/local/lib/libidn2.so)
===> cmake-core-3.31.2 depends on shared library: libjsoncpp.so - found (/usr/local/lib/libjsoncpp.so)
===> cmake-core-3.31.2 depends on shared library: libpkg.so - found (/usr/local/lib/libpkg.so)
===> cmake-core-3.31.2 depends on shared library: librhash.so - found (/usr/local/lib/librhash.so)
===> cmake-core-3.31.2 depends on shared library: libuv.so - found (/usr/local/lib/libuv.so)
===> Configuring for cmake-core-3.31.2
---------------------------------------------
Source directory: /usr/ports/devel/cmake-core/work/cmake-3.31.2
Binary directory: /usr/ports/devel/cmake-core/work/.build
Prefix directory: /usr/local
System: FreeBSD
Generator: Unix Makefiles
Doing parallel make: 1

---------------------------------------------
CMake 3.31.2, Copyright 2000-2024 Kitware, Inc. and Contributors
C compiler on this system is: cc -O2 -pipe -I/usr/include -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing
---------------------------------------------
Error when bootstrapping CMake:
Cannot find a C++ compiler that supports both C++11 and the specified C++ flags.
Please specify one using environment variable CXX.
The C++ flags are "-O2 -pipe -I/usr/include -fstack-protector-strong -isystem /usr/local/include -fno-strict-aliasing -D__BSD_VISIBLE -isystem /usr/local/include ".
They can be changed using the environment variable CXXFLAGS.
See cmake_bootstrap.log for compilers attempted.
---------------------------------------------
Log of errors: /usr/ports/devel/cmake-core/work/.build/Bootstrap.cmk/cmake_bootstrap.log
---------------------------------------------
===> Script "configure" failed unexpectedly.
Please report the problem to kde@FreeBSD.org [maintainer] and attach the
"/usr/ports/devel/cmake-core/work/.build/Bootstrap.cmk/cmake_bootstrap.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[1]: stopped in /usr/ports/devel/cmake-core
*** Error code 1

Stop.
make: stopped in /usr/ports/devel/cmake-core
 
OK, I downloaded base.txz and uncompressed it, then move the extracted one to replace :

mv /usr/include /usr/include.old/
cp /home/me/new/usr/include /usr/include


Then did same steps :

root@vendome:/usr/src # cd /usr/ports/devel/cmake-core/
root@vendome:/usr/ports/devel/cmake-core # make install


Seems like it did the trick and cmake-core is building OK, thanks a lot sir.
I'm now trying to portmaster a port like apache24 to validate the whole process is OK.
 
Allrighty :)

Apache is not using C++, so it wouldn't be affected.
I had no idea!

But even so, I would not want to set up Apache or anything on a system where an upgrade was botched this bad. I'm not a fan of sifting through a train wreck and salvaging stuff, especially when I need a working train so that I can get somewhere. When learning is in fact the priority, rather than getting somewhere, then sure, I'll cooperate on sifting through a train wreck, and even have some fun doing that.
 
cracauer@ Ah... If portmaster apache24 runs OK, I'll try with another "big" one :)

astyle I'm not a fan either, that's why I ordered and installed a new VPS server with a fresh FreeBSD 14.2 on it. But I need the "old" server back online just for having cyrus-imapd up and running and transfer all emails via imapsync.

Charlie_ Very insightful, and probably my issue was related to that. As soon as portmaster let me, i'll run the command you gave me :)
 
Charlie_ Here is the output I get.


root@vendome:/usr/ports/devel/cmake-core # freebsd-update IDS
Looking up update.FreeBSD.org mirrors... 3 mirrors found.
Fetching metadata signature for 14.2-RELEASE from update2.freebsd.org... done.
Fetching metadata index... done.
Inspecting system... done.
/.cshrc has SHA256 hash 8b3f74dd170b2fad6be3c5b18cf89af83bcd597fb65b3e92721036293b6aa6b3, but should have SHA256 hash d1ba75d6e942aa2f17eb84061fe4edda1d17b9a9ab8e4e2ce3a19e650403b5d7.
/etc/group has SHA256 hash 4d99f5aef2f8f5ee31860908b3d9c829368e8badaceda488b8e26d7d855e4b6c, but should have SHA256 hash a76791033e18dcb526c30a6417bdb31ef774649f84e7f4ca0e745549cb15729c.
/etc/hosts has SHA256 hash f9e2a950945c9009910b87eb53cb79f27d35d897f2c67e7e6b215ebacbd58732, but should have SHA256 hash 336de0d20e14a6e526e147580ef5b0a7167a4ff4ebd788222d71e4c238e7ab2e.
/etc/mail/aliases has SHA256 hash 17bf1606f59f8a38a12271548fef52c80ca8a4d452efe2bc483bad3e659de128, but should have SHA256 hash f98a9312846abdb5095b1162100fa8d56ba665beb3779239aee94a6c8d44a88f.
/etc/master.passwd has SHA256 hash bc29abb316e1e4499565ef34c9de4d5cca6b70058d4f11d404b3c75cf7228520, but should have SHA256 hash 55dfb5a41ebad44523b26cba443d94c3d55e0b39a32558f81a1d50fed964ec34.
/etc/passwd has SHA256 hash f97dcc844ab9a648243143077efa026683b3fafddbc22aca0dbcc5419613c040, but should have SHA256 hash 57d2a756f16439eb2bc13af8d4b0a958ccec88643c6246cfc00e5b0894417eec.
/etc/pwd.db has SHA256 hash 2ed6b3a722cdcb721b494ebc280e435c57891472991e65231761247ef7968038, but should have SHA256 hash bd30e09f6e06e4430bbb8fa20c4ed46babaec585d5580a92244c6a4227c5af56.
/etc/shells has SHA256 hash d46a6a8d81650ef3cb8b0a63f4b8cdd6ed681dfa14aa3690a9308a13097ada56, but should have SHA256 hash d4f435c3c24679f19609fcf0e78c473c85582cd0300ebcc0ac3088c34408cde4.
/etc/spwd.db has SHA256 hash a8320b37f6c0335ae11cb19a8751cb136325a6c620f368cad8e7b2aa5d3c31a6, but should have SHA256 hash 5b8454a1d288eef2ed215f2280ac5cf9e9197ac1d2a1e46a67ba38c2c0c370e7.
/etc/sysctl.conf has SHA256 hash 24abb80d5a672222a041fbb2cf786e1973b13100b7e93aa97b6dd8d3987f1e2c, but should have SHA256 hash 45f469e7a9b4eef887bab7b55397305043fe101e1d6ce6f7e23d758e72f56dc6.
/etc/ttys has SHA256 hash 7e3b5425f0f4a76101c6dc4003efb681b2857f94f8ed53f1f61898b3015a35c3, but should have SHA256 hash 233bbde35fce584ed8655483e5aa3f6f43978d27fa3fb3e55b6898f48eae7aea.
/root/.cshrc has SHA256 hash 8b3f74dd170b2fad6be3c5b18cf89af83bcd597fb65b3e92721036293b6aa6b3, but should have SHA256 hash d1ba75d6e942aa2f17eb84061fe4edda1d17b9a9ab8e4e2ce3a19e650403b5d7.
/usr/src/contrib/bc/tests/bc/misc6.txt is a symlink, but should be a regular file.
/usr/src/contrib/bc/tests/bc/misc6_results.txt is a symlink, but should be a regular file.
/usr/src/sys/contrib/openzfs/cmd/arc_summary is a directory, but should be a regular file.
/usr/src/sys/contrib/openzfs/cmd/zvol_wait is a directory, but should be a regular file.
/var/account has 0755 permissions, but should have 0750 permissions.


cracauer@ I now launch portmaster on postfix / amavisd / spamassassin.
 
cracauer@ I reinstalled many ports without any problems. My mailserver is now completely functional again. But I'll move data on another fresh install soon to avoid more problems. Plus, I'm hesitating between continuing to self host these or sign up for a managed service to avoid long term nervous moments like this one. Anyway thanks a lot for helping me here.

Charlie_ and USerID : I confess I don't understand what I should do here.
The output of cat outfile.ids | awk '{ print $1 }' | more is :

root@vendome:/home/gorby # cat outfile.ids | awk '{ print $1 }' | more
Looking
Fetching
Fetching
Inspecting
/.cshrc
/etc/group
/etc/hosts
/etc/mail/aliases
/etc/master.passwd
/etc/passwd
/etc/pwd.db
/etc/shells
/etc/spwd.db
/etc/sysctl.conf
/etc/ttys
/root/.cshrc
/usr/src/contrib/bc/tests/bc/misc6.txt
/usr/src/contrib/bc/tests/bc/misc6_results.txt
/usr/src/sys/contrib/openzfs/cmd/arc_summary
/usr/src/sys/contrib/openzfs/cmd/zvol_wait
/var/account
 
Back
Top