LLVM Bugzilla is read-only and represents the historical archive of all LLVM issues filled before November 26, 2021. Use github to submit LLVM bugs

Bug 1055 - LLVMlto library does not build on Linux (amd64)
Summary: LLVMlto library does not build on Linux (amd64)
Status: RESOLVED FIXED
Alias: None
Product: Build scripts
Classification: Unclassified
Component: Makefiles (show other bugs)
Version: trunk
Hardware: PC Linux
: P normal
Assignee: Chandler Carruth
URL:
Keywords: build-problem
Depends on:
Blocks:
 
Reported: 2006-12-16 14:38 PST by Chandler Carruth
Modified: 2010-02-22 12:42 PST (History)
3 users (show)

See Also:
Fixed By Commit(s):


Attachments
Patch builds LLVMlto as a static library (1.22 KB, patch)
2007-01-05 19:41 PST, Chandler Carruth
Details
Patch to build LLVMlto on non Darwin systems (2.21 KB, patch)
2007-01-05 23:20 PST, Chandler Carruth
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Chandler Carruth 2006-12-16 14:38:41 PST
The library LLVMlto is only built on Darwin. Commenting out lines 26 and 28 of
tools/Makefile, to add lto to the build, results in the following error:

...
make[2]: Entering directory `/home/chandlerc/code/compilers/build/llvm/tools/lto'
llvm[2]: Linking Debug Loadable Module LLVMlto.so

*** Warning: Linking the shared library
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMlto.la against the
non-libtool
*** objects  /home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMARM.o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMIA64.o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMAlpha.o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMPowerPC.o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMSparc.o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMX86.o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMCBackend.o is not portable!
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMARM.o: relocation
R_X86_64_32 against `llvm::SupportDwarfLinkVar' can not be used when making a
shared object; recompile with -fPIC
/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMARM.o: could not read
symbols: Bad value
collect2: ld returned 1 exit status
make[2]: *** [/home/chandlerc/code/compilers/build/llvm/Debug/lib/LLVMlto.la]
Error 1
make[2]: Leaving directory `/home/chandlerc/code/compilers/build/llvm/tools/lto'
...

The same error is generated using './configure --with-pic' and without.

I am running Gentoo Linux, amd64 architecture, gcc (GCC) 4.1.1 (Gentoo 4.1.1-r3)
.

-Chandler
Comment 1 Chris Lattner 2006-12-16 14:41:40 PST
This is because all of LLVM needs to be built PIC to link liblto.  We should probably just do this.

-Chris
Comment 2 Reid Spencer 2006-12-16 16:13:24 PST
An --enable-pic option to configure has been added. Chandler is going to try it
out to see if it resolves the problem. The option default to disabled so it
shouldn't affect anyone. When it works, we'll enable it as the default.
Comment 3 Chris Lattner 2006-12-16 16:50:16 PST
Sounds good, when we know it works, we should just enable it by default everywhere.  The pain of 
building everything multiple times and supporting multiple configurations is far too high to justify 
supporting partial pic or any other things.  PIC everywhere is goodness :)
Comment 4 Chandler Carruth 2006-12-17 02:24:19 PST
Well, the -fPIC option seems to work, but isn't sufficient to solve this
problem. The libs themselves are being linked as static libraries, and can't be
pulled into a shared object. What we need is the split-generation of best static
libs and shared libs so that each can be linked as they are needed (I think?).

As a side note, I feel like when I was using a pure GNU autotools build system
it had an "ok" way of handling this. Ideally, each object is built with -fPIC,
and then two libs are linked, to minimize redundant operations. As a potential
refinement of the -fPIC behavior, as there are small speed gains without it,
perhaps allow building both PIC and non-PIC versions for everything, but only
when optimizations / release builds are enabled. Might allow the halved build
time during development (debugging) builds, but still provide performance gains
in releases, etc. Just a thought.

-Chandler
Comment 5 Chandler Carruth 2006-12-17 18:50:30 PST
Ok, I've been setting SHARED_LIBRARY=1 in Makefiles of the various objects that
cause errors when attempting to link LLVMlto, in order to get shared object
versions of those libs. So far, it seems to be removing libraries from the list
of errors, but I hit this snag with LLVMX86:

g++ -shared -nostdlib
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/crti.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/crtbeginS.o 
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86ATTAsmPrinter.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86AsmPrinter.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86CodeEmitter.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86ELFWriter.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86FloatingPoint.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86ISelDAGToDAG.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86ISelLowering.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86InstrInfo.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86IntelAsmPrinter.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86JITInfo.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86RegisterInfo.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86Subtarget.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86TargetAsmInfo.o
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86TargetMachine.o
 -L/home/chandlerc/code/compilers/build/llvm/Debug/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64 -L/lib/../lib64
-L/usr/lib/../lib64
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/lib
-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../.. -lstdc++ -lm -lc -lgcc_s
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/crtendS.o
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../lib64/crtn.o  -Wl,-soname
-Wl,libLLVMX86.so.0 -o
/home/chandlerc/code/compilers/build/llvm/Debug/lib/.libs/libLLVMX86.so.0.0.0
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
/home/chandlerc/code/compilers/build/llvm/lib/Target/X86/Debug/.libs/X86JITInfo.o:
relocation R_X86_64_PC32 against `X86CompilationCallback2' can not be used when
making a shared object; recompile with -fPIC
/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.1/../../../../x86_64-pc-linux-gnu/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status

-Chandler
Comment 6 Chandler Carruth 2007-01-05 19:41:26 PST
Created attachment 537 [details]
Patch builds LLVMlto as a static library

This doesn't build LLVMlto in the same manner in linux as it does on darwin.
Getting the build scripts to be able to do this in a reasonable manner (i.e.,
without building every file twice) isn't reasonable at this time. As a
compromise for the short term, we just build it as a static library when not in
Darwin.
Comment 7 Chandler Carruth 2007-01-05 23:20:41 PST
Created attachment 540 [details]
Patch to build LLVMlto on non Darwin systems

This is an update to fix a bug that shows up with compilers on other systems.
Particularly, while the library compiles without error, without an (empty)
definition of ~LinkTimeOptimizer(), some compilers (gcc 4.0.3) will throw an
error when linking it into a program.
Comment 8 Chris Lattner 2007-01-06 16:33:34 PST
Reid: can you review the makefile changes please?

-Chris
Comment 9 Reid Spencer 2007-01-06 20:59:50 PST
Makefile changes look fine to me. Much of this was worked out between Chanderl
and I on IRC.
Comment 10 Chris Lattner 2007-01-07 19:53:22 PST
When you have cvs commit access, please apply this Chandler!
Comment 11 Chandler Carruth 2007-01-08 00:28:26 PST
Committed patch.