# Problem in a 9.0 clang world



## sambler (Feb 13, 2012)

Machine - Asus P8H61-M-LE/USB3 - corei5 - 8GB RAM - nvidia GT520

So I am running my own 64bit kernel/world - from standard GENERIC kernel config -

```
uname -a
FreeBSD leader 9.0-RELEASE FreeBSD 9.0-RELEASE #1: Tue Feb  7 08:57:10 CST 2012     shane@leader:/usr/obj/usr/src/sys/GENERIC  amd64
```

My problem is I seem to have trouble related to libthr. I see a few ports that crash in libthr which breaks a couple of ports that for example use msgmerge during build. The example I show here is from running lang/guile straight after *make install* --

```
# gdb /usr/local/bin/guile
GNU gdb 6.1.1 [FreeBSD]
<snip>
Program received signal SIGBUS, Bus error.
[Switching to Thread 802007400 (LWP 100383/guile)]
0x00000008019001d5 in sigprocmask () from /lib/libthr.so.3
(gdb) bt
#0  0x00000008019001d5 in sigprocmask () from /lib/libthr.so.3
#1  0x0000000801b5b2ac in longjmp () from /lib/libc.so.7
#2  0x0000000000000001 in ?? ()
#3  0x00007fffffffcf68 in ?? ()
#4  0x00000008008fb3d2 in scm_ithrow () from /usr/local/lib/libguile.so.21
#5  0x000000080088f217 in scm_error_scm () from /usr/local/lib/libguile.so.21
<snip>
```
The libthr.so and libc.so calls are common place at the start of the backtrace with non-running programs.

I used the following in /etc/make.conf

```
CPUTYPE?=corei7

## we want to use clang for as much as possible
CC=clang
CXX=clang++
CPP=clang-cpp

.if ${.CURDIR:M*/usr/src*}
## we can set different cflags for world if needed
CFLAGS= -O3 -fno-strict-aliasing -pipe 
.else
CFLAGS= -O3 -fno-strict-aliasing -pipe 
## try using the new libc++
## the old one is libstdc++
#CXXFLAGS+= -stdlib=libc++ 
.endif

## I read this is to be placed in src.conf for buildworld but
## http://wiki.freebsd.org/NewC%2B%2BStack
## says to add it to make.conf ???
WITH_LIBCPLUSPLUS=yes

# Don't die on warnings
NO_WERROR=
WERROR=
# Don't forget this when using Jails!
NO_FSCHG=
```
Followed by a list of ports that need gcc46 and some custom ports adjustments.

I also had /etc/src.conf with -

```
WITHOUT_LIB32=yes

WITH_LIBCPLUSPLUS=yes
WITH_BSD_GREP=yes

WITH_ICONV=yes
```
After the new build world I have gone through and rebuilt my installed ports using clang with some exceptions that need gcc (mostly kde stuff).

Also I find that WITHOUT_LIB32 isn't completely supported. At least one port creates empty /usr/lib32/dtrace and /usr/lib32/i18n dirs (not pinned down which yet) The existence of /usr/lib32 breaks valgrind build if the expected libs aren't in there (just need to delete them).


----------



## xibo (Feb 13, 2012)

I can build world with WITHTOUT_LIB32 here. The only software package I have installed here that doesn't work (or rather build) without lib32 support is valgrind.

While -O3 will not neccessarily break things, it will most probably not be worth the additional amount of compile time. Just to be sure... have you tried building world/kernel/userland without those CFLAGS (note that the wiki recommends -O1 for clang)?


----------



## sambler (Feb 14, 2012)

I can buildworld WITHTOUT_LIB32 and run fine but I now see that build/install world creates the empty /usr/lib32/... dirs even when WITHTOUT_LIB32 is set. A couple of ports check if lib32 exists to decide to build 32bit binaries - valgrind is one. With an empty lib32 it fails to build the 32bit version - rm -R /usr/lib32 will allow valgrind to build in a 64bit only world (not tested usage)

-Ox in CFLAGS always has room for debate. -O2 has been considered the max for kernel builds for a long time. I think after 8.2 I read someone saying that an -O3 kernel passed tests. As for building with clang this wiki page says that Link Time Optimizations can be used for kernel builds - that is -O4 for clang. I feel fine testing it (maybe -O4 later) and so far have had a stable system (just this libthr issue)

Having said that I have done another build/install world and kernel with clang and -O1 with the same results. Now I'm back to a clang -O3 world.

I am confident it is a clang build issue. As a workaround - I can use a clang built world and replace /lib/libc.so.7 and /lib/libthr.co.3 with gcc built versions and solve this issue (both worlds need to be built with the same WITH_ICONV option). Now to find a proper solution...


----------



## sambler (Feb 15, 2012)

For reference -
I have narrowed this down to libthr built with clang. I was a bit over eager to include libc before.

To test I have built two worlds - one clang, one gcc (both with -O3) - each installed to different base dirs and setup to be runnable in jails. I then chroot into each and build lang/perl5.12 as this gets to the problem quicker than guile. In the clang world, when the build fails I run - 

```
# gdb work/perl-5.12.4/miniperl
GNU gdb 6.1.1 [FreeBSD]
<snip>
(gdb) r -Ilib work/perl-5.12.4/autodoc.pl 
<snip>
Program received signal SIGBUS, Bus error.
[Switching to Thread 801807400 (LWP 100342/miniperl)]
0x0000000800ff11d5 in sigprocmask () from /lib/libthr.so.3
(gdb) bt
#0  0x0000000800ff11d5 in sigprocmask () from /lib/libthr.so.3
#1  0x000000080124c2ac in longjmp () from /lib/libc.so.7
<snip>
```

Within the clang built world I can replace /lib/libthr.so.3 with the gcc built version and not have the problem.

I'll submit a pr on this now.


----------

