Opened 8 years ago

Closed 8 years ago

#7786 closed task (wontfix)

Don't build all llvm libraries as shared

Reported by: Armin K Owned by: blfs-book@…
Priority: normal Milestone: 7.10
Component: BOOK Version: SVN
Severity: normal Keywords:
Cc:

Description

According to [1]:

BUILD_SHARED_LIBS is only recommended for use by LLVM developers. If you want to build LLVM as a shared library, you should use the LLVM_BUILD_LLVM_DYLIB option.

I suggest that you replace -DBUILD_SHARED_LIBS=ON with -DLLVM_BUILD_LLVM_DYLIB=ON -DLLVM_LINK_LLVM_DYLIB=ON

That will produce one shared library, libLLVM.so, and make all the tools link to it instead of individual, static ones. Note that mesa doesn't correcly detect this kind of shared lib just yet. A sed can be used (taken from Archlinux):

sed -i 's/LLVM_SO_NAME=.*/LLVM_SO_NAME=LLVM/' configure

[1] http://llvm.org/docs/CMake.html

Change History (5)

comment:1 by Pierre Labastie, 8 years ago

This has been discussed in ticket #7528. Everything seems to work OK with the current instructions; and mesa does find the shared libraries. To me, this means that mesa devs use -DBUILD_SHARED_LIBS=ON. I guess that is documentation, which has not been updated for a while.

comment:2 by Armin K, 8 years ago

The documentation is up to date. See page footer:

LLVM Project. Last updated on 2016-04-29. Created using Sphinx 1.1.3.

In previous LLVM versions, the shared lib had version in its name, ie libLLVM-3.7.so, while 3.8 with cmake produces libLLVM.so.

LLVM 3.9 svn produces libLLVM-3.9.so, too, so I guess Mesa devs didn't feel the need to update their configure machinery just for one release. Note that mesa can also use either all static, all shared or one shared (all static and all shared depends on how LLVM was built). It will default to single shared lib before anything else.

in reply to:  2 comment:3 by Pierre Labastie, 8 years ago

Replying to Krejzi:

The documentation is up to date. See page footer:

LLVM Project. Last updated on 2016-04-29. Created using Sphinx 1.1.3.

I meant the sentence in the documentation, not the documentation as a whole... Anyway, what is your point? As an example, if we relied on GCC documentation, we would create the build directory outside the source directory. There are a lot of other places where we do not follow the documentation. So why do you want to strictly follow the doc here? Note that I do not insist on keeping the current instructions. It's rather something like "It works, so why fix it?"

comment:4 by Armin K, 8 years ago

I'm simply pointing out that you are going against recommendation. You are free to interpret it however you like and take whatever action you want.

As for the gcc, the current instructions still honor the documentation. The build directory can be placed on a hard drive on moon if needed, as long as it isn't the same as source dir.

Last edited 8 years ago by Armin K (previous) (diff)

comment:5 by bdubbs@…, 8 years ago

Resolution: wontfix
Status: newclosed

I think we can close this as wontfix for right now. We may want to reconsider later.

Note: See TracTickets for help on using tickets.