Solved How to completely replace LLVM16 by LLVM15 on FreeBSD14 Current?

F

FabricioGuzzy

Hello folks,
I got a situation where I need to compile FreeBSD 14 Current from an old source (from 3 to 5 months ago) but I am getting multiple errors related to the last changes involving CLANG/LLVM16, like the explanation below:

Clang 16 introduced a warning that "implicit truncation from 'int' to a
one-bit wide bit-field changes value from 1 to -1".

LLVM15 has no issues with it. Knowing that, I am trying to override the native LLVM16 by LLVM15 with no success.
I tried modifying the /etc/make.conf like below:
Code: 
CC=/usr/local/llvm15/bin/clang-15
CXX=/usr/local/llvm15/bin/clang++
CPP=/usr/local/llvm15/bin/clang-cpp
DEFAULT_VERSIONS+=llvm=15

I also tried to change the PATH env, pointing to /usr/local/llvm15/bin before the default /usr/bin:/usr/sbin:/bin and etc.
When I do that, the compilation process starts complaining about missing headers and include files.
What I am missing here? Any help is very welcome!!!

Thanks!!!
Fabricio.
 
forums.freebsd.org

Topics about unsupported FreeBSD versions

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking...
forums.freebsd.org forums.freebsd.org
 
SirDice said:
forums.freebsd.org

Topics about unsupported FreeBSD versions

The FreeBSD Forums cater primarily to end-users and systems administrators. As such, the Forums focus almost exclusively on FreeBSD versions that are officially supported according to the official FreeBSD website. Since resources are scarce, the FreeBSD Forums strongly suggest that anyone asking...
forums.freebsd.org forums.freebsd.org
Click to expand...
With all my respect...
I could easily change the question to: How to completely change LLVM/Clang version from 16 to 15? , not explaining the reasons why and people would never know that I am trying to work with a code from 4 months ago. (I have reasons for that)
At least I am being honest explaining the reasons I need such change.
Anyway, If I can't request information about FreeBSD at the FreeBSD forum, then what?
 
You can actually ask here. It's not a solid rule about that particular question. The rule is saying that, not many people will have an answer for you on here. People can continue to help you and you can ask questions about it.

You can get better help on the mailing lists. Current is really for experts, and those who can figure out things on their own or with the mailing list. Also, you'd have to be apt to filing bug reports, and finding/sharing solutions on the appropriate mailing list.

I've messed with installing versions of LLVM/Clang in the past on supported FreeBSD releases. The base install of LLVM/Clang was replaced before, but I couldn't rebuild my base after a few times, because the tools needed were in that toolchain and each build dropped a few more needed tools. Thread is-it-possible-to-buildworld-without-base-compilers-to-use-package-compilers.59874 is one past attempt. Other times, after things have changed enough, I couldn't repeat doing this. This process isn't recommended and not needed.

You're trying to go down a version, so why not use FreeBSD Stable or the latest supported version? Did you install devel/llvm15 through ports. You tried to tell make.conf to use that.

You might find examples here: Thread share-your-make-conf-and-src-conf.63544.

There's an argument applicable to the base system, and one for ports inside make.conf.

You're doing something that requires more expertise than the forums are for and requires more technical ability on that.
 
sidetone said:
You can actually ask here. It's not a solid rule about that particular question. The rule is saying that, not many people will have an answer for you on here. People can continue to help you and you can ask questions about it.

You can get better help on the mailing lists. Current is really for experts, and those who can figure out things on their own or with the mailing list. Also, you'd have to be apt to filing bug reports, and finding/sharing solutions on the appropriate mailing list.

I've messed with installing versions of LLVM/Clang in the past on supported FreeBSD releases. The base install of LLVM/Clang was replaced before, but I couldn't rebuild my base after a few times, because the tools needed were in that toolchain. Thread is-it-possible-to-buildworld-without-base-compilers-to-use-package-compilers.59874 is one past attempt. Other times, after things have changed enough, I couldn't repeat doing this. This process isn't recommended and not needed.

You're trying to go down a version, so why not use FreeBSD Stable or the latest supported version? Did you install devel/llvm15 through ports. You tried to tell make.conf to use that.

You might find examples here: Thread share-your-make-conf-and-src-conf.63544.

There's an argument applicable to the base system, and one for ports in make.conf.

You're doing something that requires more expertise than the forums are for and requires more technical ability on that.
Click to expand...
Thanks Much for you attention on this matter. I just read your post about it. Really useful by the way.
I may try the other changes you made on the make.conf file.
Yes, I have installed llvm15 from ports and added the entries to make.conf to match the files. (it requires the full path, just like you explained on your post), but for some reason, poudriere jail and make buildworld are still using the llvm16.
That´s when I tried to override things in the /bin /usr/bin/ and others. I got a VM snapshot before the changes, in case I messed the entire OS. After changed the /bin compilers, (changed the PATH env) I started getting erros related to include files, just like ShelLuser described as well on your post. Even having the include files, the compiling process cannot find it. Not sure where it is looking for.
I may try the other changes you did. Maybe it works. (maybe not)
I will let you know after all.
Thanks once again for you help. I truly appreciate it.
 
FabricioGuzzy said:
but for some reason, poudriere jail and make buildworld are still using the llvm16.
Click to expand...
You have to set it there too. Either in the Poudriere configuration file, or another make.conf in a Poudriere directory. I'm not familar with Poudiere use. Jails typically have their own replicas of common files. I believe Poudriere is for building ports, if you got the idea about replacing base system components.

You're working on an experimental system, and you'll learn from it, so don't expect that to be a production system. Also, don't remove the base compilers and toolchain components, even if parts of it may be used anyway, than the one in ports. Maybe on a new install, you'll keep everything in base as it is, and only install and configure it for use with llvm/clang from ports.


The problem I have with CURRENT and I forgot if it applies to STABLE, is I can't update the base system with a simple command. That's why I prefer production releases, not for same reason many others don't recommend CURRENT. The only part I would need to rebuild is the kernel.


Also, check out, devel/xtoolchain-llvm-devel which I believe installs little more than a file with instructions on cross compiling. Even if that's not applicable, there's something to learn from it.
 
I Tried everything suggested. It is always the same error.
After all, I got the following:

wmmintrin.h not found
emmintrin.h not found

Those files ARE there in the include folders (more than one)
but the process can't find it. I have copied the files to different folder like:
/usr/lib/clang/
usr/include/
usr/local/include
nothing seems to fix it.

I have exhausted my options.
 
RESOLVED!!!! :)
yuripv79 said:
So it looks like another "XY problem" thread.

If it's a warning (that gets promoted to error by -Werror), try specifying WITHOUT_WERROR in src.conf(5).
Click to expand...
yuripv79 - Was right. -Werror flag resolved my problem. I was just NOT using it the right way.

The correct syntax was:
Code: 
make -j 24 KERNCONF=MYKERNEL WERROR=-Wno-bitfield-constant-conversion buildkernel

The "WERROR=-Wno-bitfield-constant-conversion" did the trick. No need to downgrade the llvm/clang version.
it silenced the warning (now error) messages and I could build the kernel successfully.
Thanks everyone who helped me on this matter. I really appreciate it.
 
You can put some arguments from the command make into make.conf, so they don't have to be spelled out each time. Definitely for KERNCONF. Not sure if you can put the WERROR argument there, also.

Code: 
KERNCONF= MYKERNEL
 
sidetone said:
You can put some arguments from the command make into make.conf, so they don't have to be spelled out each time. Definitely for KERNCONF. Not sure if you can put the WERROR argument there, also.

I am using a custom shell script, so, that´s OK - I just added it to the script.
Click to expand...
 
You must log in or register to reply here.
Back
Top