On Thu, Jan 09, 2020 at 09:28:14AM -0700, Alan Feuerbacher via blfs-support wrote: > On 1/8/2020 9:37 PM, Bruce Dubbs via blfs-support wrote: > > On 1/8/20 8:54 PM, Alan Feuerbacher via blfs-support wrote: > > > After running into problems building doxygen, I tracked the basic > > > problem down to the library file libLLVM-9.so being missing from > > > /usr/lib . > > >
> Now this is downright weird! I rebuilt LLVM-9 several times, with > different > combinations of building non-shared libraries (the default from the > BLFS > book) and shared libraries. I also built LLVM-8 to see what I would > get. I never installed them during testing. Here are the results: > > # Where libLLVM-9.so did not show up: > (lfs chroot) root:/sources/llvm-9.0.1.src/build/lib# ll libLLVM* > lrwxrwxrwx 1 root root 27 Jan 8 17:20 libLLVMAMDGPUAsmParser.so > -> libLLVMAMDGPUAsmParser.so.9 > -rwxr-xr-x 1 root root 1808448 Jan 8 17:20 libLLVMAMDGPUAsmParser.so.9 > > # LLVM-8: > (lfs chroot) root:/sources/llvm-8.0.1.src/build/lib# ll libLLVM* > -rwxr-xr-x 1 root root 57944080 Jan 8 19:20 libLLVM-8.so > -rw-r--r-- 1 root root 1014160 Jan 8 19:05 libLLVMAMDGPUAsmParser.a > -rw-r--r-- 1 root root 333624 Jan 8 19:05 libLLVMAMDGPUAsmPrinter.a > Building without installing may not create everything. It is not uncommon for packages to to fix up libraries durign the install. In general, to see what gets installed use a DESTDIR approach. And if you don't like what gets installed, remove the source before trying different options. > > I have no clue what happened, other than perhaps evil magic gremlins. > LLVM has caused a lot of pain over the years. The commands used in the book should work, optional commands worked when last tested and might cause problems. I use the commands in the book (not the options) for my normal builds, and then I make sure that the many static libs are not available : I have no objection if something needs to use one, but I want to know so that I can rebuild things using static libs if htere is a vulnerability. For what I build (using gcc and g++ for preference if possible), nothing needs the static libs. > So now back to the original problem where testing doxygen-1.8.17 fails: > [...] > Then I tested the installed /usr/bin/doxygen: > > ######### > (lfs chroot) root:/sources/doxygen-1.8.17/build# which doxygen > /usr/bin/doxygen > (lfs chroot) root:/sources/doxygen-1.8.17/build# doxygen --version > : CommandLine Error: Option 'help-list' registered more than once! > LLVM ERROR: inconsistency in registered CommandLine options > ######### > > where I've added -Duse_libclang=ON . > > Any ideas? > Looks like https://github.com/doxygen/doxygen/issues/6379 That appears to have been open for 18 months, across two minor releases, with fairly-recent comments re llvm-9. Given how much pain llvm causes (e.g. 9.0.1 for the rust version we are using, and ISTR there was a problem with 9.0) I will not be at all surprised if something within 9.0.1 has caused the problem to show up here. I would be tempted to try the patch from Debian (last January, even though against 1.8.15) https://salsa.debian.org/paolog-guest/doxygen/blob/master/debian/patches/llvm_libs.diff unless, of course, it has already been applied to 1.8.17. ĸen -- The right of the people to keep and arm Bears, shall not be infringed. -- http://lists.linuxfromscratch.org/listinfo/blfs-support FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
