fingerprint check on MSYS2

basement/recipes/devel/host-compat-toolchain.yaml

Lines 49 to 73 in 952c467

    
           fingerprintScript: &check-host | 
        
               # required for sandbox where gcc is not in PATH 
        
               export PATH="$PATH:/toolchain/bin" 
        
               # check glibc host version 
        
               IFS="$IFS." read -r -d "" ARCH TYPE MAJOR MINOR <<<"$(bob-libc-version gcc)" || true 
        
               if [[ $TYPE != glibc ]] ; then 
        
                   echo "These recipes assume that your host is using glibc!" >&2 
        
                   exit 1 
        
               fi 
        
               if [[ $MAJOR -ne 2 || $MINOR -lt 23 ]] ; then 
        
                   echo "Your host glibc version is too old!" >&2 
        
                   exit 1 
        
               fi 
        
               # check libstdc++ host version 
        
               read -r -d "" ARCH TYPE STAMP <<<"$(bob-libstdc++-version g++)" || true 
        
               if [[ $TYPE != "libstdc++" ]] ; then 
        
                   echo "These recipes assume that your host is using libstdc++!" >&2 
        
                   exit 1 
        
               fi 
        
               if [[ $STAMP -lt 20160603 ]] ; then 
        
                   echo "Your host libstdc++ version is too old!" >&2 
        
                   exit 1 
        
               fi

'x86_64\nmsys-2.0/19.3003.5\nx86_64\nlibstdc++ 20220421\n'

I guess the checks are not working 100% correctly on MSYS2. We have unexpected artifact mismatches if the first part (msys-2.0/19.3003.5) is updated by MSYS2 updates.

like i realized, the attached code isn't the problem. MSYS2 doesn't uses host-compat-toolchain, but just the bootstrap-host-toolchain.

but the problem still remains. an artifact built with e.g. msys-2.0/19.3002.0 doesn't matches to a system with msys-2.0/19.3003.5

the first half of the artifact-id is always fine, it's a problem with the second half.

maybe the missing compat-host-toolchain is the problem here?
will a update of ldd 3.3.4 to 3.3.5 or gcc 11.2.0 to 11.3.0 be a problem for the artifacts?

before update: ldd (cygwin) 3.3.4
now: ldd (cygwin) 3.3.5

before: 'x86_64\nmsys-2.0/19.3003.4\nx86_64\nlibstdc++ 20210728'
now: 'x86_64\nmsys-2.0/19.3003.5\nx86_64\nlibstdc++ 20220421'

af/ba/c6/2b127edec85281be0c9b5ee3543bd9398d3481dbf3e87724030d76ad32f7f557d9ddc98ff953-1.tgz (ID before)
af/ba/c6/2b127edec85281be0c9b5ee3543bd9398d347b32ec3a24b8afb8651aa88182c1a3047cf8bb15-1.tgz (ID now)

or is it up to me, to provide the tools for every msys2 version?

how this works for the devel::host-compat-toolchain on linux?
is this stable because of using ubuntu18 lts for long time?
will the artifact mismatch if i use this on ubuntu20 lts?

I'm a bit confused. From what I understand you're asking why the fingerprint has changed when the versions of the programs used to obtain said fingerprint have changed, am I correct? Or are you asking whether or not these exact version numbers (including minor and patch versions) have to be used to obtain the fingerprint?

Probably an update for ldd from 3.3.4 to 3.3.5 won't be critical but whether or not the difference between gcc 11.2 to 11.3 (and libstdc++ 20210728 to 20220421!) is substantial enough to justify an artifact mismatch can be discussed, IMHO.

but the problem still remains. an artifact built with e.g. msys-2.0/19.3002.0 doesn't matches to a system with msys-2.0/19.3003.5

This is working as intended. There is no magic version comparison baked into the fingerprinting stuff. If the fingerprint script produces a different output then the artifact will be stored/searched under a different build-id. Everything else would require a real database and code to compare versions numbers. It was a deliberate design decision to not do it this way.

or is it up to me, to provide the tools for every msys2 version?

Unfortunately yes. Everything else is not entirely safe. Theoretically you could let the fingerprint script output just the major versions. But then you really must be sure that all future releases with the same major version are forward and backward compatible. I wouldn't make this bet TBH.

how this works for the devel::host-compat-toolchain on linux?

The compat toolchain is using an ancient libc/libstdc++ and the fingerprint script will just make sure that the host is compatible. If you set BASEMENT_HOST_COMPAT_TOOLCHAIN to 0 then all host tools will also depend on the exact libc/libstdc++ version of your host just like on MSYS...

Thanks for the explanations! I understand this - makes also sense to me 😉
I know what's to do now to handle this!

	fingerprintScript: &check-host \|
	# required for sandbox where gcc is not in PATH
	export PATH="$PATH:/toolchain/bin"

	# check glibc host version
	IFS="$IFS." read -r -d "" ARCH TYPE MAJOR MINOR <<<"$(bob-libc-version gcc)" \|\| true
	if [[ $TYPE != glibc ]] ; then
	echo "These recipes assume that your host is using glibc!" >&2
	exit 1
	fi
	if [[ $MAJOR -ne 2 \|\| $MINOR -lt 23 ]] ; then
	echo "Your host glibc version is too old!" >&2
	exit 1
	fi

	# check libstdc++ host version
	read -r -d "" ARCH TYPE STAMP <<<"$(bob-libstdc++-version g++)" \|\| true
	if [[ $TYPE != "libstdc++" ]] ; then
	echo "These recipes assume that your host is using libstdc++!" >&2
	exit 1
	fi
	if [[ $STAMP -lt 20160603 ]] ; then
	echo "Your host libstdc++ version is too old!" >&2
	exit 1
	fi