I'm new to Linux environment. Few days ago I've installed Fedora on my laptop. I want to complie some C++ source code but having trouble with Clang. First, after installing it with *yum* I see an error (whenever I call clang in the console): clang: symbol lookup error: clang: undefinied symbol: LLVMInitializeMipsAsmParser After trying different methods I gave up on installing Clang and wanted to stick to g++. OK. but today I wanted to install some IDE. Decided to go with CodeLite and... whenever I want to open CodeLite it gives me this error: /lib64/libclang.so.3.8: undefined symbol: LLVMInitializeMipsAsmParser Seems like CodeLite is installing Clang by default and I ending up with the same error... To be honest I've tried to build LLVM from source but that didn't help (I guess Clang has to know somehow where to look for those symbols and I don't know how to tell it) and I don't have enough disc space to build LLVM & Clang at the same time (it takes 20+ GB...) following instructions from here: http://llvm.org/docs/GettingStarted.html#getting-started-quickly-a-summary

When running the Dolphin emulator from the stable Debian repos in Debian 12 with KDE I get the below error. However, no error is shown on a nearly identical machine where Dolphin emulator works fine. I already tried removing and then reinstalling dolphin-emu but I still get the same error. libllvm13 is the oldest version that is available in the repos. Installing that didn't help. There is no llvm-libs in the repos that's recommended in another question similar to this. It looks like in the machine where it works I have llvm11 installed locally (not from the repos) but llvm is not in the Debian repos. Bug report 1 When I run env QT_QPA_PLATFORM=xcb dolphin-emu it shows: dolphin-emu: error while loading shared libraries: libLLVM-11.so.1: cannot open shared object file: No such file or directory Update: it does work in Lutris (if the environment variable is configured in the Dolphin settings) so that's a workaround as is [compiling Dolphin](https://github.com/dolphin-emu/dolphin/wiki/Building-for-Linux) . Update: after updating the Dolphin runner in Lutris the Dolphin runner doesn't work anymore either: it shows this in the console: /home/username/.local/share/lutris/runners/dolphin/dolphin-emu: error while loading shared libraries: libavformat.so.60: cannot open shared object file: No such file or directory and I only have the .59 package . That's probably a bug in Lutris (?). Dolphin can be started when changing the executable to /usr/games/dolphin-emu in the Lutris settings for Dolphin.

I'm trying to install darktable from source on Fedora 27. I've installed [all dependencies](https://redmine.darktable.org/projects/darktable/wiki/Building_darktable_22#Fedora-24-and-25) , but when I run cmake I got error: -- Could NOT find LLVM (missing: LLVM_DIR) CMake Warning at CMakeLists.txt:381 (message): Could not find LLVM 3.9+ What should be the content of this variable. I've tried this: $ whereis llvm llvm: /usr/lib64/llvm $ export LLVM_DIR=/usr/lib64/llvm $ cmake -DCMAKE_INSTALL_PREFIX=/opt/darktable/ .. but got the same error that it can't find llvm. I have llvm version 5.0.2

Is there a Linux distro compiled with [clang/llvm](http://clang.llvm.org/) ? It looks like as of late 2010 the kernel was working. If not, would it be more likely to be a technical or licensing issue?

I want to do something that is supposed to be simple in any package manager, install a package, in my case it is this specifically lib64MLIRVectorToSPIRV13.

LC_ALL=C dnf install lib64MLIRVectorToSPIRV13

The problem is that a yum dependency was installed, and it is not possible to uninstall it, because it is supposedly from the system, while I am using dnf. I couldn't run yum, because it was missing crypto symbols (and I couldn't migrate it to Python 3), so what I did was simply make a symbolic link from dnf to yum. Leaving that topic aside, what I want is to be able to overwrite, change, remove or reinstall the packages that are interfering in order to install lib64MLIRVectorToSPIRV13 Yes, I can install all the packages one by one, although it would be better with the package manager, unless there is a package on the Internet that contains all of the ___LLVM 13___. But I get this error...

Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /lib64/libstdc++.so.6 from install of lib64stdc++6-11.2.0-2.x86_64 conflicts with file from package libstdc++-4.8.5-44.el7.x86_64
  file /usr/lib64/libncursesw.so.6 conflicts between attempted installs of lib64ncursesw6-6.3-1.20211219.2.x86_64 and lib64ncursesw6-6.3-1.20211219.2.x86_64

# History of my operating system I'm using a 2006 Commodore purchased at _Garbarino_ shopping.

CPU~Dual core Pentium E5700 (-MCP-) speed/max~2611/2965 MHz Kernel~5.7.2-lxpup64 x86_64 Up~7:52 Mem~1167.9/1990.8MB HDD~95.6GB(73.6% used) Procs~155 Client~Shell inxi~2.3.8

The system I use is _LxPupSc64 20.06_, which is _PuppyLinux_, in turn based on _WOFF_ and Slackware, with a modification so that it can support various package managers. How could I install another package manager? The way I managed to install the package manager was by downloading each missing package from the ___pkgs.org___ page. The package manager that I was able to install was pacman from _ArchLinux_, then since the _Nouveau_ driver no longer starts because the system was updated, I installed another package manager, which is dnf. I couldn't install _apt-get_ or _snapd_, or any package that uses _systemd_, since _PuppyLinux_ also works without sudo. Log:

Last metadata expiration check: 0:05:38 ago on Mon Mar 25 06:52:00 2024.
Dependencies resolved.
=========================================================================================================
 Package                                            Arch        Version               Repository    Size
=========================================================================================================
Installing:
 lib64MLIRVectorToSPIRV13                           x86_64      13.0.0-1              release       33 k
Installing dependencies:
 cross-aarch64-openmandriva-linux-gnu-libc          x86_64      6:2.34-6              release       62 M
 lib64LLVMDemangle13                                x86_64      13.0.0-1              release      110 k
 lib64LLVMSupport13                                 x86_64      13.0.0-1              release      806 k
 lib64MLIRAffine13                                  x86_64      13.0.0-1              release      162 k
 lib64MLIRAnalysis13                                x86_64      13.0.0-1              release       84 k
 lib64MLIRCallInterfaces13                          x86_64      13.0.0-1              release       10 k
 lib64MLIRControlFlowInterfaces13                   x86_64      13.0.0-1              release       18 k
 lib64MLIRDataLayoutInterfaces13                    x86_64      13.0.0-1              release       28 k
 lib64MLIRDialectUtils13                            x86_64      13.0.0-1              release       26 k
 lib64MLIRIR13                                      x86_64      13.0.0-1              release      483 k
 lib64MLIRInferTypeOpInterface13                    x86_64      13.0.0-1              release       15 k
 lib64MLIRLinalg13                                  x86_64      13.0.0-1              release      701 k
 lib64MLIRLoopAnalysis13                            x86_64      13.0.0-1              release      139 k
 lib64MLIRMath13                                    x86_64      13.0.0-1              release       47 k
 lib64MLIRMemRef13                                  x86_64      13.0.0-1              release      192 k
 lib64MLIRMemRefUtils13                             x86_64      13.0.0-1              release       12 k
 lib64MLIRPDL13                                     x86_64      13.0.0-1              release       90 k
 lib64MLIRPDLInterp13                               x86_64      13.0.0-1              release      118 k
 lib64MLIRPDLToPDLInterp13                          x86_64      13.0.0-1              release       90 k
 lib64MLIRParser13                                  x86_64      13.0.0-1              release      115 k
 lib64MLIRPass13                                    x86_64      13.0.0-1              release      102 k
 lib64MLIRPresburger13                              x86_64      13.0.0-1              release       34 k
 lib64MLIRRewrite13                                 x86_64      13.0.0-1              release      122 k
 lib64MLIRSCF13                                     x86_64      13.0.0-1              release      113 k
 lib64MLIRSPIRV13                                   x86_64      13.0.0-1              release      698 k
 lib64MLIRSPIRVConversion13                         x86_64      13.0.0-1              release       43 k
 lib64MLIRSideEffectInterfaces13                    x86_64      13.0.0-1              release       13 k
 lib64MLIRStandard13                                x86_64      13.0.0-1              release      237 k
 lib64MLIRSupport13                                 x86_64      13.0.0-1              release       56 k
 lib64MLIRTensor13                                  x86_64      13.0.0-1              release      109 k
 lib64MLIRTransformUtils13                          x86_64      13.0.0-1              release      231 k
 lib64MLIRVector13                                  x86_64      13.0.0-1              release      353 k
 lib64MLIRVectorInterfaces13                        x86_64      13.0.0-1              release       11 k
 lib64MLIRViewLikeInterface13                       x86_64      13.0.0-1              release       18 k
 lib64ncursesw6                                     x86_64      6.3-1.20211219.2      release      173 k
 lib64stdc++6                                       x86_64      11.2.0-2              release      647 k
Installing weak dependencies:
 cross-aarch64-openmandriva-linux-gnu-binutils      x86_64      2.37-1                release      2.7 M
 cross-aarch64-openmandriva-linux-gnu-gcc           x86_64      11.2.0-2              release       86 M

Transaction Summary
=========================================================================================================
Install  39 Packages

Total size: 157 M
Installed size: 1.5 G
Is this ok [y/N]: y
Downloading Packages:
[SKIPPED] cross-aarch64-openmandriva-linux-gnu-binutils-2.37-1-omv4050.x86_64.rpm: Already downloaded   
[SKIPPED] cross-aarch64-openmandriva-linux-gnu-gcc-11.2.0-2-omv4050.x86_64.rpm: Already downloaded      
[SKIPPED] cross-aarch64-openmandriva-linux-gnu-libc-2.34-6-omv4003.x86_64.rpm: Already downloaded       
[SKIPPED] lib64LLVMDemangle13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                           
[SKIPPED] lib64LLVMSupport13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                            
[SKIPPED] lib64MLIRAffine13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                             
[SKIPPED] lib64MLIRAnalysis13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                           
[SKIPPED] lib64MLIRCallInterfaces13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                     
[SKIPPED] lib64MLIRControlFlowInterfaces13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded              
[SKIPPED] lib64MLIRDataLayoutInterfaces13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded               
[SKIPPED] lib64MLIRDialectUtils13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                       
[SKIPPED] lib64MLIRIR13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                                 
[SKIPPED] lib64MLIRInferTypeOpInterface13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded               
[SKIPPED] lib64MLIRLinalg13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                             
[SKIPPED] lib64MLIRLoopAnalysis13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                       
[SKIPPED] lib64MLIRMath13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                               
[SKIPPED] lib64MLIRMemRef13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                             
[SKIPPED] lib64MLIRMemRefUtils13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                        
[SKIPPED] lib64MLIRPDL13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                                
[SKIPPED] lib64MLIRPDLInterp13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                          
[SKIPPED] lib64MLIRPDLToPDLInterp13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                     
[SKIPPED] lib64MLIRParser13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                             
[SKIPPED] lib64MLIRPass13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                               
[SKIPPED] lib64MLIRPresburger13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                         
[SKIPPED] lib64MLIRRewrite13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                            
[SKIPPED] lib64MLIRSCF13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                                
[SKIPPED] lib64MLIRSPIRV13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                              
[SKIPPED] lib64MLIRSPIRVConversion13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                    
[SKIPPED] lib64MLIRSideEffectInterfaces13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded               
[SKIPPED] lib64MLIRStandard13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                           
[SKIPPED] lib64MLIRSupport13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                            
[SKIPPED] lib64MLIRTensor13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                             
[SKIPPED] lib64MLIRTransformUtils13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                     
[SKIPPED] lib64MLIRVector13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                             
[SKIPPED] lib64MLIRVectorInterfaces13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                   
[SKIPPED] lib64MLIRVectorToSPIRV13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                      
[SKIPPED] lib64MLIRViewLikeInterface13-13.0.0-1-omv4050.x86_64.rpm: Already downloaded                  
[SKIPPED] lib64ncursesw6-6.3-1.20211219.2-omv4050.x86_64.rpm: Already downloaded                        
[SKIPPED] lib64stdc++6-11.2.0-2-omv4050.x86_64.rpm: Already downloaded                                  
Running transaction check
Transaction check succeeded.
Running transaction test
The downloaded packages were saved in cache until the next successful transaction.
You can remove cached packages by executing 'dnf clean packages'.
Error: Transaction test error:
  file /lib64/libstdc++.so.6 from install of lib64stdc++6-11.2.0-2.x86_64 conflicts with file from package libstdc++-4.8.5-44.el7.x86_64
  file /usr/lib64/libncursesw.so.6 conflicts between attempted installs of lib64ncursesw6-6.3-1.20211219.2.x86_64 and lib64ncursesw6-6.3-1.20211219.2.x86_64

I have a error when open the following programs: __LxTerminal, Octopi, Qemu, Google Chrome, Geany, CodeBlocks, Blender, Baobab, Czkawka, Peek, FSearch, Gnumeric, QT Designer, Gtk3-Demo, KNewStuff Dialog, Warzone 2100, PyChess and Gxine__. And fails on open Nouveau video driver, maybe by this error.

: CommandLine Error: Option 'debug-counter' registered more than once! LLVM ERROR: inconsistency in registered CommandLine options
Abortado

How do I solve this?

In the past I have embedded resource files (images) into programs by first converting them to .o files using the GNU linker. For example: ld -r -b binary -o file.o file.svg Starting with FreeBSD 12, the default linker has changed from GNU's to LLVM's. Although the linker appears to understand the command line options, it results in an error. For example: ld -r -b binary -o file.o file.svg ld: error: target emulation unknown: -m or at least one .o file required Also tried using the command line options from the [ld.lld(1)](https://www.freebsd.org/cgi/man.cgi?query=ld) manual page: ld --relocatable --format=binary -o file.o file.svg ld: error: target emulation unknown: -m or at least one .o file required Am I using the correct tool? Do I need to specify a value for the -m option?

I have installed LLVM-14 on Ubuntu manually. Everything seems to work fine except ld during the compilation of cargo-bpf in Rust cargo.

= note: /usr/bin/ld: cannot find -lLLVM-14
          collect2: error: ld returned 1 exit status
          

error: could not compile cargo-bpf (bin "cargo-bpf") due to previous error

Output of llvm-config --version

root@ip-172-31-0-42:/opt/llvm/cs-fw# llvm-config --version
14.0.0

LLVM path: /opt/llvm/clang+llvm-14.0.0-x86_64-linux-gnu-ubuntu-18.04

I am trying to build the files in the kernel mm/ directory with a personalized LLVM compiler, then link them together with the rest of the kernel to get a bootable kernel. I extracted the exact command lines that compile the files in the mm/ directory when I compile the entire kernel, I used those command lines but with my personalised LLVM compiler and I generated the entire set of object files for the mm/ directory. I moved that directory into build/mm/ directory and I started a top down compile on the kernel - but it looks like it recompiled everything. Any ideas how could I prevent the kernel build system from rebuilding everything ?

I am compiling the Linux kernel for SPARC64 [with LLVM] and I'd like to not compile the vDSO code. I removed all the vDSO-related arguments in arch/sparc/Makefile, arch/sparc/Kbuild and arch/sparc/kernel/Makefile but is there any quicker/elegant way ? Thank you.

i am getting this error whenever i run clang even with the --version flag

clang: symbol lookup error: /usr/lib/libclang-cpp.so.14: undefined symbol: _ZN4llvm9MDBuilder25createRTTIPointerPrologueEPNS_8ConstantES2_, version LLVM_14

pacman -Qi llvm

Name            : llvm
Version         : 14.0.6-3
Description     : Compiler infrastructure
Architecture    : x86_64
URL             : https://llvm.org/ 
Licenses        : custom:Apache 2.0 with LLVM Exception
Groups          : None
Provides        : None
Depends On      : llvm-libs  perl
Optional Deps   : None
Required By     : None
Optional For    : clang
Conflicts With  : None
Replaces        : None
Installed Size  : 368.51 MiB
Packager        : Evangelos Foutras 
Build Date      : Thu 04 Aug 2022 02:34:13 AM WAT
Install Date    : Mon 15 Aug 2022 09:49:26 AM WAT
Install Reason  : Installed as a dependency for another package
Install Script  : No
Validated By    : Signature

pacman -Qi clang

Name            : clang
Version         : 14.0.6-2
Description     : C language family frontend for LLVM
Architecture    : x86_64
URL             : https://clang.llvm.org/ 
Licenses        : custom:Apache 2.0 with LLVM Exception
Groups          : None
Provides        : clang-analyzer=14.0.6  clang-tools-extra=14.0.6
Depends On      : llvm-libs  gcc  compiler-rt
Optional Deps   : openmp: OpenMP support in clang with -fopenmp
                  python: for scan-view and git-clang-format [installed]
                  llvm: referenced by some clang headers [installed]
Required By     : lldb
Optional For    : qt5-tools
Conflicts With  : clang-analyzer  clang-tools-extra
Replaces        : clang-analyzer  clang-tools-extra
Installed Size  : 168.58 MiB
Packager        : Evangelos Foutras 
Build Date      : Thu 04 Aug 2022 02:44:58 AM WAT
Install Date    : Mon 15 Aug 2022 09:49:36 AM WAT
Install Reason  : Explicitly installed
Install Script  : No
Validated By    : Signature

I was reading the Rust Unstable Book, and I saw a new feature for [emit-stack-sizes](https://doc.rust-lang.org/beta/unstable-book/compiler-flags/emit-stack-sizes.html#emit-stack-sizes) , > The rustc flag -Z emit-stack-sizes makes LLVM emit stack size metadata. It goes on to say > **NOTE: This LLVM feature only supports the ELF object format as of LLVM 8.0.** Using this flag with targets that use other object formats (e.g. macOS and Windows) will result in it being ignored. The LLVM Feature it seems to be using is the EmitStackSizeSection option. What's the purpose of knowing the stack size? Does tooling use this? Is this an official feature of ELF and if so does the kernel make use of this? This seems to get recorded in the [ELF metadata under the sections .stack_sizes, .rel.stack_sizes, and .rela.stack_sizes](https://github.com/japaric/stack-sizes/blob/6de849728bd6092b86f73025decd03d53e323414/src/lib.rs#L149)

I am using Arch Linux and I installed llvm using sudo pacman -S llvm. I installed some programs like ccls, clangd, cppcheck etc. and none of them are working: ccls: error while loading shared libraries: libLLVM-13.so: cannot open shared object file: No such file or directory clangd: error while loading shared libraries: libLLVM-13.so: cannot open shared object file: No such file or directory cppcheck: error while loading shared libraries: libtinyxml2.so.9: cannot open shared object file: No such file or directory How to fix these?

I use **Spacemacs**, and installed llvm-10, clnag-10, clangd-10, and all related packages, in **Debian 10**. Used the following command to install llvm $ sudo bash -c "$(wget -O - https://apt.llvm.org/llvm.sh) " Then, **changed** clangd-10 to clangd using the following command: $ sudo update-alternatives --install /usr/bin/clangd clangd /usr/bin/clangd-10 100 Now, how can I change the other packages like clang-10, llvm-10, lldb-10, lld-10 etc. to clang, llvm, lldb, lld, etc.? Because, I have to **compile** like $ clang-10 hello.c instead of $ clang hello.c

I have a database server running Manjaro 20.0 and postgresql 12.1-2 A recent update has prevented complex queries from running - simple select queries execute ok, but larger select queries with joins generate the following error: Error: could not load library "/usr/lib/postgresql/llvmjit.so": libLLVM-9.so: cannot open shared object file: No such file or directory Checking pacman -Qi shows me that postgresql has as a dependency llvm-libs, and that this package updated from 9.0.1-2 to 10.0.0-1 when I updated a few days ago I tried reverting llvm-libs to the 9.0.1-2 version in the pacman cache, but running the same query generates a similar error: Error: could not load library "/usr/lib/postgresql/llvmjit.so": libffi.so.6: cannot open shared object file: No such file or directory It seems there is a dependency issue here that needs to be corrected - but I haven't found any relevant bug reports, and I'm not sure where I should direct this issue - to the Arch linux package repository, the llvm-libs maintainer, or postgresql maintainer? And is there anything I can do to revert this issue in the meantime?

I deleted clang. I tried to use apt to uninstall clang, and then re-install it but I get this error: Setting up clang (1:3.8-33ubuntu3.1) ... update-alternatives: error: alternative path /usr/bin/clang++ doesn't exist dpkg: error processing package clang (--configure): subprocess installed post-installation script returned error exit status 2 Errors were encountered while processing: clang E: Sub-process /usr/bin/dpkg returned an error code (1) I've tried also using apt to remove llvm and reinstall it knowing it should also install clang. I'm using Ubuntu 16.04, since further versions are un-workingly buggy for me. Here's some more info: main@ws001:~$ whereis clang clang: /usr/bin/clang #this is obviously broken main@ws001:~$ which clang apt-cache depends clang clang Depends: clang-3.8 Breaks: Breaks: Breaks: Breaks: clang-3.5 Replaces: clang Replaces: Replaces: Replaces: Replaces: clang-3.5

Would like to try this [lld](http://lld.llvm.org/) from LLVM. The doc on apt could be found [here](http://llvm.org/apt/) , but I don't know which package contains the lld executable. It seems the purpose of lld is to remove the system dependency, but clang doesn't have lld built-in. (Not yet?) Using the following example to test if lld is used. GNU-ld places some constraint on the order of archive files appear, but lld seems to be more tolerate on this (if I understand it correctly), so this example should build successfully, if lld is used. However, it fails on my box. # one.c extern int two(); int main(int argc, char *argv[]) { two(); return 0; } # two.c void two(){} $ clang -c two.c; ar cr two.a two.o ; clang -c one.c ; clang two.a one.o one.o: In function `main': one.c:(.text+0x19): undefined reference to `two' clang: error: linker command failed with exit code 1 (use -v to see invocation) If we use -v: $ clang -c two.c; ar cr two.a two.o ; clang -c one.c ; clang -v two.a one.o Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/i686-linux-gnu/4.9.0 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.9.0 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/i686-linux-gnu/4.9.0 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.8.2 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9 Found candidate GCC installation: /usr/lib/gcc/x86_64-linux-gnu/4.9.0 Selected GCC installation: /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 "/usr/bin/ld" -z relro --hash-style=gnu --build-id --eh-frame-hdr -m elf_x86_64 -dynamic-linker /lib64/ld-linux-x86-64.so.2 -o a.out /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crt1.o /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crti.o /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/crtbegin.o -L/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8 -L/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu -L/lib/x86_64-linux-gnu -L/lib/../lib64 -L/usr/lib/x86_64-linux-gnu -L/usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../.. -L/lib -L/usr/lib two.a one.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/crtend.o /usr/bin/../lib/gcc/x86_64-linux-gnu/4.8/../../../x86_64-linux-gnu/crtn.o one.o: In function `main': one.c:(.text+0x19): undefined reference to `two' clang: error: linker command failed with exit code 1 (use -v to see invocation) ## ENV Ubuntu clang version 3.4-1ubuntu3 (tags/RELEASE_34/final) (based on LLVM 3.4) Target: x86_64-pc-linux-gnu Thread model: posix

I recently compiled llvm from source since I wanted to look at 8. However, it is a whooping 56G in size once installed. That seems excessive. How can I reduce the size of the installation? ; du -h -d 1 -c . 41M ./include 22G ./lib 35G ./bin 264K ./share 28K ./libexec 56G . 56G total Build using: cmake3 -G Ninja -DCMAKE_INSTALL_PREFIX=~/llvm -DLLVM_TEMPORARILY_ALLOW_OLD_TOOLCHAIN=1 -DLLVM_ENABLE_PROJECTS="all" ../llvm

I'm looking for something like the Linux From Scratch process for GCC, but for LLVM/Clang. Linux From Scratch builds an isolated GCC/binutils toolchain, and because of the rather monolithic nature, `the process is relatively simple. But how would one do the same with LLVM/Clang/compiler_rt/libcxx/libcxxabi/lld etc? How do I build it totally isolated from the host, from scratch? I've read the documentation for the tools, and it's been unhelpful. As far as I can tell, none of them fully document the build, or even their CMake options, let alone the bootstrapping process. And none of them document their inter-dependencies, they all just link to LLVMs?

I'm trying to run lldb on Alpine Linux V3.8, but when trying to debug any program, it hangs. I'm using lldb 5.0.1-r0 from the edge/testing repository, which is the only version available currently in the Alpine repos: lldb policy: 5.0.1-r0: lib/apk/db/installed http://dl-cdn.alpinelinux.org/alpine/edge/testing Running strace, it seems to be stuck waiting on a mutex: ... mmap(NULL, 94208, PROT_NONE, MAP_PRIVATE|MAP_ANONYMOUS, -1, 0) = 0x7fb866f10000 mprotect(0x7fb866f12000, 86016, PROT_READ|PROT_WRITE) = 0 clone(child_stack=0x7fb866f26a68, flags=CLONE_VM|CLONE_FS|CLONE_FILES|CLONE_SIGHAND|CLONE_THREAD|CLONE_SYSVSEM|CLONE_SETTLS|CLONE_PARENT_SETTID|CLONE_CHILD_CLEARTID|0x400000, parent_tidptr=0x7fb866f26b20, tls=0x7fb866f26ae8, child_tidptr=0x7fb866f26b20) = 4302 futex(0x7fb866f3db20, FUTEX_WAIT, 4300, NULL) = ? ERESTARTSYS (To be restarted if SA_RESTART is set) --- SIGCHLD {si_signo=SIGCHLD, si_code=CLD_EXITED, si_pid=4301, si_uid=1000, si_status=1, si_utime=1, si_stime=0} --- futex(0x7fb866f3db20, FUTEX_WAIT, 4300, NULL Following this lead, I found a very similar problem seen with LLDB 3.8.0 on Debian 8, described here , but unfortunately without a solution. Is it a known issue with lldb on Alpine, or am I missing some setup steps? My next step would be building latest lldb from source, but it would be much preferred to have it working with the packaged version. Many thanks!