This service will be undergoing maintenance at 00:00 UTC, 2016-08-01. It is expected to last about 1 hours
Bug 493048 - llvm-gcc and llvm-g++ missing
llvm-gcc and llvm-g++ missing
Status: CLOSED WONTFIX
Product: Fedora
Classification: Fedora
Component: llvm (Show other bugs)
12
All Linux
low Severity medium
: ---
: ---
Assigned To: Bryan O'Sullivan
Fedora Extras Quality Assurance
: Triaged
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2009-03-31 09:34 EDT by Nido Media
Modified: 2010-05-23 07:56 EDT (History)
10 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2010-05-23 07:56:26 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:


Attachments (Terms of Use)

  None (edit)
Description Nido Media 2009-03-31 09:34:50 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):
llvm.i386 0:2.4-4.fc10
llvm-devel.i386 0:2.4-4.fc10

How reproducible:
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>
  
Actual results:
llvmc2: Can't find program 'llvm-gcc'
llvmc2: Can't find program 'llvm-g++'

Expected results:
no terminal output, but llvm-compiled binaries instead

Additional info:
'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)
Comment 1 Jeff Garzik 2009-04-24 09:12:03 EDT
Agreed, a C front-end should be shipped.

clang would be useful, if llvm-gcc is problematic.
Comment 2 Jeff Garzik 2009-04-24 09:39:06 EDT
Simple instructions:

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

     cd /opt/my-llvm-source-code-directory
     ./configure
     make -sj$NCPUS

as you would normally.
Comment 3 Thomas Sailer 2009-07-18 08:18:14 EDT
Ping? Changing version to rawhide, as rawhide does not seem to include a C front end either
Comment 4 Bryan O'Sullivan 2009-07-21 18:36:17 EDT
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.
Comment 5 Jeff Garzik 2009-07-21 18:46:31 EDT
clang is easy to build...
Comment 6 Bryan O'Sullivan 2009-08-08 14:26:17 EDT
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.

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.
Comment 7 Jeff Garzik 2009-08-08 23:17:30 EDT
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.
Comment 8 Kevin J. Cummings 2009-08-09 00:00:25 EDT
(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
> tree.  

Do we need to have a new maintainer for LLVM on Fedora?  (No, I'm *not* volunteering!)
Comment 9 Bryan O'Sullivan 2009-08-09 23:48:24 EDT
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.
Comment 10 Kevin J. Cummings 2009-08-10 00:02:35 EDT
(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.
Comment 11 Bryan O'Sullivan 2009-08-10 00:14:14 EDT
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.
Comment 12 Michel Alexandre Salim 2009-08-27 19:38:32 EDT
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.
Comment 13 Michel Alexandre Salim 2009-09-09 03:28:13 EDT
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?
Comment 14 Bug Zapper 2009-11-16 04:53:17 EST
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:
http://fedoraproject.org/wiki/BugZappers/HouseKeeping
Comment 15 Eric Smith 2010-01-29 19:22:44 EST
Providing clang is good, but providing llvm-gcc (etc.) would still be useful because it supports more source languages than does clang.
Comment 16 Michel Alexandre Salim 2010-05-16 07:46:23 EDT
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.
Comment 17 Eric Smith 2010-05-16 15:22:12 EDT
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.
Comment 18 Michel Alexandre Salim 2010-05-23 07:56:26 EDT
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.

Note You need to log in before you can comment on or make changes to this bug.