Dynamic linked (.so) files for clang?

Clang Frontend
#1

I’m the packager for llvm for the EPEL and it appears that all of the .so files aren’t being generated for clang. For example, libclang.so is being generated ( http://pkgs.org/centos-6/epel-x86_64/clang-3.4.2-1.el6.x86_64.rpm.html ) but several of the symbols are only available in statically linked (.a) files ( http://pkgs.org/centos-6/epel-x86_64/llvm-static-3.4.2-1.el6.x86_64.rpm.html ).

Is there something I can do to get all of the .so files to be generated?

If it helps, the .spec file that I’m using can be found at http://pkgs.fedoraproject.org/cgit/llvm.git/tree/llvm.spec?h=el6 and the configure command starts on line 320.

Thanks,

Dave

#2

The clang executable has always been linked statically, and does not actually depend on libclang.so. There isn’t support yet for linking the bulk of Clang’s internal libraries into shared libraries. For now, they are all static.

#3

Ok, that’s unfortunate but explains it.
Thanks,
Dave

#4

I’m working on packaging include-what-you-use ( https://code.google.com/p/include-what-you-use/ ) for Fedora/RHEL ( https://bugzilla.redhat.com/show_bug.cgi?id=1091659 ) and the packaging guidelines strongly discourage linking against static libraries ( http://fedoraproject.org/wiki/Packaging:Guidelines#Packaging_Static_Libraries ). I’m putting in an exception request for the time being, but are there any plans in the long term to build the dynamic libraries for clang?

Thanks,
Dave

#5

I would personally like to create a big DSO for all of clang, but I don’t think anyone is working on this.

#6

How big of a project would this be? Basically, could someone like me that
has no real experience working with LLVM/clang (other than building and
using it) do this?
Thanks,
Dave

#7

hi Dave,

for curiosity, if libclang*, libllvm* (the currently static artifacts) will be dynamic library, how would you solve these problems:

  • install different versions of clang on the same machine? (developers do that)

  • install a tool which is linked against an older version of libclang*? (tool developers might be/are in delay)

i know it is possible to do all of these with dynamic libraries. but i fear that it is less effort to use static libraries for clang developers and for tool developers. (playing with LD_LIBRARY_PATH or rpath is less preferred over static libraries.) so maybe a compiler is good exception from this packaging guideline rule. maybe creating a child package for compiler developers (containing the static libraries and the corresponding header files) could make it already more ecstatic. what do you think?

regards,

Laszlo

#8

Your concerns definitely make sense from a developer perspective, but probably not as much from a user/admin perspective, and since I’m a user/admin of LLVM/clang and not familiar with its internals I don’t have a good answer to your concerns.

But here’s an explanation of where my desire for it to be a dynamic library is coming from.
http://fedoraproject.org/wiki/Packaging:No_Bundled_Libraries
I have to say that I agree with all of the points in the Fedora guidlines as to why libraries shouldn’t be linked statically (but as I said before I’m an LLVM/clang user/admin and not a developer). Also, Fedora/RHEL have a system called Software Collections ( https://fedorahosted.org/SoftwareCollections/ ) for managing multiple versions of a library/application on the same machine, and they potentially help address your concerns but not without a little work.

Hopefully, that helps shed some light on my perspective.

Thanks,
Dave