[Skiboot] [PATCH] pflash: compile fail due to version mismatch.
patrick at stwcx.xyz
Tue Aug 2 03:02:12 AEST 2016
On Mon, Aug 01, 2016 at 06:58:01PM +1000, Stewart Smith wrote:
> Patrick Williams <patrick at stwcx.xyz> writes:
> > libflash.so is currently versioned using make_version.sh, which
> > appends 'skiboot-' and optionally '-dirty' depending if the
> > build is done within a git repository. There seems to be a parallel
> > build problem where 'make_version.sh' can return different results.
> > Compiling with Yocto I sometimes see:
> > arm-openbmc-linux-gnueabi-gcc ... -shared -Wl,-soname,libflash.so
> > -o libflash.so.skiboot-5.2.5 ...
> > arm-openbmc-linux-gnueabi-gcc ...
> > ../shared/libflash.so.skiboot-5.2.5-dirty-da39a3e -lrt -o pflash
> > arm-openbmc-linux-gnueabi-gcc: error:
> > ../shared/libflash.so.skiboot-5.2.5-dirty-da39a3e: No such file or
> > directory
> > Changed libflash.so versioning to be libflash.so.$(SKIBOOT_VERSION)
> > whenever SKIBOOT_VERSION is defined. This ensures a consistent and
> > reasonable library version: libflash.so.5.2.5
> > Signed-off-by: Patrick Williams <patrick at stwcx.xyz>
> > CC: Joel Stanley <joel at jms.id.au>
> I think I have a better approach, we should instead follow the libtool
> guidelines and do things correctly, and basing so version on skiboot
> version is totally not that.
> Can you test if the following works for you with yocto?
> If it does, and this looks good to others, i'll merge this in as the
> final patch before pushing skiboot 5.3.0 up.
> diff --git a/external/shared/rules.mk b/external/shared/rules.mk
> index a4976a1..147c38f 100644
> --- a/external/shared/rules.mk
> +++ b/external/shared/rules.mk
> @@ -1 +1,18 @@
> -SHARED_NAME=libflash.so.$(shell ../../make_version.sh)
> +# NOTE: shared lib versioning has *NOTHING* to do with software package version
> +# If source code has changed, revision++
> +# if any interfaces have been added, removed, or changed, current++, revision=0
> +# if any interfaces have been added, age++
> +# if any interfaces have been removed or changed, age=0
> +# i.e. AGE refers to backwards compatibility.
> +# e.g. If we start with 5.3.0 and we're releasing new version:
> +# - bug fix no api change: 5.4.0
> +# - new API call, backwards compatible otherwise: 6.0.1
> +# - API removed, or changed (i.e. not backwards compat): 6.0.0
I fail to understand the utility of the nomenclature. How do I tell
from version 6.1.1 that if it is "compatible" with 5.3.0 or just with
6.0.0? Don't I have to know the entire history to make that
determination? ie. What are all the versions between 5.3.0 and 6.1.1?
I'm pretty certain this will work just fine from a Yocto perspective.
It doesn't really care what the versions are, as long as there are some.
> Stewart Smith
> OPAL Architect, IBM.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 819 bytes
Desc: Digital signature
More information about the Skiboot