llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
http://llvm.org
Other
29.01k stars 11.96k forks source link

llvm-config omitting curses libraries #17276

Open llvmbot opened 11 years ago

llvmbot commented 11 years ago
Bugzilla Link 16902
Version trunk
OS Linux
Reporter LLVM Bugzilla Contributor
CC @chandlerc

Extended Description

At least with revision 188466, llvm-config is failing to report a curses dependency (-ltinfo in my case) established by LLVM's configure script:

$ llvm-config --ldflags
-L/usr/local/stow/llvm-latest/lib  -lbfd -lz -lpthread -lffi -lrt -ldl -lm  -lopagent -L/usr/lib/oprofile -Wl,-rpath,/usr/lib/oprofile

One ramification is that DragonEgg, which uses llvm-config to determine what to link to, fails to build:

$ make
Linking TargetInfo
/usr/local/stow/llvm-latest/lib/libLLVMSupport.a(Process.o): In function `terminalHasColors':
/tmp/llvm/lib/Support/Unix/Process.inc:265: undefined reference to `setupterm'
/tmp/llvm/lib/Support/Unix/Process.inc:283: undefined reference to `tigetnum'
collect2: error: ld returned 1 exit status
make: *** [TargetInfo] Error 1

Is this problem perhaps a fallout of the change in curses detection implemented in r188165? (I haven't checked.)

-- Scott

llvmbot commented 11 years ago

Problem is, when ncruses are compiled without tinfo, then llvm processed with colors enabled, but LDFLAGS="-ltinfo" missing.

So, my problem is fixed by compiling ncurses with tinfo and fixing mesa build system (another problem).

This issue should be opened till LLVM correctly detect ncurses without tinfo.

llvmbot commented 11 years ago

lastest git (4873c157f3b6776968f63f66bc76f839bdaf128e), clean compilation of llvm. Then compilation of mesa with llvm enabled ends with:

libtool: link: x86_64-pc-linux-gnu-g++ -fPIC -DPIC -shared -nostdlib /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/crti.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtbeginS.o .libs/egl.o .libs/egl_pipe.o .libs/egl_st.o -Wl,--whole-archive ../../../../src/gallium/auxiliary/.libs/libgallium.a ../../../../src/gallium/drivers/identity/.libs/libidentity.a ../../../../src/gallium/drivers/trace/.libs/libtrace.a ../../../../src/gallium/drivers/rbug/.libs/librbug.a ../../../../src/gallium/state_trackers/egl/.libs/libegl.a ../../../../src/gallium/winsys/sw/xlib/.libs/libws_xlib.a ../../../../src/gallium/winsys/sw/wayland/.libs/libws_wayland.a ../../../../src/egl/wayland/wayland-drm/.libs/libwayland-drm.a ../../../../src/mesa/.libs/libmesagallium.a ../../../../src/gallium/winsys/radeon/drm/.libs/libradeonwinsys.a ../../../../src/gallium/drivers/r300/.libs/libr300.a ../../../../src/gallium/drivers/softpipe/.libs/libsoftpipe.a ../../../../src/gallium/drivers/llvmpipe/.libs/libllvmpipe.a -Wl,--no-whole-archive -Wl,-rpath -Wl,/var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/egl/main/.libs -Wl,-rpath -Wl,/var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/gbm/.libs -Wl,-rpath -Wl,/var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/mapi/shared-glapi/.libs -L/var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/gbm/.libs -L/var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/mapi/shared-glapi/.libs -L/usr/lib64/llvm -Wl,--as-needed ../../../../src/egl/main/.libs/libEGL.so -lX11-xcb -lxcb-dri2 -lxcb-xfixes -lxcb-render -lxcb-shape -lxcb /var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/gbm/.libs/libgbm.so -lX11 -lXext -lXfixes ../../../../src/gbm/.libs/libgbm.so -ludev -lwayland-client -lwayland-server /var/tmp/portage/media-libs/mesa-9999-r51/work/Mesa-9999-amd64/src/mapi/shared-glapi/.libs/libglapi.so -ldrm ../../../../src/mapi/shared-glapi/.libs/libglapi.so -ldrm_radeon -lz -lpthread -lffi -lcurses -ldl -lLLVMMCJIT -lLLVMBitWriter -lLLVMX86Disassembler -lLLVMX86AsmParser -lLLVMX86CodeGen -lLLVMSelectionDAG -lLLVMAsmPrinter -lLLVMMCParser -lLLVMX86Desc -lLLVMX86Info -lLLVMX86AsmPrinter -lLLVMX86Utils -lLLVMJIT -lLLVMRuntimeDyld -lLLVMExecutionEngine -lLLVMCodeGen -lLLVMObjCARCOpts -lLLVMScalarOpts -lLLVMInstCombine -lLLVMTransformUtils -lLLVMipa -lLLVMAnalysis -lLLVMTarget -lLLVMMC -lLLVMObject -lLLVMCore -lLLVMSupport -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64 -L/lib/../lib64 -L/usr/lib/../lib64 -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../x86_64-pc-linux-gnu/lib -L/usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../.. -lstdc++ -lm -lc -lgcc_s /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/crtendS.o /usr/lib/gcc/x86_64-pc-linux-gnu/4.6.3/../../../../lib64/crtn.o -march=native -O2 -Wl,--no-undefined -Wl,--allow-multiple-definition -Wl,-R -Wl,/usr/lib64/llvm -Wl,-O1 -pthread -Wl,-soname -Wl,egl_gallium.so -o .libs/egl_gallium.so /usr/lib64/llvm/libLLVMSupport.a(Process.o): In function llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x619): undefined reference tosetupterm' /usr/lib64/llvm/libLLVMSupport.a(Process.o): In function llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x698): undefined reference totigetnum' /usr/lib64/llvm/libLLVMSupport.a(Process.o): In function llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x6a1): undefined reference toset_curterm' /usr/lib64/llvm/libLLVMSupport.a(Process.o): In function llvm::sys::Process::FileDescriptorHasColors(int)': (.text+0x6a9): undefined reference todel_curterm' collect2: ld returned 1 exit status

llvmbot commented 11 years ago

Scott, that's good to hear. The bug can be closed, then?

Yes, let's close it.

-- Scott

llvmbot commented 11 years ago

Scott, that's good to hear. The bug can be closed, then?

llvmbot commented 11 years ago

Since it appears that things should be working - I tried cleaning up the build directory completely, and it solved the problem for me. I think the problem before was that I ran 'make update', which uses the existing configure script. This may not be "clean enough" when the configure script is actually updated (my previous checkout on this machine was before Chandler's recent curses-related changes).

Scott - can you try in a clean build directory?

That worked! I did a completely clean build of revision 190309, and I no longer have a missing dependency when I link.

Thanks, -- Scott

llvmbot commented 11 years ago

Since it appears that things should be working - I tried cleaning up the build directory completely, and it solved the problem for me. I think the problem before was that I ran 'make update', which uses the existing configure script. This may not be "clean enough" when the configure script is actually updated (my previous checkout on this machine was before Chandler's recent curses-related changes).

Scott - can you try in a clean build directory?

llvmbot commented 11 years ago

I have the same problem when building a project that uses LLVM as a library. I use llvm-config to compile the project's code - properly including and adding libs. Curiously I have two slightly different machines (both Ubuntu 12.04 AMD64) that apparently have different setups and the problem only exists on one of them.

On the machine with the problem, in $BUILDDIR/tools/llvm-config/Debug+Asserts/BuildVariables.inc I have:

define LLVM_SYSTEM_LIBS "-lpthread -ldl -lm "

On the machine without the problem, the same #define shows:

define LLVM_SYSTEM_LIBS "-lz -lpthread -ltinfo -lrt -ldl -lm "

However, on both machines $BUILDDIR/include/llvm/Config/config.h has:

define HAVE_TERMINFO 1

define HAVE_TERMIOS_H 1

Which causes Support/Unix/Process.inc to use the function that aren't being linked without -ltinfo.