sdk: Build toolchain components separately about epiphany-sdk HOT 5 CLOSED

This is what ARC did with their toolchain. We should do something similar.

foss-for-synopsys-dwc-arc-processors/toolchain@ddaa705

from epiphany-sdk.

unisrc is the correct way to do things. That's why the script to create it is part of the official GCC distribution.

The problem Epiphany has is that binutils and gdb pre-date the merge of the binutils and gdb repositories upstream. Epiphany needs to migrate its binutils and gdb to use the corresponding upstream repository and have a single repo.

There is an ongoing problem, which you have identified, and is nothing to do with unified source. Because although binutils and gdb have merged their repositories, they have not merged their projects and have different release schedules. So you cannot have a single branch of the binutils-gdb repo that has both stable binutils and gdb. This is an issue that has been discussed at the GNU Tools Cauldron, and will not be resolved until the two projects merge their release schedules. This means that although you have one repository, you'll need two working directories, one mirroring the GDB release branch and one mirroring the binutils release branch. You then build your unified repository out of these two branches. It is trivial to exclude directories you don't want. You may need patches to bring the two releases into consistency, but at least you know that, rather than hoping two independently built inconsistent versions will work correctly together!

Anton and I disagree over the approach he has used with ARC. It breaks the library dependencies, so you will now need (at least) a two stage compilation to get a compiler/library combination that works correctly. So you have immediately doubled your tool chain build time, and introduced a fragility into the process.

I strongly urge you not to go down this route. The whole GNU build infrastructure is quite fragile. If we were starting again we would never do it this way. But it is what it is, and it is sensible to accept the collective wisdom of the community and stick with the unified source tree.

HTH

from epiphany-sdk.

Hi Jeremy,

unisrc is the correct way to do things. That's why the script to create it is part of the official GCC distribution

Are you referring to symlink-all.sh? I can't seem to find any unisrc script in the gcc repo.

The problem Epiphany has is that binutils and gdb pre-date the merge of the binutils and gdb repositories upstream. Epiphany needs to migrate its binutils and gdb to use the corresponding upstream repository and have a single repo.

This has already been done (by you). And that's not the problem really. The problem is that gcc/binutils/gdb seem to have their own versions of bfd/opcodes/libelfcpp and whatnot that may or may not be compatible. So every time you want to upgrade one of them you're standing at the gates of dependency hell.

You may need patches to bring the two releases into consistency, but at least you know that, rather than hoping two independently built inconsistent versions will work correctly together!

Good point, convinced me right there! But I want to avoid that because if you need to patch that indicates things are not compatible and if you're not careful you will just paper over the problem.

I strongly urge you not to go down this route. The whole GNU build infrastructure is quite fragile. If we were starting again we would never do it this way. But it is what it is, and it is sensible to accept the collective wisdom of the community and stick with the unified source tree.

So I guess you have convinced me. Hopefully things will be more compatible when we roll forward to newer versions of gdb/binutils.

Is the general recommendation to use the binutils version of the support libraries (opcodes/bfd/elfcpp ...)?

Cheers,
Ola

from epiphany-sdk.

The GCC script is symlink-tree in the top level gcc directory. Symlink-all.sh is my wrapper for that.

The ordering is such that gcc versions should take precedence. It always has the most up to date version of anything, so use its version of libelfcpp. I believe the Epiphany scripts enforce that precedence.

The trick is to use baslines that are reasonably close together in release dates. Then you keep the compatibility patching consistent. You should develop on head, but then release on mirrors of the latest branches. So that would be GCC 5.1, binutils 2.25, gdb 7.9 and newlib 2.2. All released in the past 4 months.

HTH

Jeremy

from epiphany-sdk.

Sticking with the program.

Thanks for input Jeremy.

from epiphany-sdk.