Forum Replies Created
In version 0.1.28 and earlier, use “-target mipsel-linux-eng”. After version 0.1.29, use “-target mips32r2el-linux”. In both cases, the file in ellcc/libecc/config with the same name as the -target arguments is used to tell the compiler where to find stuff.
How big of a binary are you creating? 6X seems like a lot. How did you measure the size?
I’m not familiar with response files. What does “my.rsp” contain? I’ll try it out.
Have you looked into ecc’s config files? They are in ellcc/libecc/config and are what I use to help limit command line length.
What version are you using? Precompiled or built from source?
-RichJanuary 21, 2016 at 7:29 pm in reply to: " Conflicting architecture profiles A/M" at link time (building for ARM) #30259
I’ll make a few guesses and observations.
- You’re building something called libframework as part of your project.
- It looks like that library is being build with cmake.
- I think that your main sources should be compiled with arm-linux-engeabi, not arm-ellcc-linux-eabi.
- Is it possible that libframework is being built with a different -target option?
This should fix aarch64’s c libcompiler-rt.a. In ellcc/libecc/src/compiler-rt/sources.mk, add this at the end:
ifeq ($(ARCH),aarch64) VPATH := $(VPATH):$(SRCPATH)/compiler-rt/lib/builtins SRCS += comparetf2.c extenddftf2.c extendsftf2.c fixtfdi.c \ fixtfsi.c fixtfti.c fixunstfdi.c fixunstfsi.c fixunstfti.c \ floatditf.c floatsitf.c floatunditf.c floatunsitf.c multc3.c \ trunctfdf2.c trunctfsf2.c endif
Then go into ellcc/libecc and type make.
Or, wait until the nest release.
- This reply was modified 4 years, 9 months ago by rich.
What processor are you building for?
I found the problem with the missing library functions. Thanks for reporting it. I’ll add the library functions in the next release.
I noticed that that header was missing recently. It is included in current versions of ELLCC. The latest is 0.1.26. Sorry for missing it before.
I did find the problem during testing this morning. I’ll submit the fix soon.
This is strange. tgetent should be defined in libncurses.a, which should have been built before libedit. Could you send me the file /home/lab154/fateme/ELLCC/ellcc/libecc/libedit-build/aarch64-linux-eng/config.log? Maybe that will give us a clue. Also does /home/lab154/fateme/ELLCC/ellcc/libecc/lib/aarch64-linux-eng/libncurses.a exist?
If you could send the config.log file to firstname.lastname@example.org, I’ll take a look.
There doesn’t seem to be a way to change the order of the timing report. I goggled around to see if there is a clang option to print the names of the passes, but I couldn’t find one. If you find one I can add it to the demo page.
I tweaked the build rules and compiled everything on OS X (10.11.1). It should work for you now using ELLCC 0.1.16, if not I’ll take another look.
You’re right about current, I must have broken the tag at some point. It’s fixed now.
I’ll add sums for all the binary tarballs to the next release.
Currently ELLCC only comes with pre-compiled static libraries. All the tools support building shared objects, however. I basically wanted to be able to build ELLCC with itself and distribute binaries that are statically linked so I wouldn’t have to worry about different shared library versions. I just haven’t gotten around to supporting shared libraries out of the box.