Red Hat Bugzilla – Bug 493048
llvm-gcc and llvm-g++ missing
Last modified: 2010-05-23 07:56:26 EDT
Description of problem:
llvm does not come with llvm-gcc. However; llvmc2 (which comes with llvm) requires llvm-gcc. Also; llvm comes with a man page for llvmgcc; but neither llvmgcc or llvm-gcc
Version-Release number of selected component (if applicable):
install the llvm package and notice the missing file. (also note the dependency
Steps to Reproduce:
1. yum install llvm llvm-devel
2. llvmc2 <path to c file>
3. llvmc2 <path to c++ file>
llvmc2: Can't find program 'llvm-gcc'
llvmc2: Can't find program 'llvm-g++'
no terminal output, but llvm-compiled binaries instead
'yum provides *bin/llvm-gcc' and 'yum provides *bin/llvm-g++' provide no results (e.g. I can't find another package with those files)
Agreed, a C front-end should be shipped.
clang would be useful, if llvm-gcc is problematic.
In order to build the clang front-end (http://clang.llvm.org/, LLVM's official C front-end), simply check out or unpack clang tarball into llvm source directory:
$ cd /opt/my-llvm-source-code-directory
$ cd tools
$ svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
clang is automatically integrated into the LLVM build process, so just do
as you would normally.
Ping? Changing version to rawhide, as rawhide does not seem to include a C front end either
llvm-gcc was a nightmare last time I took a look, but I'll see if I can spend a few minutes on this tonight.
clang is easy to build...
The llvm-gcc build is still hopelessly screwed. It drops a little shell script into its search path that pretends to be as, but actually just passes garbage to exec and thus always fails. Delete that, and things get a little further, but we get another bomb-out when building libgcc:
In file included from ./gthr-default.h:1,
../../gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory
../../gcc/gthr-posix.h:44:20: error: unistd.h: No such file or directory
I haven't tried to debug gcc build problems in years, and my heart sure isn't in it now. Patches welcome.
As for clang, it has never been released in any kind of official form. As my experience with llvm-gcc suggests, I'm not feeling masochistic this quarter, so I do not plan to try to build some random version of clang from SVN. But as I said earlier, patches welcome!
Sorry, folks. If I can't even build this stuff out of the box, I see no reason to have any confidence that it would actually work if I invested the time. If someone with an iron stomach would like to invest the time to get either llvm-gcc or clang working, I will happily apply their patches to the rawhide tree.
It is blatantly obvious that you did not attempt to build clang at all, or even learn much about it, if you [incorrectly] think that llvm-gcc build experience in any way relates to a 100% different clang source base ???
To repeat comment #2, which apparently got missed, building clang is as simple as simple can get:
1) create LLVM tree
2) check out clang into $LLVM_TREE/tools
3) type "make" in main LLVM directory
Furthermore, each clang commit is preceded by a full testsuite run, which with rare exceptions makes each random SVN version just as workable as the last one.
LLVM packages are much less useful without a real code generator shipping with the package.
If you give me CVS ACLs, I'll get it done. I build clang almost daily, to test Linux kernel builds with a non-gcc compiler.
(In reply to comment #6)
> The llvm-gcc build is still hopelessly screwed. It drops a little shell script
> into its search path that pretends to be as, but actually just passes garbage
> to exec and thus always fails. Delete that, and things get a little further,
> but we get another bomb-out when building libgcc:
> In file included from ./gthr-default.h:1,
> from ../../gcc/gthr.h:114,
> from ../../gcc/unwind-dw2.c:42:
> ../../gcc/gthr-posix.h:43:21: error: pthread.h: No such file or directory
> ../../gcc/gthr-posix.h:44:20: error: unistd.h: No such file or directory
> I haven't tried to debug gcc build problems in years, and my heart sure isn't
> in it now. Patches welcome.
Back in June, I downloaded the llvm-gcc4.2-2.5-x86-linux-RHEL4.tar.gz file from the LLVM site, and built it on my F11.i586 system using configure and make. (I have not yet tried on my F11.x86_64 system.) It built on F11.i586. (Sorry, I no longer remember how much tweaking I had to do to get it to build, but it was simple set environment variables to the right directories type of stuff.)
While it does come with a spec file, I agree that the spec file is broken for Fedora and needs fixing (by someone who understands spec files), but the software *does* build and run on Fedora 11.
> Sorry, folks. If I can't even build this stuff out of the box, I see no reason
> to have any confidence that it would actually work if I invested the time. If
> someone with an iron stomach would like to invest the time to get either
> llvm-gcc or clang working, I will happily apply their patches to the rawhide
Do we need to have a new maintainer for LLVM on Fedora? (No, I'm *not* volunteering!)
Jeff: I never claimed that I tried to build clang, I stated that I didn't plan to try, because I don't have time to work with SVN snapshots. If you want to work on it, please do so by all means.
If you want CVS access, you must request it through pkgdb before I can grant it to you. Here's the link: https://admin.fedoraproject.org/pkgdb/packages/name/llvm
Kevin: I'm delighted that you got llvm-gcc working on your machine. Please send me a patch against llvm.spec to replicate your success, and I'll apply it if it works on my x86_64 box.
(In reply to comment #9)
> Kevin: I'm delighted that you got llvm-gcc working on your machine. Please send
> me a patch against llvm.spec to replicate your success, and I'll apply it if it
> works on my x86_64 box.
You didn't read what I wrote.... I built executables directly from the .tar.gz package using configure/make/make install. I did not (could not) build RPMs using the spec file. I have no patches to send you. Instead, I suggested that someone who understands spec files better than me replicate my process and fix the spec file.
Kevin: I read what you wrote. I'm suggesting that you try to reproduce your success given the Fedora spec file (not the bit-rotted junk that's in the llvm source dist), and send me a patch if you can get it working.
clang won't be included even with LLVM 2.6 -- but what we can do is check the revision on RELEASE_25, and checkout the clang for exactly that revision.
And do the same process for 2.6.
I might be able to help with this, but not right now -- trying to fix some other packaging issue with LLVM; namely that because of the way we do "make install", the buildroot ended up in the library files.
clang is in Rawhide now (llvm-clang); I'm asking upstream what name they prefer, so it might get renamed to simply 'clang'. F-11 currently still have LLVM 2.5, and will probably stay there until two things happen:
1. LLVM 2.6 final is released
2. Any third-party packages depending on LLVM that is in F-11, or about to enter it, can be built against 2.6 (OpenGTL, currently on review, is one such potential blocker)
Is it worth doing another update just to properly exclude tools that depend on llvm-gcc?
This bug appears to have been reported against 'rawhide' during the Fedora 12 development cycle.
Changing version to '12'.
More information and reason for this action is here:
Providing clang is good, but providing llvm-gcc (etc.) would still be useful because it supports more source languages than does clang.
Agreed; however, llvm-gcc is rather tricky to build and is not the focus of upstream anyway. I'd definitely welcome any patch to the current spec file that enables llvm-gcc build, though.
Agreed! Since my comment, llvm-gcc has been deprecated. At this point packaging DragonEgg would be more useful, and should in principle be easier once Fedora moves to GCC 4.5.
Plus of the languages supported by llvm-gcc, Ada is experimental and Fortran is not fully supported. Closing this bug as WONTFIX; I have excluded llvm-gcc manpages, they will come out the next time LLVM is updated.