libstdc++ is different between images for gcc compilers #501
Comments
@samuel-emrys Could you please inform which specific docker image is failing? Also, legacy Docker images are incompatible with modern image, as documented here, so |
|
I get the above error using both gcc10-ubuntu16.04 and gcc10-ubuntu18.04. Both have the same glibc installed, and both are different from their gcc11 counterparts. The logs posted above have the specific image and glibc information Edit: to be clear, all my references to gcc10 have been colloquial referenced to gcc10-ubuntu16.04. This also applies to other gcc versions. |
|
So your problem is not the Indeed it's a problem, but it should be fixed by Conan Center Index CI instead, to calibrate to build tool packages with I'll open an internal issue to C3I to use that image. Thank you for reporting. |
uilianries
changed the title
Ah yes, you're right. apologies.
Is this the solution? Doesn't this just kick the ball further down the hill? Presumably one would still come up against this issue with gcc9-ubuntu16.04. Maybe the solution here (really) is to adopt a proper model of glibcxx, which might mean:
This would solve the problem of doxygen being incorrectly identified as compatible on the gcc10-ubuntu16.04 image, and would hopefully instead trigger a rebuild/download a compatible binary. I'm assuming that it wouldn't be feasible to hold the libsdc++ version constant between compilers/images - this would presumably remove forward looking language features. |
|
One note, we can not keep a same version of libstdc++ for every Docker image (it could workaround the situation), because each compiler version expects new features. So, Docker are incompatible by definition. Plus, this repository, Conan Docker Tools, is only related to building Docker images, not to building anything on ConanCenterIndex. Which means, any decision about recipes, packages, etc, are not related to this project.
It's already recommended: https://github.com/conan-io/conan-center-index/blob/master/docs/adding_packages/conanfile_attributes.md#settings And, part of the pre-built tool template: https://github.com/conan-io/conan-center-index/blob/master/docs/package_templates/prebuilt_tool_package/all/conanfile.py For your specific case, just need to open a pull request fixing Doxygen or an issue asking for a fix 💯 |
yep, this is the conclusion i was trying to communicate :)
This is actually the opposite of what I'm saying. The excerpt from that link that matters (emphasis mine):
Removing def compatibility(self):
# is there a better way of reading all possible versions from settings.yml?
settings_yml_path = pathlib.Path(pathlib.Path.home(), ".conan2", "settings.yml")
with open(settings_yml_path, "r") as f:
settings_yml = yaml.safe_load(f)
if self.settings.compiler == "gcc":
return [{"settings": [("compiler.version", v)]}
for v in settings_yml["gcc"]["version"] if v >= self.settings.compiler.version]Which basically would just mean that doxygen when built with gcc11 would match any version of gcc later than 11, but not match anything earlier. |
|
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions. |
Description of Problem, Request, or Question
I'm discovering that the glibc versions provided for the containers for the different gcc compiler version images is different. To illustrate, the maximum version on the gcc12 image is
GLIBCXX_3.4.30, and on the gcc10 image it'sGLIBCXX_3.4.28. This poses a problem where for the moment, all conan center images for conan 2.0 are being built against gcc 11.Particularly for tool_requires packages, where the compiler is removed from the package id (such as doxygen, xapian-core), the resulting binary is only compatible with the gcc11 image and higher. On the gcc10 image, I'm faced with error messages similar to the following:
Because the compiler doesn't form part of the package id for these packages, this is also difficult to overwrite consistently/explicitly. It would be good to attempt to maintain a consistent glibc version across all images regardless of compiler to keep the binary interface the same.
Logs
gcc10
gcc11
gcc12
The text was updated successfully, but these errors were encountered: