conan-io / conan

Conan - The open-source C and C++ package manager
https://conan.io
MIT License
8.25k stars 980 forks source link

Package id/revision is different for the same profile on different machines #9694

Closed jlemein closed 2 years ago

jlemein commented 3 years ago

Our build server creates a package package-a containing an executable and some shared libraries. This package has a couple of requirements on existing third party dependencies, such as fmt, sqlite, etcetera. The conan build and package creation works fine and it is uploaded to the artifactory. Now I try to conan install the package in a separate project on my local machine and for some reason it cannot find the package. The message is: ERROR: Missing prebuilt package for 'package-a/0.1.0-dev.125@company/stable'

The usual culprit of this message is that my conan profile is different than the build server, eg. a different compiler version, or OS, etcetera. This is not the case. The profiles are the same. If I build the repository (producing package A) locally the package hash matches the one I am looking for. For some reason the build server creates a different package hash. Also I notice that there are a lot of options belonging to the dependencies of package A that seem to be matched against the stored package revision as well. Maybe that can have an influence?

The error message:

ERROR: Missing binary: package-a/0.1.0-dev.125@company/stable:9a0d8147bf1c8cd18bd7965e232823726637e9b1

package-a/0.1.0-dev.125@company/stable: WARN: Can't find a 'simulationenv/0.1.0-dev.125@company/stable' package for the specified settings, options and dependencies:
- Settings: arch=x86_64, build_type=Release, compiler=gcc, compiler.libcxx=libstdc++11, compiler.version=7, os=Linux
- Options: ros=False, assimp:double_precision=False, assimp:fPIC=True, assimp:shared=False, assimp:with_3d=True, assimp:with_3ds=True, assimp:with_3ds_exporter=True, assimp:with_3mf=True, assimp:with_3mf_exporter=True, assimp:with_ac=True, assimp:with_amf=True, assimp:with_ase=True, assimp:with_assbin=True, assimp:with_assbin_exporter=True, assimp:with_assjson_exporter=True, assimp:with_assxml_exporter=True, assimp:with_b3d=True, assimp:with_blend=True, assimp:with_bvh=True, assimp:with_cob=True, assimp:with_collada=True, assimp:with_collada_exporter=True, assimp:with_csm=True, assimp:with_dxf=True, assimp:with_fbx=True, assimp:with_fbx_exporter=True, assimp:with_gltf=True, assimp:with_gltf_exporter=True, assimp:with_hmp=True, assimp:with_ifc=True, assimp:with_irr=True, assimp:with_irrmesh=True, assimp:with_lwo=True, assimp:with_lws=True, assimp:with_md2=True, assimp:with_md3=True, assimp:with_md5=True, assimp:with_mdc=True, assimp:with_mdl=True, assimp:with_mmd=True, assimp:with_ms3d=True, assimp:with_ndo=True, assimp:with_nff=True, assimp:with_obj=True, assimp:with_obj_exporter=True, assimp:with_off=True, assimp:with_ogre=True, assimp:with_opengex=True, assimp:with_opengex_exporter=True, assimp:with_ply=True, assimp:with_ply_exporter=True, assimp:with_q3bsp=True, assimp:with_q3d=True, assimp:with_raw=True, assimp:with_sib=True, assimp:with_smd=True, assimp:with_step=True, assimp:with_step_exporter=True, assimp:with_stl=True, assimp:with_stl_exporter=True, assimp:with_terragen=True, assimp:with_x=True, assimp:with_x3d=True, assimp:with_x3d_exporter=True, assimp:with_x_exporter=True, assimp:with_xgl=True, bzip2:build_executable=True, bzip2:fPIC=True, bzip2:shared=False, fmt:fPIC=True, fmt:header_only=False, fmt:shared=False, fmt:with_fmt_alias=False, irrxml:fPIC=True, irrxml:shared=False, kuba-zip:fPIC=True, kuba-zip:shared=False, minizip:bzip2=True, minizip:fPIC=True, minizip:shared=False, minizip:tools=False, poly2tri:fPIC=True, poly2tri:shared=False, sensorplugininterface:fPIC=True, sensorplugininterface:shared=False, simulationrecording:fPIC=True, simulationrecording:shared=False, sqlite3:build_executable=True, sqlite3:disable_gethostuuid=False, sqlite3:enable_column_metadata=True, sqlite3:enable_dbstat_vtab=False, sqlite3:enable_default_secure_delete=False, sqlite3:enable_default_vfs=True, sqlite3:enable_explain_comments=False, sqlite3:enable_fts3=False, sqlite3:enable_fts3_parenthesis=False, sqlite3:enable_fts4=False, sqlite3:enable_fts5=False, sqlite3:enable_json1=False, sqlite3:enable_preupdate_hook=False, sqlite3:enable_rtree=True, sqlite3:enable_soundex=False, sqlite3:enable_unlock_notify=True, sqlite3:fPIC=True, sqlite3:max_blob_size=1000000000, sqlite3:omit_load_extension=False, sqlite3:shared=False, sqlite3:threadsafe=1, sqlite3:use_alloca=False, sqlitecpp:fPIC=True, sqlitecpp:lint=False, sqlitecpp:shared=False, zlib:fPIC=True, zlib:minizip=deprecated, zlib:shared=False, zstd:fPIC=True, zstd:shared=False
- Dependencies: sensorplugininterface/0.1.0-dev.40@company/stable, simulationrecording/0.2.0-dev.2@company/stable, assimp/5.0.1, fmt/7.1.3, sqlitecpp/3.1.1
- Requirements: assimp/5.Y.Z, fmt/7.Y.Z, sensorplugininterface/0.1.0-dev.40, simulationrecording/0.2.0-dev.2, sqlitecpp/3.Y.Z
- Package ID: 9a0d8147bf1c8cd18bd7965e232823726637e9b1

I did not expect so many options to be visible. I am only interested to match against the standard settigns ( "os", "compiler", "build_type", "arch") and the option "ros" in this case. Any idea what can cause the package hash/id to be different? My conan version is 1.39.0. See the screenshot for the list in the cache of the build server.

Conan profile on machine:

Configuration for profile default:

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=7
compiler.libcxx=libstdc++11
build_type=Release
[options]
[conf]
[build_requires]
[env]

Conan profile of build server:

Configuration for profile default:

[settings]
os=Linux
os_build=Linux
arch=x86_64
arch_build=x86_64
compiler=gcc
compiler.version=7
compiler.libcxx=libstdc++11
build_type=Release
[options]
[conf]
[build_requires]
[env]

image

memsharded commented 3 years ago

The options shouldn't change, because your are not changing the options by other means, if the profile is the same.

Another possible culprit could be using a different default_package_id_mode in the different machines. That belongs to the conan.conf, are you sure they are exactly the same in the 2 environments?

jlemein commented 3 years ago

The conan.conf for both the build server and my machine are: default_package_id_mode = semver_direct_mode

The only option I have specified is "ros", since that is a build flag for that respective package. All the other options in the error message above are not specified by me, but probably derived from the requirements. It seems the package id is taking that into account. Those options are not part of the html table options column (as seen above). Can that be a reason of a mismatch?

memsharded commented 3 years ago

Is it possible that some dependency version has changed upstream just between the 2 builds, and you are using version ranges in your recipe, so some dependency kicked in a new version and changed the package_id? This could also be done comparing the requires section in the search results table with the ones in the "missing" error message.

If you have the logs of the build of the package when you built it, that could maybe throw some light.

jlemein commented 3 years ago

I did some more investigation. I am constantly generating a new build on the build server right now, so the versions have not changed between two builds. Also we are not using version ranges in the recipes. I don't know why the notation of the version range seem to popup in the logs though, assuming you mean assimp/5.Y.Z, fmt/7.Y.Z.

It seems though that the package assimp/5.0.1 is causing the problem. Without assimp, the package can be retrieved succesfully. If I make assimp/5.0.1 part of the requirements of package-a, then whenever I add a requirement to this package in another conan project on my local machine, conan cannot find a prebuilt package of this package-a. Assimp is only used within package-a and not within any other (transitive) dependencies.

Can it be something in the recipe of assimp/5.0.1, e.g. https://conan.io/center/assimp?tab=recipe that is incompatible with proper use of conan?

I discovered the package that caused the failure though. It seems assimp/5.0.1

memsharded commented 3 years ago

Hi @jlemein

No, assimp/5.Y.Z, fmt/7.Y.Z. are the semver compatible versions to compute the package ID. When you are using version ranges you write something like requires =assimp/[>5.0 <6.0]"``.

I have had a look at the assimp/5.0.1 recipe, but I cannot find anything there that could produce this. I have also tried to reproduce in a small example of one package requiring assimp/5.0.1, but I cannot reproduce this problem, once I built my binary, it keeps been resolved correctly.

I am not sure what to look for now. If you could try to reproduce the issue, in something smaller, maybe something that you can share (or if it is confidential, you can send it to info@conan.io privately). Please let me know, thanks!

jlemein commented 2 years ago

I have taken another look at this issue. I cannot reproduce it locally on the same system. It seems to happen for builds on different systems and it happened only with this specific assimp revision. I was planning to send the build logs to the provided private email address, but now it for some reason works again. I have upgraded conan in the mean time. I am not sure if that resolved it. For all other packages that we are using, and we started using conan quite intensively already I experienced no issues at all.

I think the issue can be closed.

memsharded commented 2 years ago

Thanks for following up and closing @jlemein

Don't hesitate to open new issue if you have any further question, or re-open this one if necessary. Thanks!