# Version of llvm compilor framework in FreeBSD 13 and for the ports are not identical



## HL1234 (May 21, 2021)

FreeBSD 13.0 uses now llvm-11.0.1.

In /usr/ports/Mk/bsd.default-versions.mk is defined

```
#Possible values: 70, 80, 90, 10, 11, -devel (to be used when non-base compiler is required)
LLVM_DEFAULT?=90
```
That's the version llvm-9.0..

So installing from the ports, where some ports LLVM needed, will install and compile llvm-9.0.1, because it is set as default and not using the higher llvm-11.0.1 form the OS. I discover that, as I compiled the mysql-server80 from the ports. It takes the whole day and after that I saw 700 Mb more compiled for the llvm compiler. I have now defined in /etc/make.conf llvm default as the same version like the OS is set to avoid that an deinstall llvm-9.0.1..

Is there a wrong default setting in bsd.default-versions.mk?

(I have nor forget to make an fresh port tree, with `#portsnap fetch extract`, after upgrade to FreeBSD 13)


----------



## richardtoohey2 (May 21, 2021)

I know MySQL 5.7 won't build with llvm 11, so I know if you try and build MySQL 5.7 (don't know about 8.0) then the ports will build llvm 9 and use that to build MySQL 5.7.

But haven't seen the behaviour (pulling down llvm 9) outside of building MySQL.


----------



## richardtoohey2 (May 21, 2021)

See: https://svnweb.freebsd.org/ports/head/databases/mysql57-server/Makefile?r1=542151&r2=546322


----------



## HL1234 (May 22, 2021)

richardtoohey2 said:


> I know MySQL 5.7 won't build with llvm 11, so I know if you try and build MySQL 5.7 (don't know about 8.0) then the ports will build llvm 9 and use that to build MySQL 5.7.
> 
> But haven't seen the behaviour (pulling down llvm 9) outside of building MySQL.


Ok thanks, I look now at the default for MySQL and it is MYSQL_DEFAULT?= 5.7. I used version 8.0 since a year so I forgot that. Then, if there are still default port which use llvm 9, it must be also the default. To solve that I have set llvm to version 11 in the /etc/make.conf file with

```
DEFAULT_VERSIONS+=llvm=11
```
 (2021) Until yet that works.
Thanks for you answer


----------



## astyle (May 22, 2021)

Only the clang part of llvm11 is even included in the base of FreeBSD 13-RELEASE. It is enough to recompile the kernel, and get the rest of llvm11 parts, but clang is not the complete llvm. BTW, I'm compiling Firefox 88 at time of this post, and it's pulling in llvm12... I know that just llvm will take a couple hours to build with my Ryzen 5 1400. And this is normal - when I was compiling x11/plasma5-plasma-desktop, I had llvm 9 and 10 pulled in.


----------



## astyle (May 24, 2021)

BTW, it looks like databses/mysql57 has been marked as broken - too many security vulnerability reports filed against that version of MySQL. Some ports come with a MySQL dependency option - I'd suggest not turning that option on at all, just proceed without it. It's probably not impossible to compile stuff against a newer version of MySQL, but you gotta keep your eyes peeled and be prepared to spend some time learning from your own mistakes and reading lots of documentation.


----------



## richardtoohey2 (May 24, 2021)

Where are you seeing it marked as broken?






						FreshPorts -- databases/mysql57-server: Multithreaded SQL database (server)
					

MySQL is a very fast, multi-threaded, multi-user and robust SQL (Structured Query Language) database server.




					www.freshports.org
				




It's marked as vulnerable because of the outstanding patches, but I've not seen it's broken?


----------



## astyle (May 24, 2021)

Right, in this case I was just going off my memory from the day before, and not really taking notes as I go. Sometimes, the ports system will just refuse to compile a port that has been marked as vulnerable. In my case, the ports system refused to compile a a dependency (yes, mysql57 in this case) because of the security vulnerabilities. I had to turn that one off to continue. I did have to `# rm -rf work`, `# make config`, remove the offending dependency, and then `make && make install`. Removing the work folder is essential for proper re-compiling.


----------



## Alain De Vos (May 24, 2021)

I've added to make.conf

```
DEFAULT_VERSIONS+=llvm=11
```


----------



## richardtoohey2 (May 24, 2021)

astyle said:


> Right, in this case I was just going off my memory from the day before, and not really taking notes as I go. Sometimes, the ports system will just refuse to compile a port that has been marked as vulnerable.


Phew, I know I have to get to MySQL 8.x but only just migrated to 5.7 from 5.6 so not ready for the migration just yet.

Doing the patching looks miserable because of all the non-security-related changes, so I can understand why it's an easy job to put off.


----------



## astyle (May 24, 2021)

richardtoohey2 said:


> Phew, I know I have to get to MySQL 8.x but only just migrated to 5.7 from 5.6 so not ready for the migration just yet.


Not impossible to run 2 versions of MySQL side-by-side. I have Python 2.7 (thanks to KDE), Python 3.7, and Python 3.8 on my system. Generally, when you compile something against MySQL, the makefile will offer options to use other options, like sqlite. I'd recommend using Sqlite rather than MySQL when you gotta specify a database dependency. Most apps that do need a database back-end (like Akonadi) will do just fine with a databases/sqlite back-end.


----------

