As far as I know, LLVM doesn't install shared libraries (except libLTO.so on x86_64?); applications that use it, link statically to it. Also, I'll have a look at the llvm-ocaml package and correct the permissions.

What benefit(s) would '--enable-targets=all' give us?

If I'm mistaken somewhere, please let me know. :)

> As far as I know, LLVM doesn't install shared libraries (except libLTO.so on x86_64?);

Yes it does,

# Install shared libs
make -j1 SHARED_LIBRARY=1 || return 1
cp Release/lib/libLLVM*.so "${pkgdir}/usr/lib/llvm" || return 1

will install the shared libraries. I am attaching PKGBUILD that makes use of the above code. For further details see http://llvm.org/docs/MakefileGuide.html

> applications that use it, link statically to it.

No, shared libs are essential for many LLVM applications, e.g., to load LLVM JIT compiler (libLLVMJIT.so) dynamically if needed, to name just one.

> What benefit(s) would '--enable-targets=all' give us?

Cross compilation, i.e., to generate code for target architectures and platforms other than the host.

Hope this helps.

Thanks for taking your time for improving llvm package.

Cheers, George

I'm not sure SHARED_LIBRARY is meant to be set by us; it looks more like a variable that a library can set to denote that it should be built as shared. That's the case with libLTO, for example. I checked Fedora's and Debian's LLVM packages and neither includes shared libraries (besides libLTO). I hope you understand why I'm reluctant to implement this.

The permissions issue with llvm-ocaml should be corrected in 2.6-5. I also enabled all targets, like you suggested.

At any rate, you certainly seem to know more about LLVM than I do, so please excuse me if I'm misunderstanding something. Feel free to provide further suggestions for improvement. :)

> I hope you understand why I'm reluctant to implement this.

I do understand . However, I do not think that if something is wrong with Debian and Fedora packages Arch needs to inherit the deficiencies. Quite opposite Arch should try to improve on them. All shared vs. static arguments do apply here, I also outlined why LLVM shared libraries are really useful, and after all LLVM's build system provides a way to build shared libraries, both in its CMake and autotool incarnations. So why should not we use it and improve the package.

I am attaching PKGBUILD that builds LLVM shared libraries as a separate package. I am not suggesting that we should use the provided PKGBUILD. This just to demonstrate that it can be done.


> The permissions issue with llvm-ocaml should be corrected in 2.6-5. I also enabled all targets, like you suggested.

Thanks a lot, very much appreciated, I have seen the improvements in LLVM 2.6-5.

> Feel free to provide further suggestions for improvement. :)

One more improvement please. Because libffi header files are installed in a non-standard location, LLVM's configure script assumes that libffi is not available. libffi support is enabled by default in LLVM and is needed to run natively compiled code in LLVM interpreter (very useful feature).

I suggest we add CPPFLAGS="-I/usr/lib/libffi-3.0.8/include" to configure and make lines see attached PKGBUILD. This also required libffi to be added as a dependency.

Thanks in advance for your consideration.

Cheers, George

Thanks for the suggestion about libffi. I used `export CPPFLAGS="$CPPFLAGS $(pkg-config --cflags libffi)"' inside the build function and it appears to have picked it up. It will be enabled in the 2.6-6 packages.

I'm still not going forward with the shared libraries (at least for now). I'm not interested in following what Fedora or Debian does, but I'm obviously not going to ignore them completely either. Setting SHARED_LIBRARY ourselves simply feels like something that we shouldn't do. That is also the feeling I got when I asked in #llvm on IRC (although one of the two people that replied did acknowledge the validity of your libLLVMJIT.so example).

If I'm being overly stubborn, please excuse me and correct me. :)

> Thanks for the suggestion about libffi. I used `export CPPFLAGS="$CPPFLAGS $(pkg-config --cflags libffi)"' inside the build function and it appears to have picked it up. It will be enabled in the 2.6-6 packages.


Thanks a lot for the improvement, very much appreciated.


> I'm still not going forward with the shared libraries (at least for now). I'm not interested in following what Fedora or Debian does, but I'm obviously not going to ignore them completely either. Setting SHARED_LIBRARY ourselves simply feels like something that we shouldn't do. That is also the feeling I got when I asked in #llvm on IRC (although one of the two people that replied did acknowledge the validity of your libLLVMJIT.so example).

I do understand your concern regarding setting SHARED_LIBRARY ourselves. I am not suggesting to build shared libraries this way. All I am saying is that shared libraries for LLVM should be available. Almost all libraries in Arch (and other distros) come in both, static and shared, flavours. Why should LLVM be different. LLVM is a library for building compilers.

Going back to SHARED_LIBRARY variable. The reason I used it to build the shared libraries is that configure's "--enable-shared" flag had some problems on my system. The fact that such flag exists confirms the fact that LLVM is indeed intended to be used as a shared lib as well. As I understand the breakage of the flag is a bug in LLVM's autotools-based build system and building of shared libs is properly supported in LLVM's cmake-based build system.

I would like to suggest to investigate ways of building shared libs proper/acceptable way and even get in touch upstream with build system improvements and queries (if needed).

Cheers, George

Thanks for the follow-up. I'll keep this issue in mind and revisit it when time allows.