Solved FreeBSD 13.3-RELEASE LLVM and clang updated to 17.0.6

VladiBG

VladiBG

I'm a bit confused.
In FreeBSD 13.3-RELEASE LLVM and clang were updated to 17.0.6 but the ports are still default to version of LLVM 15.
/usr/ports/Mk/bsd.default-versions.mk
 
Ports pull in LLVM (in most cases) for its libraries, not for the compiler. As long as a port doesn't explicitly specify otherwise, it will be built with the base compiler anyways.

llvm libraries are a moving target, ports really needing them (like, e.g., mesa for its "llvmpipe" software rendering) will need a specific version. This has absolutely nothing to do with the base compiler version. And as always, ports are completely independent from base anyways.
 
So making ports default clang 17 would be ahead of FreeBSD 14’s base compiler.

So I was wondering if that was a factor but as Zirias said the two versions (clang in base versus ports) are unrelated.
 
Hi, I've got problems exactly with that. I have poudriere* and port tree that is frozen in time for while now. After moving from F13.2 -> F13.3 some stuff is no longer possible to compile. Adding llvm=14 to make.conf for some reason doesn't fix anything.
Code: 
DEFAULT_VERSIONS+= pgsql=14 ... gcc=9 qt=5 llvm=14

Any help, how to force llvm version?

p.s.

*the word 'poudriere' is unpronouncable! i hate the person who chose the name. have to copy it every time.
 
My ports compiled just fine under FreeBSD 13.3 i just observe that there are still using LLVM15 that's why i was questioning myself if i miss something. But i'm using PostgreSQL 15 and not like you 14.
 
Again, a dependency on llvm (so, pulling in an llvm port) is rarely done for the compiler, if ever. It's for libllvm and friends, using llvm's infrastructure to build own "code transformation" stuff, just like mesa is doing with "llvmpipe" for software rendering.

So no, crypt47, your issue is almost certainly NOT related here. Your ports will be built with the base compiler, and yes, that's a newer version in 13.3 than it was in 13.2. Please open your own thread, explain your problem in detail (including compilation errors you get and your whole configuration, e.g. the whole make.conf). First question would be, why use a "frozen" ports tree at all, and why pin so many non-default "default versions"? That's very likely the source of your issues.
 
zirias@ said:
Please open your own thread, explain your problem in detail (including compilation errors you get and your whole configuration, e.g. the whole make.conf). First question would be, why use a "frozen" ports tree at all, and why pin so many non-default "default versions"? That's very likely the source of your issues.
Click to expand...
Ok, a new topic it is then. As for your question it's pretty simple. It is because I want a stable system for the whole FreeBSD release cycle. I don't want to deal with all kinds of library migrations you, developers, like to deal with. I just want my system to setup once and be that way for a while. See nothing bad about this. That is why we have a stable ABI (in base). But linker errors after upgrade make it useless.
 
crypt47 said:
I don't want to deal with all kinds of library migrations you, developers, like to deal with.
Click to expand...
First, you have to work on your attitude.

And then, there's "quarterly" in ports for those who want as little change as possible. Just not ever updating ports means even fewer change, sure, but is a very stupid idea as well, you will just collect vulnerabilities. For base, there are SAs and corresponding patch releases -- a similar thing can't be done for third party software out of control of the project, so, upgrade is, at some point in time, the only sensible thing to do.
 
zirias@ said:
First, you have to work on your attitude.

And then, there's "quarterly" in ports for those who want as little change as possible. Just not ever updating ports means even fewer change, sure, but is a very stupid idea as well, you will just collect vulnerabilities. For base, there are SAs and corresponding patch releases -- a similar thing can't be done for third party software out of control of the project, so, upgrade is, at some point in time, the only sensible thing to do.
Click to expand...
If you want proper attitude, then have respect for others first. I'm not asking to lecturing me really. And I don't know who you are to call my ideas stupid. If the compiler would be able to not messed up the old code and just recompile the software, there would be no problem in the first place.
 
VladiBG said:
My ports compiled just fine under FreeBSD 13.3 i just observe that there are still using LLVM15 that's why i was questioning myself if i miss something. But i'm using PostgreSQL 15 and not like you 14.
Click to expand...
It's not about postgres really. Are you able to build llvm 14 for example? Generally something is wrong with linking

forums.freebsd.org

FreeBSD 13.3-RELEASE LLVM gives errors where F13.2 didn't

Hi, I have poudriere and port tree that is frozen in time for while now. That is done because I want a stable system without breakage till EOL. After moving from F13.2 -> F13.3 some stuff is no longer possible to compile. Linker errors apparently. Adding llvm=14 to DEFAULT_VERSIONS+= in...
forums.freebsd.org forums.freebsd.org
 
VladiBG said:
I'm using the default version of the LLVM which currently is 15.
Click to expand...
For some reason my outdated port tree uses base version.
Code: 
===>  Configuring for rhash-1.4.3
Checking for target OS ... FreeBSD
Checking for cc version ... clang 17.0.6
I don't know why.
 
The easy fix is to remove your make.conf and rebuild everything with it's default version. You will need to migrate your pgsql db
 
VladiBG said:
The easy fix is to remove your make.conf and rebuild everything with it's default version. You will need to migrate your pgsql db
Click to expand...
Please, forget about pgsql, it's not an issue) The problem as I described it in my own post is with the linker. Even with clean make.conf it uses LLVM 17 and gives

Code: 
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrBuildNodeList' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrEvalRangePredicate' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrFreeLocationSet' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrLocationSetAdd' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrLocationSetCreate' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrLocationSetDel' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrLocationSetMerge' failed: symbol not defined
ld: error: version script assignment of 'LIBXML2_2.4.30' to symbol 'xmlXPtrLocationSetRemove' failed: symbol not defined

Code: 
--- librhash/librhash.so.0 ---
ld: error: version script assignment of 'global' to symbol 'rhash_wfile' failed: symbol not defined
cc: error: linker command failed with exit code 1 (use -v to see invocation)
*** [librhash.so.0] Error code 1

and this kind of error on some packages but not the other.
 
releng-13.3, stable-13, stable-14 and -current has all been updated to llvm-17.0.6. releng-14.0 is still on 16. 13.2 is on 14.

I find this strange. Surely FreeBSD's concept of a top-level release doesn't cover a major compiler update like that. Especially if it means a jump from 14 to 17 during a minor version bump.

I personally found problems with 17 which I didn't have time to verify yet.
 
security/rhash is building fine on 13.3 with all default settings. If you want i can provide you a log file.

According your error you are using old version of LIBXML2. The current is libxml2-2.11.7. You need to remove your old build deps first and upgrade all ports.
 
VladiBG said:
security/rhash is building fine on 13.3 with all default settings. If you want i can provide you a log file.

According your error you are using old version of LIBXML2. The current is libxml2-2.11.7. You need to remove your old build deps first and upgrade all ports.
Click to expand...
I absolutely believe you can build the new port. My point is that the new compiler (llvm 17) shouldn't break what was working. Or the minor system update (we are talking about something stable here, right?) shouldn't introduce such drastic change. I really don't see, why I as a user should just drop everything and go for major library changes because of the new developer's stuff in stable (!) base that can't handle what was working a half year before. It's kinda twisted logic to me.

Seems like this bug report explains this kind of things.

The new linker is more strict.

May be it can be relaxed with options?
 
cracauer@ said:
I find this strange. Surely FreeBSD's concept of a top-level release doesn't cover a major compiler update like that. Especially if it means a jump from 14 to 17 during a minor version bump.
Click to expand...
It's strange, yes, but I'd say it doesn't violate the stable ABI 🤷‍♂️

What's really causing lots of issues (I fixed a few of them in ports myself) is the latest tendency in llvm/clang to add very strict rules, even rejecting stuff that would be fine (although ugly and smelly) according to language standards. Most of that can be disabled sprinkling some -Wno-error=<foo>, but it's still annoying.

But then, ports will get tested and fixed. They're rolling release, you're supposed to keep them updated and if you want fewer updates, quarterly is for you ... anything else just isn't supported. :rolleyes:
 
I don't disagree and now see more of the benefits of having llvm 17 in all releases, given that all use the same ports tree.

But it also violates the principle of least surprise to have llvm17 pop up in a 13.x release earlier than a 14.x release.

The linker change might still be a step too far.
 
It's pretty easy to fix such errors for programmers, but takes time for others. I was given advice to add LDFLAGS and now it's not working with building llvm15 itself. Apparently cmake doesn't respect this flag. I have no clue why. Non-programmer user shouldn't dig into that every minor-release.

As for @zirias "rolling release" point it's just incompetent. I'm telling this as a person who supported software repositories for organizations on paid basis. I strongly disagree. You should sometimes tough a grass and see how others use your code. Telling that everybody should upgrade just because is abusive. It's really up to user to decide. We aren't Microsoft, are we? From my experience you can't justify immediate upgrade from security perspective. Also new updates not just fix bugs, but introduce a new ones, that is even worse in case of production. Not that I'm actually using FreeBSD this way. Quarterly is good, but maybe too fast paced in some cases.
 
You must log in or register to reply here.
Back
Top