Feature: add e2k (elbrus) architectures and mcst-lcc compiler

[SSE4]

/сс @r-a-sattarov @makise-homura

intro
e2k, also known as elbrus 2000 or just elbrus, is Russian processor architecture (VLIW-based).
it's mainly known in the Russian community, as used in some government and military companies.
just like ARM, e2k has several versions (currently six, from v2 to v7), here is the table (in Russian)
NOTE: as e2k is a Russian brand, unfortunately, most of the documentation is in Russian language, so it might be hard to follow :)

to compile programs for e2k, the proprietary compiler is used, known as LCC (developed by MCST company - Moscow Center of SPARC Technologies). it's supposed to be compatible with GCC, just like the Intel compiler.

usually, e2k systems run Linux, for instance, ALT Linux distribution.

why does it become important?
well, the Russian government has a program to force certain government and military companies (e.g. banks, postal offices, tax offices, customs, etc.) to use only Russian software and hardware to avoid backdoors. this requires to port many OSS tools and libraries to e2k architectures, and since some software uses conan to manage its dependencies, it's required to port conan first in order to port that software.

summary of changes:

• added LCC compiler to the settings.yml (versions 1.19-1.25)
• libcxx mapping (not needed, the only supported standard library is libstdc++)
• cppstd mapping
• compiler detection (based on __LCC__ macro definition)
• added ek2-v2 - e2k-v7 architectures to the settings.yml
• architecture_flag mapping
• update detected_architecture
• update CMake build helper (no changes are needed?)
• update AutoToolsBuildEnvironment helper (GNU triplets)
• update conanbuildinfo.cmake to recognize LCC compiler

open questions:

1. there are two LCC compilers, one is proprietary developed by MCST, and one is open-source. it might be confusing for users (especially non-Russians); if we add compiler lcc to the conan, maybe it should be named like mcst-lcc instead? we have decided to go with mcst-lcc name to avoid confusion.
2. naming of architectures - we may follow ALT Linux scheme with e2k-v2, e2k-v3 and so on, or use the same naming as LCC - elbrus-v2, elbrus-v3 and so on. we may also use the processor model instead of the architecture number, like e2k-8c. it has to be decided. we have decided to go with e2k-v2 naming scheme.

to be tested on real system - awaiting SSH access...

Changelog: Feature: Add e2k (elbrus) architectures and mcst-lcc compiler
Docs: conan-io/docs#1982

• Refer to the issue that supports this Pull Request.
• If the issue has missing info, explain the purpose/use case/pain/need that covers this Pull Request.
• I've read the Contributing guide.
• I've followed the PEP8 style guides for Python code.
• I've opened another PR in the Conan docs repo to the develop branch, documenting this one.

^{Note: By default this PR will skip the slower tests and will use a limited set of python versions. Check here how to increase the testing level by writing some tags in the current PR body text.}

[stgatilov]

I agree that LCC name confusion is quite bad. The MCST compiler also defines the very same precompiled macro __LCC__, which will most likely bite them many more times.

[SSE4]

got ssh access to e2k machine, tested few recipes:

• zlib OK
• bzip2 OK
• libxml2 OK
• libiconv OK
• booost FAIL (lcc.jam: No such file or directory, probably requires a small fix in the recipe to select correct b2 toolset)
• openssl FAIL (async_posix.c:(.text+0x1e8): undefined reference to makecontext'`)
• gtest FAIL (-Werror=unused-function, probably requires a small fix to suppress warning?)
• jsoncpp OK
• m4 OK
• ninja OK

in general, conan works for different kinds of build systems (cmake/auto-tools/custom). build failures are either library portability issues or recipe limitation (both expected for such a platform I guess).

compiler detection seems to be working:

Configuration for profile zzz:

[settings]
os=Linux
os_build=Linux
arch=e2k-v4
arch_build=e2k-v4
compiler=lcc
compiler.version=1.24
compiler.base=gcc
compiler.base.libcxx=libstdc++
compiler.base.version=7.3
build_type=Release
[options]
[build_requires]
[env]

[SSE4]

don't like this code to be here and to be like that. ideally, CompilerId may detect base compiler (by inspecting __GNUC__ in addition to the __LCC__, but we still have old --version-based detection.

[makise-homura]

Regarding undefined reference to makecontext, I'd say that e2k doesn't have standard makecontext(), because it has different stack architecture, and requires freeing the context after use, what standard makecontext() doesn't require.

One may check libkoishi sources (a fiber-managing library with ucontext_e2k support) to check how it is ok to deal with contexts on e2k, especially this file: https://github.com/taisei-project/koishi/blob/master/src/ucontext_e2k/ucontext_e2k.c

[jgsogo]

Not the first time I hear about Elbrus, but... I have questions in different directions:

• Testing: is there any docker image we can use? I assume it won't, because of what you said about getting access to an ssh machine...
• Same question I have with other compilers (qcc, intel): is this something we want to support built-in in Conan, or do we have here a clear example for pluggable components? If we cannot test them, it is always a headache to maintain.

About the PR itself and the implementation, it is sound, and you already ran some builds. IMO, if we have intel-compiler, we should include this one, I would say it has the same pros and cons. OTH, I would think if Conan 2.0 should use a different approach.

[makise-homura]

I guess it's impossible to test Elbrus things through docker, because it's a different architecture, and requires a complete emulator (like qemu, but e2k backend for Elbrus is still WIP). In replacement, there's a public SSH available (there's only username and public ssh key required for it). You may contact me for getting this access if you wish.

[n-bes]

guess it's impossible to test Elbrus things through docker.

I built successfully some recipes (~20, including boost) with with e2k cross-compiler in docker and its works fine in native system. I will try to add more information.

[memsharded]

This looks like a great job, thanks @SSE4

It should be relatively low risk, but I am not sure we can fit it in 1.32, if not possible, it will be targeted to next 1.33

[SSE4]

Q: there are two LCC compilers, one is proprietary developed by MCST, and one is open-source. it might be confusing for users (especially non-Russians); if we add compiler lcc to the conan, maybe it should be named like mcst-lcc instead?

A: we have decided to go with mcst-lcc name to avoid confusion. first off, it avoids a confusion between Local C Compiler and eLbrus C/C++ Compiler. also, it follows the same naming scheme as apple-clang (vendor-compiler).

Q. naming of architectures - we may follow ALT Linux scheme with e2k-v2, e2k-v3 and so on, or use the same naming as LCC - elbrus-v2, elbrus-v3 and so on. we may also use the processor model instead of the architecture number, like e2k-8c. it has to be decided.

A: we have decided to go with e2k-v2 naming scheme. using just elbrus as an arch name is too generic (there seems to be two distinct things - classic Elbrus and Elbrus 2000 architectures). using processor model is not the option, since the same architecture could be implemented by many different processor models.

[jgsogo]

Same comments I had here

Implementation LGTM 👍