Displaying 4 results from an estimated 4 matches for "llvmgcc3".
Did you mean:
llvmgcc
2006 Jun 02
0
[LLVMdev] Compiling natively vsftp with LLVM
.... -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 LLVM.
I agree that this is an ugly issue. You've basically fallen into the
"llvmgcc3 doesn't work the way a normal compiler does" problem. If you
use llvmgcc4, it is completely transparent, and works just like a native
compiler, unless you provide the -emit-llvm switch.
If you'd like for this stuff to work, I'd suggest *not* using the gccld
"-native*"...
2006 Jun 02
2
[LLVMdev] Compiling natively vsftp with LLVM
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
2006 Nov 08
0
[LLVMdev] going from gcc 4.0.1 to gcc 4.2
Hi Kenneth,
On Wed, 2006-11-08 at 11:58 +0100, Kenneth Hoste wrote:
> Hello LLVM-people,
>
> I realize most of you have other things on their head now, with the
> 1.9 release coming up, but I'd like to ask some questions regarding
> the llvm-gcc frontend.
Okay.
> The current llvm-gcc4 frontend is based on GCC 4.0.1, as far as I can
> tell from the docs. I also
2006 Nov 08
2
[LLVMdev] going from gcc 4.0.1 to gcc 4.2
Hello LLVM-people,
I realize most of you have other things on their head now, with the
1.9 release coming up, but I'd like to ask some questions regarding
the llvm-gcc frontend.
The current llvm-gcc4 frontend is based on GCC 4.0.1, as far as I can
tell from the docs. I also understand that GCC 4.1.x will probably be
skipped, to go to the upcoming GCC 4.2 release directly (which is