Page MenuHomePhabricator

Fix `llvm-config` to adapt to the install environment.
ClosedPublic

Authored by DiamondLovesYou on Sep 27 2015, 12:25 AM.

Details

Summary

This patch does a couple of things:

  • Adds a new argument --shared-mode which accepts a list of components and prints whether or not the provided components need to be linked statically or shared.
  • Fixes --libnames when CMake BUILD_SHARED_LIBS is used.
  • Fixes --libnames, --libs, and --libfiles for dylib when static components aren't installed.
  • Fixes --libnames, --libs, --libfiles, and --components to use LLVM_DYLIB_COMPONENTS as the component manifest for dylib linking.
  • Uses the host platform's usual convention for filename extensions and such, instead of always defaulting to Unix-izms.

Because I don't own a Mac, I am not able to test the Mac platform dependent stuff locally. If someone would be willing to run a build for me on their machine (unless there's a better option), I'd appreciate it.

Diff Detail

Repository
rL LLVM

Event Timeline

DiamondLovesYou retitled this revision from to Fix `llvm-config` to adapt to the install environment..
DiamondLovesYou updated this object.
DiamondLovesYou added reviewers: brad.king, jfb.
DiamondLovesYou set the repository for this revision to rL LLVM.
DiamondLovesYou added a subscriber: llvm-commits.
brad.king edited edge metadata.Nov 2 2015, 10:20 AM

Sorry for the delay. Overall the changes look good. The configuration of BuildVariables.inc looks right.

I built and tested on OS X and there is a problem. For versioned shared libraries, CMake places the version number before the .dylib suffix, as in libLLVMObject.3.8.0svn.dylib instead of libLLVMObject.dylib.3.8.0svn. The --libfiles output currently constructs the versioned names with the components in the wrong order. On Linux the order is correct and the named files exist.

DiamondLovesYou added a comment.EditedNov 2 2015, 2:09 PM

I built and tested on OS X and there is a problem. For versioned shared libraries, CMake places the version number before the .dylib suffix, as in libLLVMObject.3.8.0svn.dylib instead of libLLVMObject.dylib.3.8.0svn. The --libfiles output currently constructs the versioned names with the components in the wrong order. On Linux the order is correct and the named files exist.

Thanks for running a build! Does Darwin's autoconf do the same? (EDIT: grammars)

Thanks for running a build! Does Darwin's autoconf do the same? (EDIT: grammars)

With autoconf the library name is libLLVM-3.8svn.dylib and there is a symlink called libLLVM-3.8.0svn.dylib that points to it (which seems reversed, BTW). However, since LLVM_ENABLE_SHARED is hard-coded to OFF for autoconf builds (by this patch) the --libfiles output does not list the dylib anyway.

DiamondLovesYou edited edge metadata.

Mac puts the package revision before the extension.

After a minor fix this now compiles and gives the proper --libfiles paths on OS X with both CMake and autoconf builds.

tools/llvm-config/llvm-config.cpp
367

Minor fix needed to compile:

-  std::string DyLibName = SharedPrefix + "LLVM";
+  std::string DyLibName = SharedPrefix.str() + "LLVM";
DiamondLovesYou edited edge metadata.

Fix compile issue.

DiamondLovesYou marked an inline comment as done.Nov 6 2015, 8:12 AM
DiamondLovesYou added inline comments.
tools/llvm-config/llvm-config.cpp
367

Odd that I did not catch that locally.

beanz added a subscriber: beanz.Nov 6 2015, 10:04 AM

We've made some changes recently to LLVM's CMake usage to make it match the output of our autoconf build. The changes were reviewed here: D13841

These changes aren't ideal for a number of reasons, but they make your patches not work correctly on trunk. The main changes are:

  • The version is only part of the library path on Linux
  • The version is always before the shared library extension (meaning libLLVM-3.8.so not the more-typical libLLVM.so.3.8)
DiamondLovesYou marked an inline comment as done.

Fixes for recent trunk changes.

I applied the updated changes on top of r252467 and built all combinations of:

  • OS: Linux / OS X
  • Build tool: autoconf / cmake
  • --enable-shared (LLVM_BUILD_LLVM_DYLIB): ON / OFF

I also tried removing the .a files so that llvm-config would switch to reporting the single shared library instead of the components.

All worked as expected.

beanz accepted this revision.Nov 9 2015, 2:02 PM
beanz added a reviewer: beanz.

LGTM! Thank you for doing this.

-Chris

This revision is now accepted and ready to land.Nov 9 2015, 2:02 PM
This revision was automatically updated to reflect the committed changes.
chapuni added a subscriber: chapuni.Feb 9 2016, 5:21 PM
chapuni added inline comments.
llvm/trunk/tools/llvm-config/llvm-config.cpp
331 ↗(On Diff #39758)

The behavior should be controlled not by target, but by host. Fixed in r260343.
Consider if host=linux, target=i686-win32.

llvm-config is a tool for host's libraries, regardless of the target.

With cross compilation of clang/llvm, Both llvm-config (host's, aka
configure's --build) and llvm-config.exe should be built.
See also, http://bb.pgr.jp/builders/i686-mingw32-RA-on-linux/builds/7293
It is using i686-mingw32-g++ on linux.