CMake shared files are broken in llvm-3.7-dev

[chfast]

Bugzilla Link	24154
Resolution	FIXED
Resolved on	Aug 21, 2015 18:05
Version	unspecified
OS	Linux
CC	@bradking,@llvm-beanz,@delcypher,@jfbastien,@sylvestre,@DiamondLovesYou

Extended Description

The error is:

CMake Error at /usr/share/llvm-3.7/cmake/LLVMExports.cmake:8 (set_property): set_property could not find TARGET LLVMSupport. Perhaps it has not yet been created.

The file LLVMExports.cmake misses a sections with entries like that:

add_library(LLVMSupport STATIC IMPORTED) set_property(TARGET LLVMSupport PROPERTY IMPORTED_LOCATION "${_LLVM_LIBRARY_DIR}/libLLVMSupport.a")

This problem is on Ubuntu 14.04 (trusty) with package version 1:3.7~svn242033-1~exp1, but not on Ubuntu 15.04 (vivid) with package version 1:3.7~svn242178-1~exp1

[DiamondLovesYou]

@​Richard Diamond @​JF Bastien

I've just committed

r245715 r245716 r245717

which together remove the dependence on the llvm-config executable when generating the CMake export files when building LLVM with the autoconf/makefile build system.

So you can probably try reverting r244108 if you haven't already.

Thanks, but PNaCl's issue was that the build script (not LLVM's) removes the installed archives, leaving only the shared object. I've created http://reviews.llvm.org/D11835 instead, which I think is a better fix than the original for that issue.

[delcypher]

@​Richard Diamond @​JF Bastien

I've just committed

r245715 r245716 r245717

which together remove the dependence on the llvm-config executable when generating the CMake export files when building LLVM with the autoconf/makefile build system.

So you can probably try reverting r244108 if you haven't already.

[bradking]

Unfortunately, the snapshot from last night is still wonky, now in a different way. LLVM is successfully detected, but the LLVM_* variables are calculated incorrectly. The build snapshot I am testing with is 3.8~svn244215.

That is likely due to the packaging problem I described here:

http://thread.gmane.org/gmane.comp.compilers.llvm.cvs/255502/focus=255724

Debian packaging of r241080 or later needs to make the changes I described. That includes both the 3.7 branch and post-3.7 trunk.

[llvmbot]

Unfortunately, the snapshot from last night is still wonky, now in a different way. LLVM is successfully detected, but the LLVM_* variables are calculated incorrectly. The build snapshot I am testing with is 3.8~svn244215.

The state of the various variables in /usr/share/llvm-3.8/cmake/LLVMConfig.cmake are:

CMAKE_CURRENT_LIST_FILE=/usr/share/llvm-3.8/cmake/LLVMConfig.cmake _LLVM_CMAKE_DIR=/usr/share/llvm-3.8/cmake LLVM_INSTALL_PREFIX=/usr LLVM_LIBRARY_DIRS=/usr/lib LLVM_INCLUDE_DIRS=/usr/include

I am used to seeing something more along the lines of: LLVM_LIBRARY_DIRS=/usr/lib/llvm-3.8/lib LLVM_INCLUDE_DIRS=/usr/lib/llvm-3.8/include

[zmodem]

So is there a bug on 3.7 or is this only on trunk?

The bug is not in the 3.7 branch. This issue is now only about trunk. The bug existed temporarily in development versions leading up to 3.7 and happened to be packaged by Ubuntu as 1:3.7~svn242033-1~exp1, hence mention of "llvm-3.7-dev" in the bug subject line.

From what I understand, the problematic commit was r243297, which was never in 3.7.

Correct, and now that problematic commit in post-3.7 trunk has been reverted by r244108.

Great! Thanks for clarifying.

[llvm-beanz]

@​Brad, Agreed. I like how your patches restructured the logic.

[bradking]

@​Richard, Is there a reason you reverted the commit instead of applying the fix that Brad proposed on llvm-commits?

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150803/291300.html

@​Chris I wasn't subscribed to the list at the time his patch was submitted. I apologize; I should have checked the list beforehand regardless.

FYI, my patches are still worth applying because they make the logic independent of llvm-config altogether by moving it to llvm-build which is a better place for it anyway. Then Richard's llvm-config updates can be made independently of this issue.

[bradking]

So is there a bug on 3.7 or is this only on trunk?

The bug is not in the 3.7 branch. This issue is now only about trunk. The bug existed temporarily in development versions leading up to 3.7 and happened to be packaged by Ubuntu as 1:3.7~svn242033-1~exp1, hence mention of "llvm-3.7-dev" in the bug subject line.

From what I understand, the problematic commit was r243297, which was never in 3.7.

Correct, and now that problematic commit in post-3.7 trunk has been reverted by r244108.

[DiamondLovesYou]

@​Richard, Is there a reason you reverted the commit instead of applying the fix that Brad proposed on llvm-commits?

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150803/291300.html

@​Chris I wasn't subscribed to the list at the time his patch was submitted. I apologize; I should have checked the list beforehand regardless.

[zmodem]

This problem is on Ubuntu 14.04 (trusty) with package version 1:3.7~svn242033-1~exp1, but not on Ubuntu 15.04 (vivid) with package version 1:3.7~svn242178-1~exp1 [snip] llvm-config gives -lLLVM-3.8.0 regardless of library name. [snip] I think it's very likely that the issue is caused by r243297

Yes, this was caused originally by commit r241938, but that was reverted by r242152. Later it was re-applied as commit r243297. The release_37 branch as of r243928 does not have that change, but trunk as of r243996 does. This explains why it fails in some versions and not others.

So is there a bug on 3.7 or is this only on trunk?

From what I understand, the problematic commit was r243297, which was never in 3.7.

[llvm-beanz]

@​Richard, Is there a reason you reverted the commit instead of applying the fix that Brad proposed on llvm-commits?

http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150803/291300.html

[DiamondLovesYou]

I reverted the faulting commit in r244108.

[llvmbot]

this is a different topic, could you open a new bug for this?

See https://llvm.org/bugs/show_bug.cgi?id=24365

[sylvestre]

this is a different topic, could you open a new bug for this?

[llvmbot]

@@ -17,7 +17,7 @@

VENDOR=$(shell lsb_release -is)

-AUTOCONF_BUILD=yes +AUTOCONF_BUILD=no BUILD_DIR=Release

DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

The build should work, after that, I was stuck because some libraries were not generated.

It should, but for me it didn't :(

I had 3 changes so far:

1. Turn on cmake
2. Use a different BUILD_DIR, since cmake puts it in build-llvm/. as opposed to build-llvm/Release for autoconf.
3. Set build type to Release instead of Debug.

diff -rupN a/debian/rules b/debian/rules --- a/debian/rules 2015-08-05 09:23:34.680384974 -0700 +++ b/debian/rules 2015-08-05 09:24:11.900386392 -0700 @@ -17,8 +17,8 @@ endif

VENDOR=$(shell lsb_release -is)

-AUTOCONF_BUILD=yes -BUILD_DIR=Release +AUTOCONF_BUILD=no +BUILD_DIR=.

DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH) DEB_HOST_GNU_TYPE = $(shell dpkg-architecture -qDEB_HOST_GNU_TYPE) @@ -218,7 +218,7 @@ override_dh_auto_configure: preconfigure cd $(TARGET_BUILD) && \ cmake ../ \ -DCMAKE_INSTALL_PREFIX=/usr/lib/llvm-$(LLVM_VERSION) \

• -DCMAKE_VERBOSE_MAKEFILE=ON -DBUILD_SHARED_LIBS=on; \
• -DCMAKE_VERBOSE_MAKEFILE=ON -DCMAKE_BUILD_TYPE=Release -DBUILD_SHARED_LIBS=on; \ fi

  cd $(TARGET_BUILD) && cmake ../ -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_VERBOSE_MAKEFILE=ON

  mkdir build-compiler-rt && cd build-compiler-rt && cmake ../compiler-rt

[sylvestre]

I did try to switch to cmake in my setup, and there were a series of increasingly complex failures and workarounds needed. The debian/rules file is not prepared for cmake primetime,

Index: rules

--- rules (révision 1608) +++ rules (copie de travail) @@ -17,7 +17,7 @@

VENDOR=$(shell lsb_release -is)

-AUTOCONF_BUILD=yes +AUTOCONF_BUILD=no BUILD_DIR=Release

DEB_HOST_MULTIARCH = $(shell dpkg-architecture -qDEB_HOST_MULTIARCH)

The build should work, after that, I was stuck because some libraries were not generated.

[llvmbot]

I took the source debian and rebuilt it. In the build tree, llvm-config gives -lLLVM-3.8.0 regardless of library name.

$ ./llvm-config --libs all -lLLVM-3.8.0 $ ./llvm-config --libs support -lLLVM-3.8.0 $ ./llvm-config --libs -lLLVM-3.8.0

For reference, the configure string is:

../configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-cxx-include-32bit-dir=32 --prefix=/usr/lib/llvm-3.8 --bindir=\${prefix}/bin/ --disable-assertions --enable-shared --enable-optimized --with-optimize-option=' -g -O2' --enable-pic --enable-libffi --libdir=\${prefix}/lib/x86_64-linux-gnu --with-binutils-include=/usr/include --with-cloog --with-isl --with-bug-report-url=http://bugs.debian.org/ --enable-shared --disable-bindings

Would it be possible to build the deb with CMake? autoconf+make doesn't install the static libs, but CMake will. This is why llvm-config only returns the one flag.

I did try to switch to cmake in my setup, and there were a series of increasingly complex failures and workarounds needed. The debian/rules file is not prepared for cmake primetime, and least from my noobish debuild perspective. Someone else may disagree and easily patch up the build to work properly, and I would have no objection.

[bradking]

autoconf+make doesn't install the static libs, but CMake will.

It did for me when locally testing my patch with --enable-shared.

[DiamondLovesYou]

I took the source debian and rebuilt it. In the build tree, llvm-config gives -lLLVM-3.8.0 regardless of library name.

$ ./llvm-config --libs all -lLLVM-3.8.0 $ ./llvm-config --libs support -lLLVM-3.8.0 $ ./llvm-config --libs -lLLVM-3.8.0

For reference, the configure string is:

../configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-cxx-include-32bit-dir=32 --prefix=/usr/lib/llvm-3.8 --bindir=\${prefix}/bin/ --disable-assertions --enable-shared --enable-optimized --with-optimize-option=' -g -O2' --enable-pic --enable-libffi --libdir=\${prefix}/lib/x86_64-linux-gnu --with-binutils-include=/usr/include --with-cloog --with-isl --with-bug-report-url=http://bugs.debian.org/ --enable-shared --disable-bindings

Would it be possible to build the deb with CMake? autoconf+make doesn't install the static libs, but CMake will. This is why llvm-config only returns the one flag.

[jfbastien]

I forwarded this bug to Richard, who authored the original patch. We can revert if it's not resolved quickly enough (either by Brad or Richard).

[bradking]

Patch series posted here:

[PATCH] Fix LLVMExports.cmake generation with configure --enable-shared http://lists.llvm.org/pipermail/llvm-commits/Week-of-Mon-20150803/291300.html

[bradking]

I have a patch that moves away from llvm-config in favor of llvm-build that I'll post to the llvm-commits list when ready.

[bradking]

This problem is on Ubuntu 14.04 (trusty) with package version 1:3.7~svn242033-1~exp1, but not on Ubuntu 15.04 (vivid) with package version 1:3.7~svn242178-1~exp1 [snip] llvm-config gives -lLLVM-3.8.0 regardless of library name. [snip] I think it's very likely that the issue is caused by r243297

Yes, this was caused originally by commit r241938, but that was reverted by r242152. Later it was re-applied as commit r243297. The release_37 branch as of r243928 does not have that change, but trunk as of r243996 does. This explains why it fails in some versions and not others.

[delcypher]

I've not tested this but I think it's very likely that the issue is caused by r243297 [1] or r241938 [2] (the original patch was reverted and then reapplied). CC'ing JF Bastien.

This is yet another example that this feature needs to be tested. I'm going to try to revive the dead thread on this issue I created.

[1] https://github.com/llvm-mirror/llvm/commit/6a829ed9d4011f64e9c23866ab78a753eae8b3f0 [2] https://github.com/llvm-mirror/llvm/commit/01446706b4c0a86bb64768f307079cab5c514aa3

[llvmbot]

I took the source debian and rebuilt it. In the build tree, llvm-config gives -lLLVM-3.8.0 regardless of library name.

$ ./llvm-config --libs all -lLLVM-3.8.0 $ ./llvm-config --libs support -lLLVM-3.8.0 $ ./llvm-config --libs -lLLVM-3.8.0

For reference, the configure string is:

../configure --host=x86_64-linux-gnu --build=x86_64-linux-gnu --with-cxx-include-32bit-dir=32 --prefix=/usr/lib/llvm-3.8 --bindir=\${prefix}/bin/ --disable-assertions --enable-shared --enable-optimized --with-optimize-option=' -g -O2' --enable-pic --enable-libffi --libdir=\${prefix}/lib/x86_64-linux-gnu --with-binutils-include=/usr/include --with-cloog --with-isl --with-bug-report-url=http://bugs.debian.org/ --enable-shared --disable-bindings

[zmodem]

Sylvestre might know how the .deb packages are built.

[bradking]

LLVMExports.cmake is generated by "cmake/modules/Makefile" and uses

$(LLVM_CONFIG) --libs $(LINK_COMPONENTS)

to generate the list of libraries that belong in LLVMExports.cmake.

I just built from the release_37 branch as of r243634 using plain "./configure" and I get LLVMSupport in LLVMExports.cmake. With what options is Ubuntu configuring?

[bradking]

For reference, there was discussion about how to have regular testing of this infrastructure here:

[RFC] Improving the testing of exported LLVM CMake targets http://thread.gmane.org/gmane.comp.compilers.llvm.devel/87319

[zmodem]

Looks like LLVMExports.cmake was added by Brad King / Takumi Nakamura in r201050. Maybe they can help.

[chfast]

assigned to @DiamondLovesYou