Vendor branch committed. See revision 41230.

I haven't much time at the moment, but here is the output of gcc with option -v for cross-compiling on Linux:

i386-aros-gcc hello.c -v
Using built-in specs.
Target: i386-aros
Configured with: /home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/Ports/gcc/gcc-4.2.4/configure --prefix=/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools --target=i386-aros --target=i386-aros --bindir=/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools --enable-languages=c,c++ --enable-long-long --enable-version-specific-runtime-libs --enable-sjlj-exceptions --with-sysroot=/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development
Thread model: single
gcc version 4.2.4
/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/libexec/gcc/i386-aros/4.2.4/cc1 -quiet -v hello.c -quiet -dumpbase hello.c -mtune=i386 -auxbase hello -version -o /tmp/ccvOL5a4.s
ignoring nonexistent directory "/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/local/include"
ignoring nonexistent directory "/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/lib/gcc/i386-aros/4.2.4/../../../../i386-aros/include"
#include "..." search starts here:
#include <...> search starts here:
/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/lib/gcc/i386-aros/4.2.4/include
/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include
End of search list.
GNU C version 4.2.4 (i386-aros)
compiled by GNU C version 4.3.4.
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: a70ebb07a504ca7e4850acf425984339
/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/lib/gcc/i386-aros/4.2.4/../../../../i386-aros/bin/as --traditional-format -V -Qy -o /tmp/ccvDl3gT.o /tmp/ccvOL5a4.s
GNU assembler version 2.21.1 (i386-aros) using BFD version (GNU Binutils) 2.21.1
/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/lib/gcc/i386-aros/4.2.4/../../../../i386-aros/bin/collect-aros --sysroot=/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development --eh-frame-hdr -m elf_i386 -L /home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/lib /home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/lib/startup.o -L/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/lib/gcc/i386-aros/4.2.4 -L/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/crosstools/lib/gcc/i386-aros/4.2.4/../../../../i386-aros/lib -L/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/lib /tmp/ccvDl3gT.o -lgcc -lamiga -larossupport -larosc -lm -lgcc -lautoinit


HTH

Thanks mazze. All feedback and bug reports are welcome, encouraged, and appreciated!

Quote:

Good catch. This link is automatically generated by the build script. The link for 'aros-clang' is relative, but not the link for 'aros-clang++'. I've manually changed the link to point to 'aros-clang' now.

Quote:

aros-clang spoofs as being GNU C compatible and thus expects to have access to all the GNU C headers. Unfortunately stddef.h isn't part of the AROS SDK so unless you have the GNU C headers in some standard location, like /usr/include, aros-clang won't be able to locate stddef.h. There are two solutions:

1. Add a -I option to point to your native Linux GNU C include location which contains stddef.h.

2. Modify null.h line 13 to something like:

#if !defined(__GNUC__) || defined(__AROS__)

Quote:

As Sam said, the -m32 option should do the trick.

Quote:

Yes, this is part of the collect-aros problem. Specifically that it can't seem to look for these object files in the lib directory instead of the current directory. However, this is not a show-stopper problem with collect-aros, since modifying the command line with the full object paths or copying all the objects to the current directory should allow it to link. But in my experience, even then, the resulting executable doesn't work properly on a native AROS system.

If someone can tell from the invocation why collect-aros may not be working properly, I'd appreciate it. Maybe it's an option I'm forgetting or something simple:

Quote:

Until I get it fixed, I recommend compiling only to object files (with the -c option) and do all the linking either on a native AROS setup, or with a known good linker.

Thanks,
Mike

@mazze

Thanks for trying it out. As you noticed, the parser is a bit stricter than GCC and it defaults to the C99 mode also. To set it to 32-bit output is the same as GCC: -m32 .

I'll have to have Mike check for the packaging error for the relative path to ../lib/clang/2.9/*.h . I'll probably have to repackage the Mac version too.

New attempt with a hello world which uses PutStr from dos.library:

./aros-clang -ccc-host-triple i686-pc-aros -I/home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include hello.c -o hello -v
clang version 2.9 (tags/RELEASE_29/final)
Target: i686-pc-aros
Thread model: posix
"/home/mazze/projects/llvm/bin/aros-clang-2.9" -cc1 -triple i686-pc-aros -emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name hello.c -mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i586 -momit-leaf-frame-pointer -v -resource-dir /home/mazze/projects/llvm/bin/../lib/clang/2.9 -I /home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include -ferror-limit 19 -fmessage-length 179 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-DprYZL.o -x c hello.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on x86_64-unknown-linux-gnu
ignoring nonexistent directory "/home/mazze/projects/llvm/bin/../lib/clang/2.9/include"
#include "..." search starts here:
#include <...> search starts here:
/home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include
/usr/local/include
/usr/include
End of search list.
hello.c:5:2: warning: passing 'char [7]' to parameter of type 'CONST_STRPTR' (aka 'const unsigned char *') converts between pointers to integer types with different sign
[-Wpointer-sign]
PutStr("hello\n");
^~~~~~~~~~~~~~~~~
In file included from hello.c:1:
In file included from /home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include/proto/dos.h:23:
/home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include/inline/dos.h:1714:25: note: instantiated from:
__inline_Dos_PutStr((arg1), (APTR)DOSBase)
^~~~~~
/home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include/inline/dos.h:1706:53: note: passing argument to parameter '__arg1' here
static inline LONG __inline_Dos_PutStr(CONST_STRPTR __arg1, APTR __DOSBase)
^
1 warning generated.
"/home/mazze/projects/fullaros/aros-linux-i386-v0-dbg/bin/linux-x86_64/tools/collect-aros" --eh-frame-hdr -dynamic-linker /libexec/ld.elf_so -o hello crt0.o crti.o crtbegin.o /tmp/cc-DprYZL.o -lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s --no-as-needed crtend.o crtn.o
/usr/bin/ld.bfd.real: crt0.o: No such file: No such file or directory
aros-clang-2: error: linker command failed with exit code 1 (use -v to see invocation)


Ok, that's probably the already mentioned problem with collect-aros.

I have tried the Linux cross-compiler.

There's a wrong link to the c++ compiler:
lrwxrwxrwx 1 mazze mazze 43 2011-09-04 22:26 aros-clang++ -> /home1/liquidot/llvm-build/bin/./aros-clang


Then I tried to build a simple hello world program:

./aros-clang -ccc-host-triple i686-pc-aros hello.c -o hello
In file included from hello.c:1:
/usr/include/stdio.h:34:11: fatal error: 'stddef.h' file not found
# include <stddef.h>
^
1 error generated.


Next attempt with include path:

./aros-clang -ccc-host-triple i686-pc-aros -I /home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include hello.c -o hello
In file included from hello.c:1:
In file included from /home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include/stdio.h:14:
/home/mazze/projects/aros-linux-i386-v0-dbg/bin/linux-i386/AROS/Development/include/aros/types/null.h:17:10: fatal error: 'stddef.h' file not found
#include <stddef.h>
^
1 error generated.

Maybe I need a different include path.

How do I set the output to 32-bit?

Some other notes:

LLVM doesn't have a replacement for GNU Binutils yet so linking still requires that.

For the most important options regarding options that don't show up during "aros-clang --help" try "aros-clang --help-hidden". That should help you find how to do cross-compilations with Clang, do 32-bit builds on a 64-bit platform, etc.

Please report any problems not related to Binutils here or on the mailing list and we'll try to deal with them before we submit the patch files to the AROS SVN.

Due to a bug in the Linux compilations, one of the patches has been updated and the patched source reuploaded. Hopefully we can get Linux binaries up soon.

Quote:

Having the diffs and a location to download the unpatched sources usually is enough, though, we also started to use vendor branches some weeks before.

ciao

Release candidate 1 of AROS Clang is available for download from the AROS Clang project page. It seems that a C-based cross-compiler was the best way to demonstrate that LLVM is working so that's how we distributed it. There are also the main LLVM binaries included in the archives.

If the sources are wanted in the main AROS archive, contact me. They are quite large. They are available in their entirety in the llvm-2.9-patched-src.zip file in the AROS-Clang download area.

Notes:

The Mac binaries are for a 64-bit Snow Leopard install. A Leopard install for PPC or 32-bit Intel may be possible from source but I can't go that far back from XCode 4.1 (at least for PPC).

Since ABI v0 was all that was working when Mike was working on this, ABI v1 will have to wait.

The AROS Native C compiler will also have to wait. Unlike the ABI issue, this will probably have to be covered in the phase 2 bounty.

The Linux and Windows binaries are 32-bit Intel.