[Skiboot] [PATCH] pflash: compile fail due to version mismatch.
stewart at linux.vnet.ibm.com
Tue Aug 2 08:39:53 AEST 2016
Patrick Williams <patrick at stwcx.xyz> writes:
> 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?
6.1.1 here would mean that there's been one bugfix release (the middle
1) and that version 6 is backwards compatible with version 5.
This lets ldconfig make the appropriate symlinks and apps/libraries to
link against the version of the API they need.
So 7.100.2 is backwards compatible to version 5.x.x, and there's been
100 bug fix (but not api change) releases of it.
> 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
Cool. I'll merge it in and tag skiboot 5.3.0
OPAL Architect, IBM.
More information about the Skiboot