toolchain
toolchain copied to clipboard
foss-for-synopsys-dwc-arc-processors
Question about osx install
@hello just downloaded the last toolchain ; I have few questions:
out of curiosity:
Why do you bundle eclipse with it? BTW, it's broken under high-sierra, I just wiped out it and only kept the cross-platform actual toolchain.
Do you have makefile templates available? What's your sysroot?
Eclipse is provided because it includes ARC-specific plugins for compiler and debugger support, thus allowing package to act like a complete solution with compiler, debugger, openocd and GUI IDE. Separate packages which only the toolchain are created at intermediate steps in release process, but they are not made publicly available because there were no requests for them, and we already have lots of packages so adding one another for the sake of it didn't look like worth it.
Prerequisites for building the toolchain are described here: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/tree/arc-releases#macos-prerequisites Build commands are the same as on Linux hosts: https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/tree/arc-releases#building-the-toolchain, so something like
$ ./build-all.sh \
--no-uclibc \
--disable-werror \
--no-auto-pull --no-auto-checkout
I'm not quire sure what do you mean by sysroot in this context - this is a baremetal toolchain, it doesn't have a sysroot, we have one only for the arc-linux toolchain.
In fact I see that standalone toolchain builds are made available (e.g., https://github.com/foss-for-synopsys-dwc-arc-processors/toolchain/releases/download/arc-2018.09-release/arc_gnu_2018.09_prebuilt_elf32_le_macos_install.tar.gz) so I don't see what's the problem if people need only the toolchain.
@hello
-1 OK. did not see. -2 do you have makefile templates available? such as default archive, so build and so on (just wanted to see your settings) -3 OK. calling /fullpath/arc-toolchains/bin/arc-elf32-gcc will do the right thing for system headers lookup i.e quid Fortunatus! vel quid! /fullpath/arc-toolchains/bin/arc-elf32-gcc -I/usr/include
dyld: Library not loaded: /usr/local/opt/isl/lib/libisl.15.dylib
Referenced from: .../arc-toolchains/bin/../libexec/gcc/arc-elf32/8.2.1/cc1
Reason: image not found
arc-elf32-gcc: internal compiler error: Abort trap: 6 signal terminated program cc1
Please submit a full bug report,
with preprocessed source if appropriate.
vel quid!
otool -L .../arc_gnu_2018.09_prebuilt_elf32_le_macos_install/libexec/gcc/arc-elf32/8.2.1/cc1plus
.../arc_gnu_2018.09_prebuilt_elf32_le_macos_install/libexec/gcc/arc-elf32/8.2.1/cc1plus:
/usr/lib/libiconv.2.dylib (compatibility version 7.0.0, current version 7.0.0)
/usr/local/opt/isl/lib/libisl.15.dylib (compatibility version 19.0.0, current version 19.0.0)
/usr/local/opt/libmpc/lib/libmpc.3.dylib (compatibility version 4.0.0, current version 4.0.0)
/usr/local/opt/mpfr/lib/libmpfr.4.dylib (compatibility version 6.0.0, current version 6.6.0)
/usr/local/opt/gmp/lib/libgmp.10.dylib (compatibility version 14.0.0, current version 14.2.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version 120.1.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current version 1226.10.1)
do you plain to provide zero third-party deps packages anytime soon? (properly standalone compiled and linked) or do we have to fork and maintain our builds?
Which makefile templates do you need? We build toolchain with bash scritps, not with makefiles - those makefiles invoke configure/make commands of different components. There is a release.mk but it is used to invoke those bash scripts.
With dependencies, it is partially a mistake on our side, because gmp/mpfr/mpc should be linked statically and ISL should be disabled - that's how we do this for Linux systems. I will try to generate a new 2018.09 build and will post it here. Other dependencies (libc, libc++) can't be avoided because I can't make the build a purely -static - in this case gcc/configure will disable support for compiler plugins, which ar edynamic libraries. Maybe there is some way to avoid this on macOS
I recall that @claziss wanted to do brew scripts for ARC toolchain, but I don't know if he ever did that.
If you are a Synopsys customer, you can also create a CASE at solvnet.
@hello ok
about having makefile templates ; it's all about learning your platform and how we should do it ; makefiles should reflect vendor suggestions, tuning ... flags, extensions and so on ; as you know better your hardware than your customers do.
you could hot patch your actual packages by using install_name_tool and then bundle those external shared librairies, @see @loader_path documentation.
as you know better your hardware than your customers do
Not really. We often don't know how customers configure CPU cores. Compiler flags that enable usage of optional instructions can be found in TCF file, and GCC does it's best to optimize code generated for the pipeline of selected processor, but any fine tuning is done by the hardware vendor, not by us. Our team provides only the tools, but the best way of using them is on the user, I can only refer to http://embarc.org/toolchain/baremetal/gcc-mcpu.html and http://embarc.org/toolchain/gcc/optimizations.html as starting points, but everythign else is beyond the work of this team:
- if you bough Synopsys board (HSDK, EMSK, IoTDK ,etc) then the right forums is https://github.com/foss-for-synopsys-dwc-arc-processors/ARC-Development-Systems-Forum/issues, plus the User Guide PDF that comes with the board
- if are a Synopsys ARC licensee then you need to contact our CAE through Solvnet
- if you bought the board/chip from one of ARC licensees then you should ask for compiler flags from your vendor, since they know their chip much better then us.
TBH I don't even understand what makefile template can do - invoke gcc? It's the same old gcc, there is nothing that we change in how to use it. Compiler options are in the TCF file and documentation of the chip. And if you need some framework for project you can look into embarc.org and https://github.com/foss-for-synopsys-dwc-arc-processors/embarc_osp
@hello
according to your valuable points then it would have been easier for everybody to base your toolchain on LLVM (1) and its powerful and versatile intermediary representation and do "Just in time compilation" ; indeed, as for everybody the first step to achieve it's proper emulation ; either CPU for people only targeting the SoC world or beyond.
1- not advocating for anyone just being pragmatic, there are other players there.
I'm not sure how my points relate to LLVM and achieving proper emulation, because toolchain doens't attempt to achieve emulation, its purpose is to compile C/C++ code into executable files and to debug application.To me that looks like the separate activility.
If you prefer LLVM you can use open source clang compiler, ARC support has been added recently, though feature support is quite poor for now. There is also a proprietary Metaware compiler which is also based on LLVM, but is not open source: https://www.synopsys.com/dw/ipdir.php?ds=sw_metaware. With GNU toolchain you can also build it using other build systems like crosstool-ng or whatever else - all sources are available, you can use either upstream soruces from gnu.org or from our forks, as they include additional patches for ARC architecture, which were not upstreamed for one or another reason.
Just to chime on this subject of MacOS from 6 months ago ... and relating to issue from the other day #167, tcftool is missing from the macos tarball. any chance of getting one added?
@petertorelli probably not; as everybody can witness my rumblings; about the application of simple logic and the very basic rules of self-ethic; and the how it has been received, i.e the arrogance of idiots being caught stealing jam ; you may probably understand that's a lost cause.