Forum Replies Created
I reopened the bug. I was trying to clean up bugs that have been made obsolete by recent changes. I guess I was over zealous.
#1 should be fixed when you run ./ellcc install in the toplevel ellcc directory after you untar the tarball.
#2 was a real problem. I had a bug in the binary distribution script that packaged x86_84 libraries for all the non-x86_64 tarballs. Sorry about that.
You can build compiler-rt by running “scripts/build-compiler-rt -cpCbi”
“cpCbi” means “checkout patch Configure build install”.
I put a prerelease of the next version at http://ellcc.org/prerelease/
Could you give that a try? Unfortunately I don’t have a 64 bit arm system handy.
Thanks for your input!
I have some bad news and some good news. First the bad news. The current full ellcc source tree is about 2G. That contains the sources for all the components used to make ellcc. More bad new is that current binary only downloads are about 700MB.
The good news is that I’m in the process of retooling the build process and will be updating the binary download packages as well. The ellcc source download will become very small since the new build process will download the needed source files on demand. You’ll only need to download them if you want to build ellcc from scratch.
I’m also going to trim down the size of the binary downloads. Much of the size in the binary downloads is because they come with precompiled libraries for all the cross targets. With the next release, libraries will be supplied for the host system and you’ll be able to build libraries for other target systems when you need them.
I’m working on a new release with these changes right now. I’m hoping to have the release ready by the end of the week.
By the way, my Windows version is
Version 6.1 (Build 7601: Service Pack 1)
I tried to duplicate your problem on a Windows 7 box. I downloaded a copy of ELLCC and installed it as close as I could to the way you did. Here are my results:
C:\Users\de023789\Downloads\ellcc-x86_64-w64-mingw32-0.1.28\ellcc-x86_64-w64-min gw32-0.1.28\ellcc\examples\hello>C:\Users\de023789\Downloads\ellcc-x86_64-w64-mi ngw32-0.1.28\ellcc-x86_64-w64-mingw32-0.1.28\ellcc\bin\ecc.exe C:\Users\de023789 \Downloads\ellcc-x86_64-w64-mingw32-0.1.28\ellcc-x86_64-w64-mingw32-0.1.28\ellcc \examples\hello\main.c C:\Users\de023789\Downloads\ellcc-x86_64-w64-mingw32-0.1.28\ellcc-x86_64-w64-min gw32-0.1.28\ellcc\examples\hello>a.exe hello world C:\Users\de023789\Downloads\ellcc-x86_64-w64-mingw32-0.1.28\ellcc-x86_64-w64-min gw32-0.1.28\ellcc\examples\hello>
Could this have something to do with anti-virus or something on your system?
‘/’ and ‘\’ are interchangeable in Windows file names when used from programs. Not always on the command line, since ‘/’ is the option character.
I think that is a great idea. How would you like things to be split up? For example, Just an ARM compiler? No other libraries? What I don’t get is feedback on how people actually use this stuff. Maybe I should set up a way of building a distro that has exactly what people want. Ideas?
If you leave out the -S you’ll get an a.out. Otherwise you can do
ecc -S -target arm32v7-linux -mfpu=neon nios.s
which will also give you the a.out. Unless I’m misunderstanding your question. Is neon.c a complete program that can run under qemu-arm? Or is it a bare metal file meant to run under qemu-system-arm?
Yes, that is exactly the problem. After the 0.1.28 version, the config file names were changed, as were the build rules that use them. Unfortunately 0.1.28 was the last successful build of the mingw-w64 tool chain. Something changed in clang or libc++ that causes the clang build to fail. I’ve been trying to figure out what is going wrong, but I haven’t been able to spend a lot of time on it.
Sorry about that. Maybe you could run the Linux version in a virtual machine until a fix is available?
One more thing. Using the standard C and C++ libraries in a bare metal environment like this is not yet implemented. Someday soon, I hope.
I took a quick look at building circle and I was able to build it for the Raspberry Pi 1 and 2 With the following changes to Rules.mk and sample/Rules.mk.
I have not tried to run the final executables, however. The Pi 3 build fails because of assembler weirdness. Maybe modifying the ellcc/libecc/config/arm64v8-linux config file no not use the integrated assembler would help.
I hope this helps.
rich@dev:~/circle$ diff -u -r circle-master circle-master-ellcc/ Only in circle-master-ellcc/: .README.md.swp diff -u -r circle-master/Rules.mk circle-master-ellcc/Rules.mk --- circle-master/Rules.mk 2016-10-15 05:45:58.000000000 -0500 +++ circle-master-ellcc/Rules.mk 2016-10-29 15:38:38.023205633 -0500 @@ -24,21 +24,35 @@ -include $(CIRCLEHOME)/Config.mk -RASPPI ?= 1 -PREFIX ?= arm-linux-gnueabihf- +RASPPI ?= 3 +ELLCC=~/ellcc +PREFIX ?= $(ELLCC)/bin/ +ELLCCLIBS = $(ELLCC)/libecc/lib/$(TARGET) -CC = $(PREFIX)gcc -CPP = $(PREFIX)g++ +CC = $(PREFIX)ecc +CPP = $(PREFIX)ecc++ AS = $(CC) -LD = $(PREFIX)ld -AR = $(PREFIX)ar +LD = $(PREFIX)ecc-ld $(LDFLAGS) +AR = $(PREFIX)ecc-ar +OBJDUMP = $(PREFIX)ecc-objdump +OBJCOPY = $(PREFIX)ecc-objcopy +CXXFILT = $(PREFIX)ecc-c++filt ifeq ($(strip $(RASPPI)),1) -ARCH ?= -march=armv6j -mtune=arm1176jzf-s -mfloat-abi=hard +TARGET = arm32v6-linux +ARCH ?= -target $(TARGET) -march=armv6j -mtune=arm1176jzf-s \ + -mfloat-abi=soft +LDFLAGS = -m armelf_linux_eabi -L $(ELLCCLIBS) else ifeq ($(strip $(RASPPI)),2) -ARCH ?= -march=armv7-a -mtune=cortex-a7 -mfpu=neon-vfpv4 -mfloat-abi=hard +TARGET = arm32v6-linux +ARCH ?= -target $(TARGET) -march=armv7-a -mtune=cortex-a7 \ + -mfpu=neon-vfpv4 -mfloat-abi=soft +LDFLAGS = -m armelf_linux_eabi -L $(ELLCCLIBS) else -ARCH ?= -march=armv8-a -mtune=cortex-a53 -mfpu=neon-fp-armv8 -mfloat-abi=hard +TARGET = arm64v8-linux +ARCH ?= -target $(TARGET) -march=armv8-a -mtune=cortex-a53 \ + -mfpu=neon-fp-armv8 -mfloat-abi=soft +LDFLAGS = -m aarch64linux -L $(ELLCCLIBS) endif INCLUDE += -I $(CIRCLEHOME)/include -I $(CIRCLEHOME)/addon -I $(CIRCLEHOME)/app/lib Only in circle-master-ellcc/: .Rules.mk.swp diff -u -r circle-master/sample/Rules.mk circle-master-ellcc/sample/Rules.mk --- circle-master/sample/Rules.mk 2016-10-15 05:45:58.000000000 -0500 +++ circle-master-ellcc/sample/Rules.mk 2016-10-29 15:30:40.785993359 -0500 @@ -27,9 +27,9 @@ endif kernel.img: $(OBJS) $(LIBS) - $(LD) -o kernel.elf -Map kernel.map -T $(CIRCLEHOME)/circle.ld $(CIRCLEHOME)/lib/startup.o $(OBJS) $(LIBS) - $(PREFIX)objdump -d kernel.elf | $(PREFIX)c++filt > kernel.lst - $(PREFIX)objcopy kernel.elf -O binary kernel.img + $(LD) -o kernel.elf -Map kernel.map -T $(CIRCLEHOME)/circle.ld $(CIRCLEHOME)/lib/startup.o $(OBJS) $(LIBS) -lcompiler-rt + $(OBJDUMP) -d kernel.elf | $(CXXFILT) > kernel.lst + $(OBJCOPY) kernel.elf -O binary kernel.img wc -c kernel.img include $(CIRCLEHOME)/Rules.mk rich@dev:~/circle$
I am not sure how to respond to your questions. I’ve been doing this site for quite a while. As much as I’d like to think that this project could survive with donations, and allow me ability to work on ELLCC full time, I suspect that is unreasonable for me to expect. If you have access to bags of cash, I’d gladly listen 🙂 For now I’ll just keep doing it because I want to.
-RichAugust 23, 2016 at 6:44 am in reply to: ecc-ld: attempted static link of dynamic object libexpat.so #77229
Sorry it has taken so long to get back to you.
I think the problem is that libtool is mistakenly giving the system libexpat.so to the linker when trying to build the metalinkcat utility,
Originally I tried to build ELLCC from scratch on my Fedora system which has libexpat installed. Unfortunately the build went just fine: build with gcc worked, subsequent build with ecc worked. I’m not sure why Ubuntu would be different, unfortunately.
The good news is that you have everything you need built. If you were to edit /home/vagrant/ellcc/libecc/Makefile to remove the libmetalink parts, I think the rest of your build would go OK. Comment this part out:
$(Configs):: musl.install $(OUT)$(MAKE) $(MFLAGS) $@.libmetalink.configure && \ $(MAKE) $(MFLAGS) $@.libmetalink.build && \ $(MAKE) $(MFLAGS) $@.libmetalink.install
I checked into this and found out that the C++ API backend has been removed.
Sorry about that.
Sorry about that. I’ve updated Using ELLCC. I’m also thinking that it might be a good idea to error or warn about a -target option that doesn’t refer to a config file.
That configuration only works with version 0.1.29:
[~] dev% ellcc/bin/ecc -target mips32r2el-linux hello.c [~] dev% file a.out a.out: ELF 32-bit LSB executable, MIPS, MIPS32 rel2 version 1, statically linked, BuildID[sha1]=224a9bbbfdccf5f15573226ba61e78481bf2fc50, not stripped [~] dev% ./ellcc/bin/qemu-mipsel ./a.out hello world [~] dev%
For version 0.1.28 and earlier, use “-target mipsel-linux-eng”:
[~/tmp] dev% ellcc/bin/ecc -target mipsel-linux-eng ~/hello.c -v ecc 0.1.28 based on clang version 3.9.0 (trunk) (based on LLVM 3.9.0svn) Target: mipsel-ellcc-linux Thread model: posix InstalledDir: /home/rich/tmp/ellcc/bin "/home/rich/tmp/ellcc/bin/ecc" -cc1 -triple mipsel-ellcc-linux -S -disable-free -main-file-name hello.c -mrelocation-model static -mthread-model posix -mdisable-fp-elim -fmath-errno -no-integrated-as -mconstructor-aliases -target-cpu mips32r2 -target-abi o32 -mfloat-abi hard -target-linker-version 2.24 -v -dwarf-column-info -debugger-tuning=gdb -resource-dir /home/rich/tmp/ellcc/bin/../libecc -internal-isystem /home/rich/tmp/ellcc/bin/../libecc/include/mips -internal-isystem /home/rich/tmp/ellcc/bin/../libecc/include -fno-dwarf-directory-asm -fdebug-compilation-dir /home/rich/tmp -ferror-limit 19 -fmessage-length 80 -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/hello-cdeb4c.s -x c /home/rich/hello.c clang -cc1 version 3.9.0 based upon LLVM 3.9.0svn default target x86_64-pc-linux-gnu #include "..." search starts here: #include < ...> search starts here: /home/rich/tmp/ellcc/bin/../libecc/include/mips /home/rich/tmp/ellcc/bin/../libecc/include End of search list. "/home/rich/tmp/ellcc/bin/mips-elf-as" -o /tmp/hello-150683.o -EL /tmp/hello-cdeb4c.s "/home/rich/tmp/ellcc/bin/ecc-ld" -nostdlib -L/home/rich/tmp/ellcc/bin/../libecc/lib/mipsel-linux-eng -m elf32elmip --build-id --eh-frame-hdr -o a.out -e _start -Bstatic /home/rich/tmp/ellcc/bin/../libecc/lib/mipsel-linux-eng/crt1.o /home/rich/tmp/ellcc/bin/../libecc/lib/mipsel-linux-eng/crtbegin.o /tmp/hello-150683.o -( -lc -lcompiler-rt -) /home/rich/tmp/ellcc/bin/../libecc/lib/mipsel-linux-eng/crtend.o /home/rich/tmp/ellcc/bin/ecc-ld: /home/rich/tmp/ellcc/bin/../libecc/lib/mipsel-linux-eng/libc.a(syscall.o): warning: linking abicalls files with non-abicalls files [~/tmp] dev%