# [Guide(ish)] What do you have working with clang?



## falkman (Jul 27, 2011)

The idea of this thread, post what you have working under FreeBSD+clang and perhaps any hacks you had to do to get there. If anything, this will be a good thread to go to if you are having issues with something built by clang and you could ask (politely) of the poster to tell you how they got a program to work with clang.

Check out my active pastebin:
http://pastebin.com/u/falkclang

What I have working with clang (and how I did it):

First of all, how I got world, the kernel, and a release working:

I pulled the 201105-amd64-dvd1 iso from the CURRENT builds, and installed that (I just installed base, kern, src, and lib32).

I created _/etc/make.conf_ with the the following contents:


```
.if !defined(CC) || ${CC} == "cc"
CC=clang
.endif
.if !defined(CXX) || ${CXX} == "c++"
CXX=clang++
.endif
.if !defined(CPP) || ${CPP} == "cpp"
CPP=clang-cpp
.endif

NO_WERROR=
WERROR=
NO_FSCHG=

CPUTYPE?=native
```

(Somewhat modified _/etc/make.conf_ from http://wiki.freebsd.org/BuildingFreeBSDWithClang)

Then I got ports with:

```
portsnap fetch
```
Then extracted it with:

```
portsnap extract
```

Then installed the _devel/subversion-freebsd_ port (`make install clean`)

I then made a working directory and changed into it.

```
mkdir /freebsd-9.0-native-clang
```


```
cd /freebsd-9.0-native-clang
```

Then you have to check out the source


```
svn co http://svn.freebsd.org/base/head src
```


```
cd src
```

Now it's time to build!

Build the world:

```
make buildworld
```
Build the kernel (GENERIC in this case):

```
make buildkernel
```
And make a release:

```
cd release/
```


```
make release
```

Now you can grab the iso from _/usr/obj/root/freebsd-9.0-native-clang/src/release/release.iso_ (from memory, may be wrong, but it's close enough).

Now you plop that iso on a CD like any other iso and install 9.0-native-clang.

I happen to install with ONLY base, kern, and src for my main builds (I do a full world build for i386 in a chroot).

From here I edited _/etc/make.conf_ and put the same contents from above, fetched and extracted ports like above, and started building ports.

Summary/list of ports:


```
world, kernel, and release from r224402
www/firefox                 5.0
[INDENT]This fails due to some @rel assembly issues, to fix this error edit work/mozilla-release/js/src/ctypes/libffi/src/x86/unix64.S

At line 357 change '.long .LUW0@rel' to '.long .LUW0-.'
At line 399 change '.long .LUW5@rel' to '.long .LUW5-.'
(Note the #if HAVE_AS_X86_PCREL that does this for us, but for some reason that define is not set thus it takes the wrong code)

After this, firefox compiled fine as normal
[/INDENT]

editors/vim                 7.3.121
shells/bash                 4.1-010
x11/xorg                    1.7.7
x11/gtk-theme-switch2       2.0.0rc2
x11-themes/gtk-engines2     2.20.2
x11/nvidia-driver           275.21
[INDENT]I built the x11/nvidia-driver first then built the 275.21 driver from
online after having multiple issues with the x11/nvidia-driver. You have to
comment out the line in the source that throws an #error if you're using FreeBSD 9[/INDENT]
irc/irssi                   0.8.15
emulators/linux_base-f10
www/nspluginwrapper         1.4.4
www/linux-f10-flashplugin10 10.3r181.34

Inside i386 chroot (r224402 buildworld and installworld with clang)
emulators/wine              1.3.25
[INDENT]When installing wine, dlls/msvcrt and dlls/ntdll both have issues with clang,
I simply modified the Makefiles for these and built ONLY these 2 dlls with gcc.
I'll work on a 'proper' fix later, but this allows it to build and install.[/INDENT]
x11/nvidia-driver           275.21
[INDENT]Same as above, but I only did `make depend` then installed the latest
driver.[/INDENT]
Probably some others that I'm forgetting...
```

Note: Feel free to ask about ANYTHING I have said here, the whole point of this thread is to tell other clang users what I have done, so if they need help they can ask me.
(Hopefully others contribute to this thread to make a reliable page for others to get help from)

I'll be working on a wiki page for this or putting it in http://wiki.freebsd.org/PortsAndClang, but I don't want that page to become too clobbered.

-Brandon Falk


----------



## xibo (Jul 27, 2011)

I had less success when trying to build world on CURRENT with Clang-2.8-xxyyzz in April. If the mentioned to fail ports are built with gcc, will they work with the otherwise clang environment?

Also, multimedia/vlc does compile but not run when built with clang-devel from ports on 8-STABLE.


----------



## falkman (Jul 27, 2011)

xibo said:
			
		

> I had less success when trying to build world on CURRENT with Clang-2.8-xxyyzz in April. If the mentioned to fail ports are built with gcc, will they work with the otherwise clang environment?
> 
> Also, multimedia/vlc does compile but not run when built with clang-devel from ports on 8-STABLE.



Yeh, there should be no issues with using gcc on things that clang fails on. I've done it a few times myself. I'll try to look into your vlc issue later on. What's the error output that you get?


----------



## dkeav (Aug 9, 2011)

devel/icu which usually builds with clang is not currently building with latest release, a look at google groups for chromium team has them submitting some upstream patches to fix this though, so i would expect it to be fixed in upstream on next release.

i'm currently rebuilding the packages on my package sandbox with clang to see what is broken.


----------



## dkeav (Aug 9, 2011)

Also bison compiled with clang will cause bash to fail to build when *bison -y -d* is ran, throwing a sig 10.  Bison with gcc works fine though.


----------



## xibo (Aug 16, 2011)

falkman said:
			
		

> I'll try to look into your vlc issue later on. What's the error output that you get?



SIGSEGV 
Also, there is no Qt-GUI when having compiled vlc with clang.

Another two that don't work are
(1) FreeBSD-9 with CPUTYPE set to westmere
(2) www/squid31 though I guess it's even worse in older versions.

Workaround for (2) would be replacing all occurences of _class_ in the squid code by _struct_ since the squid developers are mixing those two in the declarations of their datastructures.


----------



## falkman (Aug 17, 2011)

We have noticed quite a few issues with linking with CPUTYPE set, I'm not quite sure if this has been fixed yet. Most of the issues we had were with '-m32' (if not all, I can't remember).

I'm not sure about squid, but I've been too busy to work with FreeBSD. I'll try to check it out later.


----------



## alie (Feb 1, 2012)

```
[/usr/home/alie/fbsd/src/release]# make release KERNCONF=EZYCLIE
`release' is up to date.
```

Is there any way to remove the release? Or re-release?


----------



## falkman (Feb 13, 2012)

What do you mean exactly?


----------



## alie (Mar 30, 2012)

falkman said:
			
		

> What do you mean exactly?



I would like to remove the result and re-release the iso.


----------



## cuq (Apr 2, 2012)

Hi falkman, thank you for your post. I dont know if it is too late but I would like to ask a few questions about this before I click enter and 'make world', here they are:

It is possible just to have the kernel and/or userland in clang but not the ports?
If the system does not work with the kernel in clang, it is possible to roll back to the old one or it should be necessary to reinstall?
It is possible move some ports to clang, and then move others or I have to move all of them or none of them?
Beside the fact that clang is what will be in FreeBSD and to test is good for all of us (I don't do much about this) will the system compiled with clang run smoother or faster?
This is it,
Thank you very much
cheers
cuq


----------



## xibo (Apr 2, 2012)

cuq said:
			
		

> Hi falkman, thank you for your post. I dont know if it is too late but I would like to ask a few questions about this before I click enter and 'make world', here they are:
> 
> It is possible just to have the kernel and/or userland in clang but not the ports?


Yes, either by modifying make.conf before/after building FreeBSD, or using something the likes of

```
.if ${.CURDIR:M/usr/src*} || ${.CURDIR:M/usr/obj*}
  SHALL_USE_CLANG =
.endif

.if defined (SHALL_USE_CLANG)
.  if !defined (CC) || ${CC} == "cc"
     CC = clang
.  endif
.  if !defined (CPP) || ${CPP} == "cpp"
     CPP = clang-cpp
.  endif
.  if !defined (CXX) || ${CXX} == "c++"
     CXX = clang++
.  endif
.endif
```
or using /etc/src.conf instead of /etc/make.conf, as former is used only for the base system while latter also affects ports.



			
				cuq said:
			
		

> If the system does not work with the kernel in clang, it is possible to roll back to the old one or it should be necessary to reinstall?


Unless you messed with CFLAGS, which isn't "supported" when using gcc either, the system should be able to unroll to a filesystem snapshot from single user mode. If using zfs(8), you can also install the clang base system into some other partition and declare it to become the new root, which should be revertible in a rescue system (if the former root was not deleted in the meantime, of cause).



			
				cuq said:
			
		

> It is possible move some ports to clang, and then move others or I have to move all of them or none of them?


Probably something like

```
.if ${.CURDIR:M*multimedia/ffmpeg*} || ${.CURDIR:M*multimedia/mplayer*}
  SHALL_USE_CLANG =
  CPUTYPE        ?= corei7-avx
  CFLAGS          = -O3
  CXXFLAGS        = -O3
.endif
```
before the things posted further at the top of this post should do it.



			
				cuq said:
			
		

> Beside the fact that clang is what will be in FreeBSD and to test is good for all of us (I don't do much about this) will the system compiled with clang run smoother or faster?


Yes and no. clang can do better machine-independent optimization then gcc, especially in C++, and it also supports newer architectures. On the other side, most of the base system and also most of the ports are not written in C++, and/or compile-time optimization hardly plays a role - OpenBSD is compiled with lang/pcc by many people, and pcc lacks the majority of optimization abilities while still producing sufficiently fast running binaries.
That said, clang can produce measurably faster binaries for computation-intensive tasks, i.e. multimedia, compression (including zfs one), and so on, but will hardly make a difference for "normal" applications like cp(1) or ftp(1).


----------

