Bug 240169 - Review Request: llvm - The Low Level Virtual Machine
Summary: Review Request: llvm - The Low Level Virtual Machine
Alias: None
Product: Fedora
Classification: Fedora
Component: Package Review
Version: rawhide
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Michel Alexandre Salim
QA Contact: Fedora Package Reviews List
Keywords: Reopened
Depends On:
TreeView+ depends on / blocked
Reported: 2007-05-15 16:08 UTC by Bryan O'Sullivan
Modified: 2010-07-08 01:12 UTC (History)
4 users (show)

Clone Of:
Last Closed: 2008-01-21 18:26:36 UTC
michel: fedora-review+
kevin: fedora-cvs+

Attachments (Terms of Use)
Errors from attempt to build llvm-gcc4.0 (3.84 KB, text/plain)
2008-01-23 07:48 UTC, Michel Alexandre Salim
no flags Details

Description Bryan O'Sullivan 2007-05-15 16:08:22 UTC
Spec URL: http://www.red-bean.com/~bos/fedora/llvm.spec
SRPM URL: http://www.red-bean.com/~bos/fedora/llvm-1.9-1.fc7.src.rpm
LLVM is a compiler infrastructure designed for compile-time,
link-time, runtime, and idle-time optimization of programs from
arbitrary programming languages.  It currently supports compilation of
C and C++ programs. The compiler infrastructure includes mirror sets
of programming tools as well as libraries with equivalent functionality.

Comment 1 Bryan O'Sullivan 2007-05-15 16:10:24 UTC
The llvm package includes a build of gcc.  Because both llvm and gcc are
compilers, expect lots of warnings from rpmlint :-)

Comment 2 Jason Tibbitts 2007-09-22 03:41:08 UTC
This deserves a review as llvm is being used all over the place these days. 
However, I'm not sure I'm up to tackling this on my own, but I can at least give
it a little attention.  Here are a few comments after a quick skim:

URL has a typo (extra period).

Upstream released 2.0 not long after this package was submitted.

The License: tag for the NCSA license is just "NCSA".  Other License: tags will
need updating for current licensing guidelines; I think the GCC versions
included are GPLv2+ but I didn't check.

You probably do want to build the documentation in the final package.

The compiler packages seem to meet the naming conventions used by other
cross-compilers (avr-gcc, etc.) so that's OK.

The build fails for me in curent rawhide, although frankly I don't understand
what's up unless the system headers have suddenly become broken:

if g++ -I/builddir/build/BUILD/llvm-1.9/lib/Support
-I/builddir/build/BUILD/llvm-1.9/include  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS
-O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector
--param=ssp-buffer-size=4 -m64 -mtune=generic  -D_DEBUG -O2 -g -pipe -Wall
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mtune=generic -Woverloaded-virtual -pedantic -Wall -W -Wwrite-strings
-Wno-long-long -Wunused -Wno-unused-parameter  -c -MD -MT
/builddir/build/BUILD/llvm-1.9/lib/Support/Release/Allocator.o -MP -MF
Allocator.cpp -o /builddir/build/BUILD/llvm-1.9/lib/Support/Release/Allocator.o ;\
          then /bin/mv -f
"/builddir/build/BUILD/llvm-1.9/lib/Support/Release/Allocator.d"; \
          else /bin/rm -f
"/builddir/build/BUILD/llvm-1.9/lib/Support/Release/Allocator.LACXXd"; exit 1; fi
/usr/include/bits/unistd.h: In function 'int gethostname(char*, size_t)':
/usr/include/bits/unistd.h:225: error: declaration of 'int gethostname(char*,
size_t) throw ()' throws different exceptions
/usr/include/unistd.h:845: error: from previous declaration 'int
gethostname(char*, size_t)'
/usr/include/bits/unistd.h: In function 'int getdomainname(char*, size_t)':
/usr/include/bits/unistd.h:243: error: declaration of 'int getdomainname(char*,
size_t) throw ()' throws different exceptions
/usr/include/unistd.h:864: error: from previous declaration 'int
getdomainname(char*, size_t)'
Allocator.cpp: In member function 'void*
llvm::BumpPtrAllocator::Allocate(unsigned int, unsigned int)':
Allocator.cpp:95: warning: dereferencing type-punned pointer will break
strict-aliasing rules
make[1]: *** [/builddir/build/BUILD/llvm-1.9/lib/Support/Release/Allocator.o]
Error 1

I can't say much more without building it.

Comment 3 Jason Tibbitts 2007-09-22 03:59:20 UTC
Turns out that build error is a problem with rawhide G++:

I'll try rebuilding this when the fix makes it out.

Comment 4 Jason Tibbitts 2007-09-29 22:34:58 UTC
Coming back to this, I find that the package still fails to build in rawhide,
although for a completely different reason:

llvm[1]: Building llvm-config script.
-Wp,-D_FORTIFY_SOURCE=2 -fexceptions -fstack-protector --param=ssp-buffer-size=4
-m64 -mtune=generic  -D_DEBUG -O2 -g -pipe -Wall -Wp,-D_FORTIFY_SOURCE=2
-fexceptions -fstack-protector --param=ssp-buffer-size=4 -m64 -mtune=generic
-Woverloaded-virtual,' > temp.sed
echo 's,@LLVM_LDFLAGS@,,' >> temp.sed
echo 's,@LLVM_BUILDMODE@,Release,' >> temp.sed
/bin/sed -f temp.sed < llvm-config.in >
/bin/sed: file temp.sed line 1: unknown option to `s'
make[1]: *** [/builddir/build/BUILD/llvm-1.9/Release/bin/llvm-config] Error 1

Seems the '-Wp,-D_FORTIFY_SOURCE=2' bit which is now passed to the C++ compiler
by default conflicts with the use of a comma as the separator on that sed line.

Comment 5 Peter Lemenkov 2007-09-30 05:50:16 UTC
FYI ver. 2.1 is out


Comment 6 Michel Alexandre Salim 2007-11-17 03:52:13 UTC
Same problem with 2.1:

echo 's,@LLVM_LDFLAGS@,,' >> temp.sed
echo 's,@LLVM_BUILDMODE@,Release,' >> temp.sed
/bin/sed -f temp.sed < llvm-config.in >
/bin/sed: file temp.sed line 2: unknown option to `s'
make[1]: *** [/local/data/builder/packages/tmp/llvm-2.1/Release/bin/llvm-config]
Error 1
make[1]: Leaving directory
make: *** [all] Error 1

Comment 7 Jason Tibbitts 2008-01-18 07:50:35 UTC
There's been no response at all since the original submission; I'm closing this.

Comment 8 Bryan O'Sullivan 2008-01-18 13:50:45 UTC
Hmm.  I don't recall seeing any of the above comments.  Sigh.

If you have time to review this, I'll dust the submission off.  Otherwise, let's
leave it closed.

Comment 9 Michel Alexandre Salim 2008-01-18 16:26:04 UTC
Jason, do you want to pick it up? Otherwise, I can review it.

Comment 10 Jason Tibbitts 2008-01-18 17:40:16 UTC
I guess closing a ticket is the best way to get attention...

I have plenty of other stuff to do, so if anyone else wants to do this then feel
free.  I just didn't want a very idle ticket around preventing other folks from
submitting an llvm package..

A good start would be getting a package that builds.

Comment 11 Michel Alexandre Salim 2008-01-18 19:47:03 UTC
Taking this over then. Bryan, ready when you are.

Comment 12 Bryan O'Sullivan 2008-01-18 19:52:58 UTC
OK, I'll dust my patch off ASAP.

Comment 14 Bryan O'Sullivan 2008-01-21 03:26:34 UTC
Builds on i386 and x86_64, passes rpmlint.

A few notes:

I've disabled building the gcc 4.2 front end for now, because I can't get the
bootstrapped compiler to compile.

The -devel RPM puts a bunch of .o and .a files straight into %{_libdir}.  Since
the recommended way to use the LLVM tools is to get the libdir and library names
using llvm-config, we could move those to e.g. %{_libdir}/llvm if preferred.

Comment 15 Michel Alexandre Salim 2008-01-21 05:42:11 UTC
Would the gcc compilation problem be because it requires gcc 4.2 or above to
compile? (F8 has 4.1.2). In which case you can probably enable it for F9 and above.

Moving the *.{o,a} files would be nice, we want to avoid cluttering %{_libdir}.

Also, per guideline, -docs should probably be renamed to -doc.

Builds on ppc and ppc64 too:

Comment 16 Bryan O'Sullivan 2008-01-21 07:49:59 UTC
Thanks for the quick response.  I've made the changes you suggest, updated the
spec file, and uploaded a new SRPM.

Spec: http://www.red-bean.com/~bos/fedora/llvm.spec
SRPM: http://www.red-bean.com/~bos/fedora/llvm-2.1-2.fc8.src.rpm

Regarding the GCC front end build failure, I suspect it's got nothing to do with
GCC itself.  It looks like an obscure script-related bug.

I'll try building the 4.0 front end when I have some spare cycles, and see if
that gets anywhere.  But I don't think that the status of the GCC front end
should block the base llvm packages.  We can turn it on once we get it sorted
out, and nothing in the existing packages will change.

Comment 17 Michel Alexandre Salim 2008-01-21 17:18:27 UTC
- rpmlint is silent
- spec file OK
- package builds on all supported platforms
- tested to work on x86_64


Comment 18 Bryan O'Sullivan 2008-01-21 17:27:01 UTC
New Package CVS Request
Package Name: llvm
Short Description: The Low Level Virtual Machine
Owners: bos
Branches: F-8
Cvsextras Commits: yes

Comment 19 Kevin Fenzi 2008-01-21 17:29:50 UTC
cvs done.

Comment 20 Michel Alexandre Salim 2008-01-23 04:37:50 UTC
Might have found the problem with building the GCC front-end:

From llvm-gcc's README.LLVM:

"X86-64/AMD-64/EM64-T for any OS other than Darwin/Mac OS X:

When targeting non-darwin X86-64/AMD-64/EM64-T, configure with
--disable-shared.  The LLVM X86-64 backend doesn't support PIC codegen on
non-darwin systems yet.  If you get a build error, try configuring with

Our LLVM is configured the other way around, with --disable-static and
--enable-shared, *and* --with-pic.

Will check if changing those settings result in a buildable LLVM.

Comment 21 Michel Alexandre Salim 2008-01-23 07:48:18 UTC
Created attachment 292611 [details]
Errors from attempt to build llvm-gcc4.0

After several hours spent in vain, I'm giving up for now. Switched to trying to
get llvm-gcc4.0 to work, and bizarrely, it would fail (tried omitting the SMP
directives; changed nothing), but would always resume to completion if I
manually called make from the build directory!

The RHEL binaries for llvm-gcc shipped by upstream works, though in a
workaround way -- I have to tell it to generate LLVM assembly, and then
manually assemble and link the result. At least that's something..

Comment 22 Michel Alexandre Salim 2010-07-07 18:39:17 UTC
Package Change Request
Package Name: llvm
New Branches: EL-6
Owners: salimma

Comment 23 Kevin Fenzi 2010-07-08 01:12:06 UTC
CVS done (by process-cvs-requests.py).

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