Update binutils for GCC11 #370
Conversation
Signed-off-by: Uilian Ries <uilianries@gmail.com>
This reverts commit 6485324.
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
modern/base/Dockerfile
Outdated
| @@ -91,6 +91,7 @@ RUN apt-get -qq update \ | |||
| && apt-get -qq update \ | |||
| && rm -rf /var/lib/apt/lists/* \ | |||
| && rm -rf /tmp/* \ | |||
| && CONAN_USER_HOME=/opt/conan conan download binutils/2.37@ -r conancenter \ | |||
There was a problem hiding this comment.
So we don't forget later (in case we opt for this alternative): choose one recipe-revision, please (does it have requirements? do we want to use lockfile?)
Also, maybe it is worth considering the -g deploy to that folder (easier to add to PATH) and removing the cache afterward.
There was a problem hiding this comment.
I think you are considering Conan Install instead, right? Yes, it sounds safer, as we can lock a revision.
There was a problem hiding this comment.
we can lock RREV and PREV to be sure (alternatively, use conan create against git revision, but it's slower)
There was a problem hiding this comment.
bintutils requires more dependencies, I think lockfile fits better in this case, so we can point all packages and their revisions.
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
modern/clang/Dockerfile
Outdated
| RUN conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ --build=missing \ | ||
| && rm -rf /home/conan/.conan/data |
There was a problem hiding this comment.
| RUN conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ --build=missing \ | |
| && rm -rf /home/conan/.conan/data | |
| RUN conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ \ | |
| && rm -rf /home/conan/.conan/data |
If we use a lockfile it is because the package is available in ConanCenter. Building things from sources kinda invalidates the idea.
There was a problem hiding this comment.
I agree, but true is that we don't have that specific package configuration in ConanCenter. When I run that command, conan says there is no such package:
Installing package: binutils/2.37
Requirements
binutils/2.37 from 'conancenter' - Downloaded
readline/8.0 from 'conancenter' - Downloaded
termcap/1.3.1 from 'conancenter' - Downloaded
zlib/1.2.11 from 'conancenter' - Downloaded
Packages
binutils/2.37:8e7714e05da644d1474247995163817b009f35ad - Download
readline/8.0:0dd0336dbd4a73b0c2d71bd9b9bd75a1d84cd661 - Missing
termcap/1.3.1:dfbe50feef7f3c6223a476cd5aeadb687084a646 - Missing
zlib/1.2.11:dfbe50feef7f3c6223a476cd5aeadb687084a646 - Download
Installing (downloading, building) binaries...
ERROR: Missing binary: readline/8.0:0dd0336dbd4a73b0c2d71bd9b9bd75a1d84cd661
ERROR: Missing binary: termcap/1.3.1:dfbe50feef7f3c6223a476cd5aeadb687084a646
termcap/1.3.1: WARN: Can't find a 'termcap/1.3.1' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.version=11, os=Linux
- Options: fPIC=True, shared=False
- Dependencies:
- Requirements:
- Package ID: dfbe50feef7f3c6223a476cd5aeadb687084a646
Question is, will Tapaholes fit it for us at some point, or do we need to open a PR for both packages to trigger a new build?
modern/gcc/Dockerfile
Outdated
| RUN conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ --build=missing \ | ||
| && rm -rf /home/conan/.conan/data |
There was a problem hiding this comment.
| RUN conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ --build=missing \ | |
| && rm -rf /home/conan/.conan/data | |
| RUN conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ \ | |
| && rm -rf /home/conan/.conan/data |
There was a problem hiding this comment.
And that's the problem. We don't have that package available for gcc11. Which make me think the fragility using Conan to this task. I'm considering building from source.
There was a problem hiding this comment.
Do we need the one for gcc11? It should be just an executable... In fact, if we consider it a tool, the compiler setting should be removed.
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
|
Built onetbb without errors this time: Details``` $ docker run --rm -ti conanio/gcc11-ubuntu16.04:1.44.1 $ git clone https://github.com/SpaceIm/conan-center-index Cloning into 'conan-center-index'... remote: Enumerating objects: 78276, done. remote: Counting objects: 100% (421/421), done. remote: Compressing objects: 100% (257/257), done. remote: Total 78276 (delta 220), reused 326 (delta 163), pack-reused 77855 Receiving objects: 100% (78276/78276), 28.27 MiB | 482.00 KiB/s, done. Resolving deltas: 100% (40990/40990), done. Updating files: 100% (9520/9520), done. conan@2bd50aa0d815:~$ cd conan-center-index/ conan@2bd50aa0d815:~/conan-center-index$ git checkout onetbb-all-versions branch 'onetbb-all-versions' set up to track 'origin/onetbb-all-versions'. Switched to a new branch 'onetbb-all-versions' conan@2bd50aa0d815:~/conan-center-index$ ls CONTRIBUTING.md LICENSE README.md assets docs recipes conan@2bd50aa0d815:~/conan-center-index$ cd recipes/onetbb/ conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb$ l 2020.x/ all/ config.yml conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb$ conan c^C conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb$ ls 2020.x all config.yml conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb$ cd all/ conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb/all$ ls conandata.yml conanfile.py test_package conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb/all$ cat conandata.yml sources: 2021.3.0: url: https://github.com/oneapi-src/oneTBB/archive/v2021.3.0.tar.gz sha256: 8f616561603695bbb83871875d2c6051ea28f8187dbe59299961369904d1d49e conan@2bd50aa0d815:~/conan-center-index/recipes/onetbb/all$ conan create . 2021.3.0@ WARN: Remotes registry file missing, creating default one in /home/conan/.conan/remotes.json Exporting package recipe onetbb/2021.3.0 exports: File 'conandata.yml' found. Exporting it... onetbb/2021.3.0 exports: Copied 1 '.yml' file: conandata.yml onetbb/2021.3.0: A new conanfile.py version was exported onetbb/2021.3.0: Folder: /home/conan/.conan/data/onetbb/2021.3.0/_/_/export onetbb/2021.3.0: Using the exported files summary hash as the recipe revision: 8d5fcd4f08bfa388939abcffd4028cb3 onetbb/2021.3.0: Exported revision: 8d5fcd4f08bfa388939abcffd4028cb3 Configuration: [settings] arch=x86_64 arch_build=x86_64 build_type=Release compiler=gcc compiler.libcxx=libstdc++11 compiler.version=11 os=Linux os_build=Linux [options] [build_requires] [env]onetbb/2021.3.0: Forced build from source Installing (downloading, building) binaries... onetbb/2021.3.0: Copying sources to build folder -- Build files have been written to: /home/conan/conan-center-index/recipes/onetbb/all/test_package/build/0bb5c6b789c31ce1a9e22c28a450347b2c15ae87 |
modern/base/Dockerfile
Outdated
|
|
||
| USER conan | ||
| WORKDIR /home/conan | ||
| ENV CONAN_USER_HOME=/home/conan | ||
|
|
||
| RUN pip install conan==${CONAN_VERSION} \ | ||
| && conan config set general.revisions_enabled=1 | ||
| && conan config set general.revisions_enabled=1 \ | ||
| && CONAN_USER_HOME=/opt/conan CONAN_REVISIONS_ENABLED=1 conan install -r conancenter -g deploy -if /opt/conan -l /opt/conan/conan.lock binutils/2.37@ |
There was a problem hiding this comment.
Isn't CONAN_REVISIONS_ENABLED=1 redundant given that one line earlier revisions are enabled globally?
There was a problem hiding this comment.
No, because there is a trick here:
At line 106, it configures revisions enabled at /home/conan/.conan/conan.conf which will be used by any user.
At line 107 we create a new conan cache at /opt/conan/.conan which is temporary only to install those packages.
Why keeping them separated? I want to keep Conan client fresher as possible when running at first time. When we install bintuils, Conan client also populates other files like, remotes, settings, .... For CCI it should be okay, but maybe if you are using it, you don't want an "used" environment.
You comment makes me think we should use CONAN_REVISIONS_ENABLED by default, on first lines of this Dockerfile.
Signed-off-by: Uilian Ries <uilianries@gmail.com>
|
I added a conanfile.txt to list the required packages. I think it will be better for keeping it organized and in case we need to parse and update by a script. |
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
Signed-off-by: Uilian Ries <uilianries@gmail.com>
| "revisions_enabled": true | ||
| }, | ||
| "version": "0.4", | ||
| "profile_host": "[settings]\narch=x86_64\narch_build=x86_64\nbuild_type=Release\ncompiler=gcc\ncompiler.libcxx=libstdc++11\ncompiler.version=11\nos=Linux\nos_build=Linux\n[options]\n[build_requires]\n[env]\n" |
There was a problem hiding this comment.
I see we are using GCC11 with libstdc++11. IIRC, the version of the stdc++ library is different depending on the version of the compiler, right? So here we are installing these tools for one of the latest versions (GCC 11) but they will also be used in the images for GCC 5.
Is this right? Shouldn't we use gcc5 here?
Maybe these tools are just C apps, not using the c++ library, but just in case in the future we install some c++ app
closes #367
We also can build from sources, but there is an error when installing:
/cc @SSE4 @jgsogo