# (mini vent) Do ports really need devel/llvm?



## ShelLuser (Jul 9, 2018)

Hi gang,

I cannot help starting to see a new trend on FreeBSD and I'm not too sure it's a good one, especially if you take into consideration the time it takes to build the Clang compiler. What I'm referring to?  Well, this:


```
$ pkg info -ox llvm
llvm40-4.0.1_7                 devel/llvm40
llvm50-5.0.2                   devel/llvm50
llvm60-6.0.1_1                 devel/llvm60
```
I am not a FreeBSD coder and there could be something I'm missing here, but even so I still think this is ridiculous. Do I really need 4 different compilers (don't forget about the base system)?

Now, the reason for my small vent...

After upgrading to FreeBSD 11.2 my system is in pretty good condition, including X, yet one port does give me a few problems right now which is www/firefox. It started dumping core on me (this has happened before) and right now the build process also fails (nothing I can't handle so far). In order to find the possible cause (though I already have a good hunch) I build the port using: `# make build |& tee build.log` and started my investigation.

And that's where I'm starting to lose faith in some port maintainers:


```
===>   firefox-61.0.1,1 depends on executable: autoconf-2.13 - found
===>   firefox-61.0.1,1 depends on executable: yasm - found
===>   firefox-61.0.1,1 depends on executable: zip - found
===>   firefox-61.0.1,1 depends on package: llvm60>0 - found
===>   firefox-61.0.1,1 depends on file: /usr/local/bin/python3.6 - found
===>   firefox-61.0.1,1 depends on package: gtk3>=3.14.6 - found
```
Seems obvious enough, right? Firefox has many dependencies such as devel/llvm60. As a result my system started spending a lot of time upgrading that instead of building Firefox. But there's probably a good reason for all this.

_Well...._

```
cc -fno-strict-aliasing -O2 -pipe -fstack-protector -fno-strict-aliasing -DNDEBUG -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH_TR1 -D_DECLARE_C99_LDBL_MATH -DLIBICONV_PLUG -isystem /usr/local/include -fPIC -DPSUTIL_POSIX=1 -DPSUTIL_BSD=1 -DPSUTIL_VERSION=543 -DPSUTIL_FREEBSD=1 -I/usr/local/include/python2.7 -c psutil/_psutil_posix.c -o build/temp.freebsd-11.2-RELEASE-amd64-2.7/psutil/_psutil_posix.o
```
First we see it firing up cc. Obviously relying on the default compiler and default search path. Although you can change the compiler used for the cc target in /etc/make.conf (using the CC= directive) the default is simply /usr/bin/cc.

Then we continue to the second part of the building process and here it actually starts checking the compiler capabilities:

```
checking whether the C compiler supports -Wunreachable-code-return... yes
checking whether the C++ compiler supports -Wunreachable-code-return... yes
checking whether the C compiler supports -Wclass-varargs... yes
checking whether the C++ compiler supports -Wclass-varargs... yes
checking whether the C compiler supports -Wloop-analysis... yes
checking whether the C++ compiler supports -Wloop-analysis... yes
checking whether the C++ compiler supports -Wc++1z-compat... yes
checking whether the C++ compiler supports -Wcomma... yes
```
Here we go, surely this is using something very specific in the latest Clang version, a feature which the base system simply doesn't have. Well, not so much, because a bit below this we find:

```
checking for gcc... /usr/bin/cc -std=gnu99
checking whether the C compiler (/usr/bin/cc -std=gnu99 -O2 -pipe  -O3 -DLIBICON
V_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -Wl,-
-as-needed -fstack-protector) works... yes
checking whether the C compiler (/usr/bin/cc -std=gnu99 -O2 -pipe  -O3 -DLIBICON
V_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing  -Wl,-
-as-needed -fstack-protector) is a cross-compiler... no
checking whether we are using GNU C... yes
checking whether /usr/bin/cc -std=gnu99 accepts -g... yes
checking for c++... /usr/bin/c++
```
Well, there's probably a simple reason for all this... these are obviously the default initialization scripts for Firefox which merely check for systems defaults. I'm sure we'll find more specific Clang usage further below where the script will explicitly use a specific compiler.

```
/usr/bin/c++ -o e_exp.o -c -I/usr/ports/www/firefox/work/.build/dist/stl_wrappers -I/usr/ports/www/firefox/work/.build/dist/system_wrappers -include /usr/ports/www/firefox/work/firefox-61.0.1/config/gcc_hidden.h -DNDEBUG=1 -DTRIMMED=1 -DMOZ_HAS_MOZGLUE -I/usr/ports/www/firefox/work/firefox-61.0.1/modules/fdlibm/src -I/usr/ports/www/firefox/work/.build/modules/fdlibm/src -I/usr/ports/www/firefox/work/.build/dist/include -I/usr/local/include/nspr -I/usr/local/include/nss -I/usr/local/include/nss/nss -I/usr/local/include -I/usr/local/include -I/usr/local/include/pixman-1 -fPIC -DMOZILLA_CLIENT -include /usr/ports/www/firefox/work/.build/mozilla-config.h -Qunused-arguments -D_GLIBCXX_USE_C99 -D_GLIBCXX_USE_C99_MATH_TR1 -D_DECLARE_C99_LDBL_MATH -DLIBICONV_PLUG -isystem /usr/local/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -Qunused-arguments -Wall -Wempty-body -Wignored-qualifiers -Woverloaded-virtual -Wpointer-arith -Wsign-compare -Wtype-limits -Wunreachable-code -Wunreachable-code-return -Wwrite-strings -Wno-invalid-offsetof -Wclass-varargs -Wloop-analysis -Wc++1z-compat -Wcomma -Wimplicit-fallthrough -Wstring-conversion -Wno-inline-new-delete -Wno-error=deprecated-declarations -Wno-error=array-bounds -Wformat -Wformat-security -Wno-gnu-zero-variadic-macro-arguments -Wno-unknown-warning-option -Wno-return-type-c-linkage -fno-sized-deallocation -O2 -pipe -O3 -DLIBICONV_PLUG -fstack-protector -isystem /usr/local/include -fno-strict-aliasing -DLIBICONV_PLUG -isystem /usr/local/include -U_FORTIFY_SOURCE -D_FORTIFY_SOURCE=2 -fno-exceptions -fno-strict-aliasing -fno-rtti -ffunction-sections -fdata-sections -fno-exceptions -fno-math-errno -pipe -I/usr/local/include -O2 -O3 -fno-omit-frame-pointer -Wno-parentheses -Wno-sign-compare -Wno-dangling-else  -MD -MP -MF .deps/e_exp.o.pp   /usr/ports/www/firefox/work/firefox-61.0.1/modules/fdlibm/src/e_exp.cpp
```
Well, not so much. Although I was right about my explicit usage it actually used the compiler in the base system once again.

I know!  There are probably specific include files which will be used during the building phase. Well...

```
In file included from /usr/ports/www/firefox/work/.build/media/libsoundtouch/src/Unified_cpp_libsoundtouch_src0.cpp:92:
/usr/ports/www/firefox/work/firefox-61.0.1/media/libsoundtouch/src/cpu_detect_x86.cpp:56:12: warning: 'bit_SSE' macro redefined [-Wmacro-redefined]
   #define bit_SSE     (1 << 25)
           ^
/usr/lib/clang/6.0.0/include/cpuid.h:143:9: note: previous definition is here
#define bit_SSE         0x02000000
        ^
```
Again: _only_ those from the base system and nothing which is even closely related to devel/llvm60.

In fact, I have only found 1 example where LLVM60 is being explicitely mentioned:

```
env   RUSTC_BOOTSTRAP=1 RUSTFLAGS='-C opt-level=2 '  CARGO_TARGET_DIR=/usr/ports/www/firefox/work/.build/toolkit/library RUSTC=/usr/local/bin/rustc RUSTDOC=/usr/local/bin/rustdoc MOZ_SRC=/usr/ports/www/firefox/work/firefox-61.0.1 MOZ_DIST=/usr/ports/www/firefox/work/.build/dist LIBCLANG_PATH="/usr/local/llvm60/lib" CLANG_PATH="/usr/local/llvm60/bin/clang" PKG_CONFIG_ALLOW_CROSS=1 RUST_BACKTRACE=full MOZ_TOPOBJDIR=/usr/ports/www/firefox/work/.build  MOZ_CARGO_WRAP_LDFLAGS="-pthread -Wl,--as-needed -fstack-protector -Wl,-z,noexecstack -Wl,-z,text -Wl,-z,relro -Wl,-rpath-link,/usr/ports/www/firefox/work/.build/dist/bin -Wl,-rpath-link,/usr/local/lib" MOZ_CARGO_WRAP_LD=" /usr/bin/cc -std=gnu99" CARGO_TARGET_X86_64_UNKNOWN_FREEBSD_LINKER=/usr/ports/www/firefox/work/firefox-61.0.1/build/cargo-linker /usr/local/bin/cargo rustc  --release --frozen --manifest-path /usr/ports/www/firefox/work/firefox-61.0.1/toolkit/library/rust/Cargo.toml --lib --target=x86_64-unknown-freebsd --features "servo bindgen quantum_render cubeb_pulse_rust simd-accel no-static-ideograph-encoder-tables oom_with_global_alloc" --  -C lto
```
And that's it, that's all. Right before another call was made to /usr/bin/c++.

Making me _seriously_ wonder why those port maintainers seem to force us into wasting a lot of time and effort into building those compiler versions while they're apparently not even being used? Not to mention the fact that I think it's pathetic to have 4 versions of the exact same compiler installed.

Anyway, this does lead up to a new idea I have...  On a testing machine I plan to build a meta-port of my own: one which will satisfy the dependencies for all three LLVM port releases while only linking back to the Clang version of the base system. Then I intend to build a few ports and see what will happen next. It's going to be very funny and rewarding when everything just builds normally and I can get rid of all the unneeded overhead.


----------



## drhowarddrfine (Jul 9, 2018)

I don't have time to read your whole post but, as to llvm, I noticed I had more than one, too, so I uninstalled all but devel/llvm60 and have had no issues.


----------



## trev (Jul 9, 2018)

Yes, I too have uninstalled a bunch of llvms leaving just  devel/llvm60 and have not had any issues


----------



## Bobi B. (Jul 9, 2018)

Multiple llvms happen when you upgrade several releases and/or ports. Have you tried `pkg autoremove`?


----------

