similar to: [LLVMdev] Patch to make gccld link natively, revised and extended... again :)

Here is a revised patch after some suggestions: 1. Removed extraneous changes (the white space changes that are -/+ whitespace), and the commented out code. 2. Keep the warning for linking dynamic libraries in LinkLibraries.cpp I still don't have a good solution to the problem of -L paths that include bytecode versions of the native libraries we're trying to link. Consider the

On Mon, Aug 01, 2005 at 05:13:15PM -0500, Nicholas Riley wrote: > The attached patch fixes this. ...but had tabs in it. Misha kindly reminded me off-list that this was bad. Try this one instead. -- Nicholas Riley <njriley at uiuc.edu> | <http://www.uiuc.edu/ph/www/njriley> -------------- next part -------------- Index: tools/gccld/GenerateCode.cpp

gccld passes -shared through if it's generating a shared library, but if you're compiling a program that needs to have its symbols externally accessible, it doesn't pass -export-dynamic through to gcc for the final link. The attached patch fixes this. I've tested with a small test case I sent Chris, and with Python; both seem to work. I also fixed some inaccurate comments in

Hello, I have a patch that: 1. Allows gccld to link shared libraries natively.. 2. Passes along -rpath and -soname to the native linker... 3. Fixes a bug where the bytecode files were kept around after native linking... 4. Removes a now unnecessary warning for native linking... The result is that we are >' '< close to having Qt4 both compile *and* link with the LLVM toolchain.

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

The quoted command line prints an error. 129 gally> gccld -debug-pass=Arguments < /dev/null -o - > /dev/null Not enough positional command line arguments specified! Must specify at least 1 positional arguments: See: gccld --help Instead, use: 126 gally> as < /dev/null > null.bc 127 gally> gccld -debug-pass=Arguments null.bc Pass Arguments: -constmerge -funcresolve

Misha Brukman wrote: > Hey, Jakob -- > > On Tue, Mar 01, 2005 at 05:55:07PM +0100, Jakob Praher wrote: > >>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

Chris Lattner wrote: > On Tue, 1 Mar 2005, Jakob Praher 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

Hey, Jakob -- On Tue, Mar 01, 2005 at 05:55:07PM +0100, Jakob Praher wrote: > 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

On Tue, 1 Mar 2005, Jakob Praher 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

On Tue, 1 Mar 2005, Jakob Praher 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

Dear All, Is it alright if I add a -disable-compression option to gccld? Disabling compression is saving me some build time, and the option already exists in other LLVM tools. -- John T.

I was getting some weird errors from gccld and traced it to path construction in isBytecodeLPath. If the path doesn't end with a /, then Path just tries to stick filenames onto it, which is not so good. It would be more efficient to just add a "/" to the path once, I guess. Also, I had to touch lib/System/Path.cpp to get my changes to Path.inc noticed; it seems the build system

Chris Lattner wrote: > On Tue, 1 Mar 2005, Jakob Praher 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

Hi, I have tried another way: ar rcs libsysdeputil.a sysdeputil.o gccld seems to recognize the file type. However, it stills find unresoved symbols which are actually the functions in sysdeputil.o (can be find out with `nm libsysdeputil.a`) The problem disappears if native gcc/ld tool chain is used. As another test, main.c: ----------------- extern void foo(); int main() { foo(); return

On Fri, 2 Jun 2006, Nai Xia wrote: > The Makefile is sth like this: > > vsftpd: $(OBJS) > gccld -r -native -o vsftpd.o $(OBJS) -L/home/xianai/my_projects/llvm/cfrontend/x86/llvm-gcc/lib/ -lcrtend > gcc -o vsftpd vsftpd.o sysdeputil.o `./vsf_findlibs.sh` > > > But the gcc/ld still cannot find the reference to __main. > Do I have to compile crtend to native to

Hi, I am using LLVM to compile vsftp to native x86 ELF code. One of it's object file (sysdeputil) contains inline asm so cannot be compiled by gcc-3.4 frontend. So I decided to firstly link together the llvm objects and libcrtend and compile it to native .o file and then link it with sysdeputil.o . The Makefile is sth like this: vsftpd: $(OBJS) gccld -r -native -o vsftpd.o $(OBJS)

On Sun, 20 Feb 2005 19:42:34 -0500, Adam Treat wrote: > The result is that we are >' '< close to having Qt4 both compile *and* link > with the LLVM toolchain. Wow, cool! Mind if I ask what is motivating this work? thanks -mike

On Monday 21 February 2005 12:46 pm, Mike Hearn wrote: > On Sun, 20 Feb 2005 19:42:34 -0500, Adam Treat wrote: > > The result is that we are >' '< close to having Qt4 both compile *and* > > link with the LLVM toolchain. > > Wow, cool! Mind if I ask what is motivating this work? Essentially, I am very interested in LLVM and want it to work with Qt4 as well as

On Fri, 2 Jun 2006, Nai Xia wrote: > And the command lines: > > llvm-gcc -c -o main.o main.c > gcc -o foo.o foo.c > ar rcs libfoo.a foo.o > llvm-gcc -Wl,-native main.o -L. -lfoo > > It's *OK* > > Thanks in advance for solving my problem. :) > And I personally think it may possiblely puzzle other users, > maybe it deserves its place in FAQ or in man page for