Package has llvm80 dependency, why?

V

vmb

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?
 
vmb said:
I really don't understand why any package other than Poudriere (or similar) would need such a dependency.
Click to expand...
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?
Click to expand...
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.
 
  • Thanks
Reactions: vmb
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.
 
I found it. A build dependency and a run dependency...

Code: 
.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.
 
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.
 
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?
 
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.
Click to expand...
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:
Code: 
DEFAULT_VERSIONS+=llvm=80
At least here no ports complain being not compiled with the latest LLVM.
 
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.
 
You must log in or register to reply here.
Back
Top