# Package has llvm80 dependency, why?



## vmb (May 28, 2020)

I am successfully cross-building packages for arm.armv6 on Poudriere with qemu-user-static but I have run into an issue with some ports requiring llvm80 to be built and packaged. I really don't understand why any package other than Poudriere (or similar) would need such a dependency.

My packages are built for armv6 on a 64 bit Intel machine. Neither LLVM or GCC will be deployed on my armv6 device. A C compiler will never be run on my device as it doesn't have the resources which is why I am cross building packages in the first place. Even for a native amd64 package, a runtime dependency for llvm80 to be packaged needs justification. If my desired package is not compiling C code on my actual device why does it need LLVM or GCC?


----------



## SirDice (May 28, 2020)

vmb said:


> I really don't understand why any package other than Poudriere (or similar) would need such a dependency.


Most common reason is simply because it fails or cannot be built with the LLVM that's included in the base. And it's not Poudriere that needs this dependency, it's a direct consequence of using ports. Poudriere has nothing to do with this, it's simply a tool to build ports and create packages from those ports. 



vmb said:


> If my desired package is not compiling C code on my actual device why does it need LLVM or GCC?


It likely needs the libraries that come with those compilers. If the executable is linked to them, no libraries means the executable will fail to run. But besides that, there's a difference between _build_ dependencies and _run_ or _library_ dependencies. Just because LLVM or GCC is a _build_ dependency this doesn't necessarily mean they are a _run_ or _library_ dependency too.


----------



## vmb (May 28, 2020)

OK, I get that. Poudriere is building me a package that has a dependency on a statically linked LLVM library component that has a version dependency on what is made by LLVM 8.0.x . Just because my Poudriere installation makes packages, doesn't necessarily mean the port being built requires the LLVM package just one or more libraries that would be present in the LLVM package. To avoid building the LLVM80 package I only have to satisfy the Makefile dependency for the library required by the port that I need.


----------



## vmb (May 28, 2020)

I found it. A build dependency and a run dependency...


```
.if ${ARCH} == powerpc64
LLVM_DEFAULT=    90
.elif ${LLVM_DEFAULT:C/[1-5]./&0/:S,-devel,990,} >= 90
LLVM_DEFAULT=    80
.endif

.if ${ARCH} == aarch64 || ${ARCH} == amd64 || ${ARCH:Marm*} || ${ARCH} == i386 || ${ARCH:Mmips*} || ${ARCH:Mpowerpc*}
BUILD_DEPENDS+=    llvm${LLVM_DEFAULT}>=3.9.0_4:devel/llvm${LLVM_DEFAULT}
.if ${COMPONENT} != libs
RUN_DEPENDS+=    llvm${LLVM_DEFAULT}>=3.9.0_4:devel/llvm${LLVM_DEFAULT}
.endif
CONFIGURE_ENV+=    LLVM_CONFIG=${LOCALBASE}/bin/llvm-config${LLVM_DEFAULT}
LDFLAGS+=    -Wl,-rpath=${LOCALBASE}/llvm${LLVM_DEFAULT}/lib
CONFIGURE_ARGS+=    --enable-llvm
.else
CONFIGURE_ARGS+=    --disable-llvm
.endif
```

And now for some experimentation to see what happens using only the libraries in base.


----------



## linimon@ (May 31, 2020)

And now for some experimentation to see what happens using only the libraries in base.
[/QUOTE]

In general, these dependencies are introduced only in places where the base system libraries are _known_ not to satisfy the requirements.  This is particularly true if you look at some of the graphics ports, whose APIs move quickly.

I have a background task to try to minimize the N compiler dependencies we have, but, it's somewhat slow going.  For instance, llvm10.0 has introduced some regressions from llvm9.0.  We try to work with upstream to fight against the regressions, but this is a time-consuming task.

What I'm saying is that you should not expect the quick fix to be the right one.


----------



## linimon@ (May 31, 2020)

I also loathe the overriding of LLVM_DEFAULT and fight it wherever I find it.  IMHO this should be user-settable and not overridden internal to a port.

Let me guess: graphics/mesa-dri, right?


----------



## shkhln (May 31, 2020)

Mesa? That seems to be a recurring question: https://forums.FreeBSD.org/threads/what-for-www-firefox-port-pulls-devel-llvm90-in.74686/post-457061.


----------



## getopt (May 31, 2020)

linimon@ said:


> I have a background task to try to minimize the N compiler dependencies we have, but, it's somewhat slow going. For instance, llvm10.0 has introduced some regressions from llvm9.0. We try to work with upstream to fight against the regressions, but this is a time-consuming task.
> 
> What I'm saying is that you should not expect the quick fix to be the right one.


Having seen building various LLVM versions parallel at a time in Poudriere I stopped that blunt nonsense as it is time consuming, energy and ressource wasting.

My solution is setting the default LLVM version to the *lowest* needed in the various Poudriere make.conf:

```
DEFAULT_VERSIONS+=llvm=80
```
At least here no ports complain being not compiled with the latest LLVM.


----------



## vmb (Jun 2, 2020)

linimon@ said:


> Let me guess: graphics/mesa-dri, right?


Exactly!



getopt said:


> My solution is setting the default LLVM version to the *lowest* needed in the various Poudriere make.conf:
> 
> ```
> DEFAULT_VERSIONS+=llvm=80
> ...



I will try that. Thanks.


----------



## vmb (Jun 2, 2020)

I just had a thought about clamping LLVM to v8.

In the first half of 2020 it would be reasonably safe to expect most C++ code in ports to require a standard library of C++17 or earlier. I don't know what standard the majority of code would require as a minimum but I wouldn't be surprised if it were C++98. Clang in LLVM 10 supports C++98 to C++20(partially) so there will be a time when someone develops code in Modern C++ that will complain about LLVM80.

At the time of writing, Clang 5 and above can compile in -std=c++17, so Clang 8 is a reasonable choice. However, C++20 will probably be more completely supported by Clang 11 so Clang 8 is a safe choice for a while at least.


----------



## shkhln (Jun 2, 2020)

Mesa doesn't need LLVM for the latest C++ standard features. LLVM is required because amdgpu's shader compiler depends on it: https://llvm.org/docs/AMDGPUUsage.html#introduction.


----------



## Alain De Vos (Jun 3, 2020)

I add all llvms to my poudriere jails.


----------

