question about gccld and external libraries

hi,

I'm really new to llvm. I've successfully bootstrapped llvm-14 on my system and am able to successfully compile c code to llvm.

the problem is now that gccld is complaining that it can't find the libraries, like "c" or "crtend". [1]

all is fine, if I just use intrinsified functions like printf and friends, but I want to use the clock_gettime function and now the lli dumps.

thanks for any pointers.

-- jakob

[1]
gccld -o test-llvm -L/mnt/fire300/jp/llvm-14/lib/gcc/i686-pc-linux-gnu/3.4-llvm -L/mnt/fire300/jp/llvm-14/lib/gcc/i686-pc-linux-gnu/3.4-llvm/../../.. /tmp/ccc7ax7O.o -lc -lcrtend

gccld: warning: Cannot find library 'c'
gccld: warning: Cannot find library 'crtend'
gccld: warning: Cannot find library 'c'
gccld: warning: Cannot find library 'crtend'

Hey, Jakob --

I'm really new to llvm. I've successfully bootstrapped llvm-14 on my
system and am able to successfully compile c code to llvm.

the problem is now that gccld is complaining that it can't find the
libraries, like "c" or "crtend". [1]

Did you install the bytecode libraries into the C/C++ frontend lib
directory?

See

http://llvm.cs.uiuc.edu/docs/CFEBuildInstrs.html#instructions

7. Go back into the LLVM source tree proper. Rerun configure, using the
same options as the last time. This will cause the configuration to now
find the newly built llvm-gcc and llvm-g++ executables.

8. Rebuild your CVS tree. This shouldn't cause the whole thing to be
rebuilt, but it should build the runtime libraries. After the tree is
built, install the runtime libraries into your GCC front-end build tree.
These are the commands you need:

% gmake
% gmake -C runtime install-bytecode

Jakob Praher wrote:

hi,

I'm really new to llvm. I've successfully bootstrapped llvm-14 on my system and am able to successfully compile c code to llvm.

the problem is now that gccld is complaining that it can't find the libraries, like "c" or "crtend". [1]

If you built your own llvm-gcc, then you need to build and install the bytecode libraries as Misha directed.

However, if you downloaded a pre-built llvm-gcc frontend, then the bytecode libraries should already be pre-built for you. If that is the case, then chances are good that you need to set LLVM_LIB_SEARCH_PATH so that gccld can find the libraries.

You can try setting the environment variable LLVM_LIB_SEARCH_PATH to <cfrontend>/bytecode-libs, where <cfrontend> is the general installation directory of llvm-gcc.

For example, if I downloaded the binary llvm-gcc frontend for Linux and installed it in /home/john/cfrontend, then I would set LLVM_LIB_SEARCH_PATH to /home/john/cfrontend/x86/llvm-gcc/bytecode-libs.

This step will not be required in future versions of LLVM, which is probably why you missed it. The docs on the web page are the current ones geared for the next release. If you go to http://llvm.cs.uiuc.edu/releases/1.4/docs/index.html, you will see the documentation pertaining to LLVM 1.4.

all is fine, if I just use intrinsified functions like printf and friends, but I want to use the clock_gettime function and now the lli dumps.

thanks for any pointers.

-- jakob

[1]
gccld -o test-llvm -L/mnt/fire300/jp/llvm-14/lib/gcc/i686-pc-linux-gnu/3.4-llvm -L/mnt/fire300/jp/llvm-14/lib/gcc/i686-pc-linux-gnu/3.4-llvm/../../.. /tmp/ccc7ax7O.o -lc -lcrtend

gccld: warning: Cannot find library 'c'
gccld: warning: Cannot find library 'crtend'
gccld: warning: Cannot find library 'c'
gccld: warning: Cannot find library 'crtend'

_______________________________________________
LLVM Developers mailing list
LLVMdev@cs.uiuc.edu http://llvm.cs.uiuc.edu
http://mail.cs.uiuc.edu/mailman/listinfo/llvmdev

Regards,

-- John T.

Misha Brukman wrote:

Hey, Jakob --

I'm really new to llvm. I've successfully bootstrapped llvm-14 on my
system and am able to successfully compile c code to llvm.

the problem is now that gccld is complaining that it can't find the
libraries, like "c" or "crtend". [1]

Did you install the bytecode libraries into the C/C++ frontend lib
directory?

thanks for the pointer. Yes I've done that, but in the new shell session I apparently forgot to set the LLVM_LIB_SEARCH_PATH.

now gccld isn't complaining anymore but the interpreter doesn't seem to like it still:

ERROR: Program used external function 'clock_gettime' which could not be resolved!
lli((anonymous namespace)::PrintStackTrace()+0x1a)[0x862a53e]
lli((anonymous namespace)::SignalHandler(int)+0xd3)[0x862a807]
[0xffffe420]
lli(llvm::JIT::getPointerToFunction(llvm::Function*)+0x199)[0x837e863]
lli((anonymous namespace)::JITEmitter::getPointerToGlobal(llvm::GlobalValue*, void*, bool)+0xdb)[0x8380287]
lli((anonymous namespace)::JITEmitter::finishFunction(llvm::MachineFunction&)+0x18f)[0x838048f]
lli((anonymous namespace)::Emitter::runOnMachineFunction(llvm::MachineFunction&)+0x102)[0x840d448]
...

-- Jakob

It looks like the jit doesn't find these because they are located in librt. Try this (or adapt to whatever system you're using):

lli -load /usr/lib/librt.so yourprog.bc

If you pass '-lrt' when linking your program, it should take care of this for you.

-Chris

Chris Lattner wrote:

thanks for the pointer. Yes I've done that, but in the new shell session I apparently forgot to set the LLVM_LIB_SEARCH_PATH.

now gccld isn't complaining anymore but the interpreter doesn't seem to like it still:

It looks like the jit doesn't find these because they are located in librt. Try this (or adapt to whatever system you're using):

lli -load /usr/lib/librt.so yourprog.bc

oh. thanks that worked.

If you pass '-lrt' when linking your program, it should take care of this for you.

ah ok. so every library thet gccld can't find as a bytecode lib is added to the shell script then.

-- Jakob

Yup. Note there are other options if you don't want to run your program in the JIT. In particular, you can use these commands:

llvm-gcc x.c -Wl,-native -lrt -l...
llvm-gcc x.c -Wl,-native-cbe ...

To produce native executables that do not need the JIT. The first option uses the native LLVM code generator, the second uses the C backend and a system C compiler.

-Chris

Chris Lattner wrote:

If you pass '-lrt' when linking your program, it should take care of this for you.

ah ok. so every library thet gccld can't find as a bytecode lib is added to the shell script then.

Yup. Note there are other options if you don't want to run your program in the JIT. In particular, you can use these commands:

llvm-gcc x.c -Wl,-native -lrt -l...
llvm-gcc x.c -Wl,-native-cbe ...

To produce native executables that do not need the JIT. The first option uses the native LLVM code generator, the second uses the C backend and a system C compiler.

thanks for the info.
what is the advantage of doing so?
I suppose the at-link-time-optimization stuff, so I suppose that the nativization happens at link time? (haven't done the -v on that). Otherwise this wouldn't make much sense.

In my case I am strongly interested in llvm as a low level vm (jit) for all kinds of (bytecode/language) frontends. Like libjava and libmono. Plus I'd like to experiment with it with regards to analyzing large systems. But I am at the very start. I've also talked to gcj people at the FOSDEM and they would also be interested in that sort of thing at least they need a decent jit/dynamic compiler.

It should really be easier in the free world to bridge all those languages and llvm seems a viable solution for that.

I'll come with more info on that.

Thanks for your support.
-- Jakob

To produce native executables that do not need the JIT. The first option uses the native LLVM code generator, the second uses the C backend and a system C compiler.

thanks for the info.
what is the advantage of doing so?
I suppose the at-link-time-optimization stuff, so I suppose that the nativization happens at link time? (haven't done the -v on that). Otherwise this wouldn't make much sense.

yes, this is primarily for people who want to use LLVM as just a C/C++ compiler that supports link-time IPO, but aren't interested in the JIT capabilities.

In my case I am strongly interested in llvm as a low level vm (jit) for all kinds of (bytecode/language) frontends. Like libjava and libmono. Plus I'd like to experiment with it with regards to analyzing large systems. But I am at the very start. I've also talked to gcj people at the FOSDEM and they would also be interested in that sort of thing at least they need a decent jit/dynamic compiler.

Ok, gotcha. You probably don't want -native or -native-cbe then :slight_smile:

It should really be easier in the free world to bridge all those languages and llvm seems a viable solution for that. I'll come with more info on that.

Sounds great!

-Chris