LLVM binaries can't be found

LLVM binaries are installed with non-standard names, e.g. opt35 instead of opt (with the version being the suffix). Some applications rely on the binaries having the same names as specified in the LLVM command guide:

http://llvm.org/docs/CommandGuide/

For example LLVM HIPE compiler for Erlang:

https://github.com/erlang/otp/blob/OTP-18.0.2/lib/hipe/main/hipe.erl#L1533

I know I can create a link but having to create links to all LLVM binaries every time the port is installed somehow misses the point? Or maybe there is something I am missing?
 
LLVM binaries are installed with non-standard names, e.g. opt35 instead of opt

On my system:

Code:
locate llvm |grep opt
/usr/local/llvm34/bin/opt
/usr/local/llvm35/bin/opt

In the moment I can't look on the site from the first link, llvm.org seems down.
 
I am using FreeBSD 10.1-RELEASE-p10 and installed LLVM 35 & 36 from ports devel/llvm35 and devel/llvm36.

Code:
% which opt35
/usr/local/bin/opt35

Code:
% which opt36
/usr/local/bin/opt36

Code:
% locate llvm | grep opt
/usr/local/llvm35/bin/opt
/usr/local/share/doc/llvm35/html/opt.html
/usr/local/share/doc/llvm35/html/opt.txt
/usr/src/contrib/llvm/tools/opt
/usr/src/contrib/llvm/tools/opt/AnalysisWrappers.cpp
/usr/src/contrib/llvm/tools/opt/GraphPrinters.cpp
/usr/src/contrib/llvm/tools/opt/PrintSCC.cpp
/usr/src/contrib/llvm/tools/opt/opt.cpp
/usr/src/lib/clang/libllvmobjcarcopts
/usr/src/lib/clang/libllvmobjcarcopts/Makefile
/usr/src/lib/clang/libllvmoption
/usr/src/lib/clang/libllvmoption/Makefile
/usr/src/lib/clang/libllvmscalaropts
/usr/src/lib/clang/libllvmscalaropts/Makefile
/var/db/ports/devel_llvm-devel/options
/var/db/ports/devel_llvm34/options
/var/db/ports/devel_llvm35/options
/var/db/ports/devel_llvm36/options

So opt35 and opt36 are in $PATH but not /usr/local/llvm35/bin/opt. Does the port expect me to add it manually?
 
That was my initial plan but then I thought I can't be the first one to see this problem so obviously I must be missing something. But if no one corrects me here I will try to raise it as an official bug.
 
This is normally intentional. If every LLVM package installed /usr/local/bin/opt or other non-versioned binaries then there would be no way to ever install more than one at once. If you need the generic names, then adding your preferred version to $PATH as mentioned above will be the cleanest solution. Using symlinks would work as well but comes with a bit more of an upkeep burden when versions change.
 
This is normally intentional. If every LLVM package installed /usr/local/bin/opt or other non-versioned binaries then there would be no way to ever install more than one at once. If you need the generic names, then adding your preferred version to $PATH as mentioned above will be the cleanest solution. Using symlinks would work as well but comes with a bit more of an upkeep burden when versions change.

LLVM comes with 23 binaries. Do you seriously think that every FreeBSD user should be expected to create these links manually every time they install a new version of the port???
 
LLVM comes with 23 binaries. Do you seriously think that every FreeBSD user should be expected to create these links manually every time they install a new version of the port???

Symlinks may be appropriate on some occasions. As a said there is an upkeep burden if one desires to use them. In this case that's 23 binaries that would be conflicting and prevent installing both devel/llvm35 and devel/llvm36 as the example given in this thread. The best solution is to use $PATH for the preferred version.

For tcsh(1)
set PATH=${PATH}:/usr/local/llvm35/bin
/path/to/some/program


For sh(1) and derivatives:
export PATH=$PATH:/usr/local/llvm35/bin
/path/to/some/program


If this is a shell script you can always start your script off with the updated path:
Code:
#!/bin/sh
PATH=$PATH:/usr/local/llvm35/bin
#... script continues ...
 
Unfortunately there's nothing in FreeBSD ports to handle symlinks automatically the way you see them handled in let's says Debian Linux. On Debian you have alternatives for a package and whatever alternative you install gets its binaries linked to /usr/bin so that you don't have to symlink them yourself or set up a custom PATH to find the binaries.
 
Back
Top