Hi,
today Ruben Smits merged a pull request [1]. We had an interchange of
comments about if it was ABI compatible or affects too much.
Well, this evening I have been playing a bit with a tool called
abi-compliance-checker [2].
The result is here [3]. The verdict says Incompatible in (1.2%).
I don't know if this is important or not, or we can trust it. I can provide
any file used or procedure if it's needed.
Best regards,
Leopold
[1] https://github.com/orocos-toolchain/rtt/pull/101
[2] http://ispras.linuxbase.org/index.php/ABI_compliance_checker
[3] http://sir.upc.edu/debian-robotics/compat_reports/orocos-rtt/2.8.0_to_2....
ABI compatibility between rtt-2.8.0 and rtt-2.8.1
On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaneda <leopold [dot] palomo [..] ...> wrote:
> Hi,
>
> today Ruben Smits merged a pull request [1]. We had an interchange of
> comments about if it was ABI compatible or affects too much.
>
> Well, this evening I have been playing a bit with a tool called
> abi-compliance-checker [2].
>
> The result is here [3]. The verdict says Incompatible in (1.2%).
> I don't know if this is important or not, or we can trust it. I can provide
> any file used or procedure if it's needed.
>
> Best regards,
>
> Leopold
I guess the question is, what is the project’s process regarding choosing version numbers? IIRC there was some talk a while back about using semantic versioning [1] to make these decisions. If that is a direction that we want to take, then is a tool like the abi-compliance-checker part of that approach? Otherwise, the maintainers can choose whatever version numbering approach they like (good, bad, or otherwise).
Cheers
S
[1] http://semver.org
ABI compatibility between rtt-2.8.0 and rtt-2.8.1
Hi Leopold,
On Sat, Jun 13, 2015 at 9:03 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
> On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaneda <
> leopold [dot] palomo [..] ...> wrote:
>
> Hi,
>
> today Ruben Smits merged a pull request [1]. We had an interchange of
> comments about if it was ABI compatible or affects too much.
>
> Well, this evening I have been playing a bit with a tool called
> abi-compliance-checker [2].
>
> The result is here [3]. The verdict says Incompatible in (1.2%).
> I don't know if this is important or not, or we can trust it. I can
> provide
> any file used or procedure if it's needed.
>
>
Thanks for that analysis, this look really interesting, as I already
pointed out in the PR, the change in the BoolTypeInfo is in theory ABI
incompatible, but since it is only loaded into your application using the
TypeRepository plugin system, user code is not affected by this, not even
if you directly link to the rtt-typekit and use bool based RTT types. Only
if you would directly include the BoolTypeInfo header you would be affected
by this, which I doubt any user would do, so I would not consider this as a
change in the public API.
What's more important is that your tool also pointed out the addition of a
virtual destructor, which I missed beforehand. I tested my application to
run against the new Orocos RTT 2.8.1 without recompilation of OCL or my
application itself, and I did not notice any problems, but I might have
been lucky of course.
What's more problematic is that although rtt does its best to be able to
exploit the ABI compatibility by installing a major.minor symlink for it's
libraries:
https://github.com/orocos-toolchain/rtt/blob/master/rtt/CMakeLists.txt#L...
OCL and probably all applications that directly link to the typekit,
scripting or marshalling library are not able to use new ABI compatible
versions of these plugins because they link to the major.minor.patch
library instead of the major.minor one (for the rtt library it's correct!):
ldd bin/deployer-gnulinux
linux-vdso.so.1 => (0x00007ffcde9b3000)
*liborocos-rtt-gnulinux.so.2.8* =>
/home/rsmits/orocos_ws/install_isolated/lib/liborocos-rtt-gnulinux.so.2.8
(0x00007f05daa7d000)
liborocos-ocl-log4cpp-gnulinux.so.2.8.0 =>
/home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-log4cpp-gnulinux.so.2.8.0
(0x00007f05da9f6000)
liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 =>
/home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0
(0x00007f05da9be000)
liborocos-ocl-deployment-gnulinux.so.2.8.0 =>
/home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-deployment-gnulinux.so.2.8.0
(0x00007f05da7be000)
libboost_program_options.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0
(0x00007f05da504000)
liblog4cpp.so.6.0 =>
/home/rsmits/orocos_ws/install_isolated/lib/liblog4cpp.so.6.0
(0x00007f05da276000)
libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
(0x00007f05da058000)
libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(0x00007f05d9d4b000)
libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f05d9b34000)
libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05d976f000)
libboost_filesystem.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f05d9558000)
libboost_system.so.1.54.0 =>
/usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f05d9354000)
librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f05d914c000)
libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f05d8f47000)
libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05d8c41000)
libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
(0x00007f05d89fa000)
*librtt-scripting-gnulinux.so.2.8.0* =>
/home/rsmits/orocos_ws/install_isolated/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.8.0
(0x00007f05d85b2000)
*librtt-marshalling-gnulinux.so.2.8.0* =>
/home/rsmits/orocos_ws/install_isolated/lib/orocos/gnulinux/plugins/librtt-marshalling-gnulinux.so.2.8.0
(0x00007f05d84d9000)
/lib64/ld-linux-x86-64.so.2 (0x00007f05dac6a000)
libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f05d82b0000)
I personally don't really care if we call it 2.8.0 (we could do this as
well, as 2.8 has not been officially released anyway, whatever that means)
, 2.8.1 or 2.9.0, I'm more interested in fixing the above.
R.
> Best regards,
>
> Leopold
>
>
> I guess the question is, what is the project’s process regarding choosing
> version numbers? IIRC there was some talk a while back about using semantic
> versioning [1] to make these decisions. If that is a direction that we want
> to take, then is a tool like the abi-compliance-checker part of that
> approach? Otherwise, the maintainers can choose whatever version numbering
> approach they like (good, bad, or otherwise).
>
> Cheers
> S
>
> [1] http://semver.org
>
> --
> Orocos-Dev mailing list
> Orocos-Dev [..] ...
> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>
>
ABI compatibility between rtt-2.8.0 and rtt-2.8.1
Hi Ruben,
El Dilluns, 15 de juny de 2015, a les 09:06:04, Ruben Smits va escriure:
> Hi Leopold,
>
> On Sat, Jun 13, 2015 at 9:03 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
> > On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaneda <
> > leopold [dot] palomo [..] ...> wrote:
> >
> > Hi,
> >
> > today Ruben Smits merged a pull request [1]. We had an interchange of
> > comments about if it was ABI compatible or affects too much.
> >
> > Well, this evening I have been playing a bit with a tool called
> > abi-compliance-checker [2].
> >
> > The result is here [3]. The verdict says Incompatible in (1.2%).
> > I don't know if this is important or not, or we can trust it. I can
> > provide
> > any file used or procedure if it's needed.
>
> Thanks for that analysis, this look really interesting, as I already
> pointed out in the PR, the change in the BoolTypeInfo is in theory ABI
> incompatible, but since it is only loaded into your application using the
> TypeRepository plugin system, user code is not affected by this, not even
> if you directly link to the rtt-typekit and use bool based RTT types. Only
> if you would directly include the BoolTypeInfo header you would be affected
> by this, which I doubt any user would do, so I would not consider this as a
> change in the public API.
>
> What's more important is that your tool also pointed out the addition of a
> virtual destructor, which I missed beforehand. I tested my application to
> run against the new Orocos RTT 2.8.1 without recompilation of OCL or my
> application itself, and I did not notice any problems, but I might have
> been lucky of course.
>
> What's more problematic is that although rtt does its best to be able to
> exploit the ABI compatibility by installing a major.minor symlink for it's
> libraries:
> https://github.com/orocos-toolchain/rtt/blob/master/rtt/CMakeLists.txt#L... L198 OCL and probably all applications that directly link to the typekit,
> scripting or marshalling library are not able to use new ABI compatible
> versions of these plugins because they link to the major.minor.patch
> library instead of the major.minor one (for the rtt library it's correct!):
I did some patches to OCL here [1]. This version of OCL expose its stuff with
major.minor, so, the applications that use it should be not have problems in
this stuff, if I have understood you well.
[...]
>
> I personally don't really care if we call it 2.8.0 (we could do this as
> well, as 2.8 has not been officially released anyway, whatever that means)
> , 2.8.1 or 2.9.0, I'm more interested in fixing the above.
Yes, I know, but for whom like me try to package all the orocos stuff is a
headache manage all this kind of ~rc1, and not well released versions, ubuntu
packages, OSRF versions and so on.
So, if you use, as Steven said, semver, all of us will be much more happy,
with all of work that implies (ABIs, SONAMES, releases, etc ...)
Best regards,
Leopold
[1] http://anonscm.debian.org/cgit/debian-science/packages/orocos/ocl.git/tr...
> R.
>
> > Best regards,
> >
> > Leopold
> >
> >
> > I guess the question is, what is the project’s process regarding choosing
> > version numbers? IIRC there was some talk a while back about using
> > semantic
> > versioning [1] to make these decisions. If that is a direction that we
> > want
> > to take, then is a tool like the abi-compliance-checker part of that
> > approach? Otherwise, the maintainers can choose whatever version numbering
> > approach they like (good, bad, or otherwise).
> >
> > Cheers
> > S
> >
> > [1] http://semver.org
> >
> > --
> > Orocos-Dev mailing list
> > Orocos-Dev [..] ...
> > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
ABI compatibility between rtt-2.8.0 and rtt-2.8.1
On Mon, Jun 15, 2015 at 9:06 AM, Ruben Smits <ruben [dot] smits [..] ...>
wrote:
> Hi Leopold,
>
> On Sat, Jun 13, 2015 at 9:03 AM, S Roderick <kiwi [dot] net [..] ...> wrote:
>
>> On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaneda <
>> leopold [dot] palomo [..] ...> wrote:
>>
>> Hi,
>>
>> today Ruben Smits merged a pull request [1]. We had an interchange of
>> comments about if it was ABI compatible or affects too much.
>>
>> Well, this evening I have been playing a bit with a tool called
>> abi-compliance-checker [2].
>>
>> The result is here [3]. The verdict says Incompatible in (1.2%).
>> I don't know if this is important or not, or we can trust it. I can
>> provide
>> any file used or procedure if it's needed.
>>
>>
> Thanks for that analysis, this look really interesting, as I already
> pointed out in the PR, the change in the BoolTypeInfo is in theory ABI
> incompatible, but since it is only loaded into your application using the
> TypeRepository plugin system, user code is not affected by this, not even
> if you directly link to the rtt-typekit and use bool based RTT types. Only
> if you would directly include the BoolTypeInfo header you would be affected
> by this, which I doubt any user would do, so I would not consider this as a
> change in the public API.
>
> What's more important is that your tool also pointed out the addition of a
> virtual destructor, which I missed beforehand. I tested my application to
> run against the new Orocos RTT 2.8.1 without recompilation of OCL or my
> application itself, and I did not notice any problems, but I might have
> been lucky of course.
>
> What's more problematic is that although rtt does its best to be able to
> exploit the ABI compatibility by installing a major.minor symlink for it's
> libraries:
>
> https://github.com/orocos-toolchain/rtt/blob/master/rtt/CMakeLists.txt#L...
> OCL and probably all applications that directly link to the typekit,
> scripting or marshalling library are not able to use new ABI compatible
> versions of these plugins because they link to the major.minor.patch
> library instead of the major.minor one (for the rtt library it's correct!):
>
> ldd bin/deployer-gnulinux
> linux-vdso.so.1 => (0x00007ffcde9b3000)
> *liborocos-rtt-gnulinux.so.2.8* =>
> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-rtt-gnulinux.so.2.8
> (0x00007f05daa7d000)
> liborocos-ocl-log4cpp-gnulinux.so.2.8.0 =>
> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-log4cpp-gnulinux.so.2.8.0
> (0x00007f05da9f6000)
> liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 =>
> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-taskbrowser-gnulinux.so.2.8.0
> (0x00007f05da9be000)
> liborocos-ocl-deployment-gnulinux.so.2.8.0 =>
> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-deployment-gnulinux.so.2.8.0
> (0x00007f05da7be000)
> libboost_program_options.so.1.54.0 =>
> /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0
> (0x00007f05da504000)
> liblog4cpp.so.6.0 =>
> /home/rsmits/orocos_ws/install_isolated/lib/liblog4cpp.so.6.0
> (0x00007f05da276000)
> libpthread.so.0 => /lib/x86_64-linux-gnu/libpthread.so.0
> (0x00007f05da058000)
> libstdc++.so.6 => /usr/lib/x86_64-linux-gnu/libstdc++.so.6
> (0x00007f05d9d4b000)
> libgcc_s.so.1 => /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f05d9b34000)
> libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05d976f000)
> libboost_filesystem.so.1.54.0 =>
> /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f05d9558000)
> libboost_system.so.1.54.0 =>
> /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f05d9354000)
> librt.so.1 => /lib/x86_64-linux-gnu/librt.so.1 (0x00007f05d914c000)
> libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f05d8f47000)
> libm.so.6 => /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05d8c41000)
> libreadline.so.6 => /lib/x86_64-linux-gnu/libreadline.so.6
> (0x00007f05d89fa000)
> *librtt-scripting-gnulinux.so.2.8.0* =>
> /home/rsmits/orocos_ws/install_isolated/lib/orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.8.0
> (0x00007f05d85b2000)
> *librtt-marshalling-gnulinux.so.2.8.0* =>
> /home/rsmits/orocos_ws/install_isolated/lib/orocos/gnulinux/plugins/librtt-marshalling-gnulinux.so.2.8.0
> (0x00007f05d84d9000)
> /lib64/ld-linux-x86-64.so.2 (0x00007f05dac6a000)
> libtinfo.so.5 => /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f05d82b0000)
>
> I personally don't really care if we call it 2.8.0 (we could do this as
> well, as 2.8 has not been officially released anyway, whatever that means)
> , 2.8.1 or 2.9.0, I'm more interested in fixing the above.
>
>
See https://github.com/orocos-toolchain/rtt/pull/104 for a fix for the
linking.
R.
> R.
>
>
>> Best regards,
>>
>> Leopold
>>
>>
>> I guess the question is, what is the project’s process regarding choosing
>> version numbers? IIRC there was some talk a while back about using semantic
>> versioning [1] to make these decisions. If that is a direction that we want
>> to take, then is a tool like the abi-compliance-checker part of that
>> approach? Otherwise, the maintainers can choose whatever version numbering
>> approach they like (good, bad, or otherwise).
>>
>> Cheers
>> S
>>
>> [1] http://semver.org
>>
>> --
>> Orocos-Dev mailing list
>> Orocos-Dev [..] ...
>> http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev
>>
>>
>
>
> --
> Ruben Smits, Roboticist - Founder
> +32 479 511 786
> Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM
> www.intermodalics.eu
>