On 1/9/2020 3:59 PM, Ken Moffat via blfs-support wrote:
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.
Wow. That's new to me.
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.
Another thing new to me. I've not used a DESTDIR approach because I've
not needed it.
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 poked around in the LLVM files and found that
lib/Support/CommandLine.cpp contains the offending strings:
"inconsistency in registered CommandLine options"
"CommandLine Error"
When I build Doxygen with the switch "-Duse_libclang=ON" this error
arises; without the switch it all works. So I'm going with that.
I wonder if the problem is strictly with LLVM, or strictly with Doxygen,
or both.
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.
Without comparing the new against the old versions, I have no comments.
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
I tried manually doing what's in that patch: removing the word "support"
from the appropriate line in the file |doxygen/src/CMakeLists.txt . The
"CommandLine..." problem did not go away.|
|Seems to me that the maintainers of Doxygen should fix this. Yes? No?|
|Alan
|
||
--
http://lists.linuxfromscratch.org/listinfo/blfs-support
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
