Re: ABI compatibility between rtt-2.8.0 and rtt-2.8.1
Ruben Smits <[email protected]> Mon, 15 Jun 2015 09:06:04 +0200
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <CAN8Phb=RN=p5uPL--fr1KynLpipRaNDxK8b3P4Fs2f-2NdmEPA@mail.gmail.com> |
--===============1056671738== Content-Type: multipart/alternative; boundary=089e01494b68940ff705188918a2 --089e01494b68940ff705188918a2 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable Hi Leopold, On Sat, Jun 13, 2015 at 9:03 AM, S Roderick <[email protected]> wrote: > On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaneda < > [email protected]> 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#L197= -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!): ldd bin/deployer-gnulinux linux-vdso.so.1 =3D> (0x00007ffcde9b3000) *liborocos-rtt-gnulinux.so.2.8* =3D> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-rtt-gnulinux.so.2.8 (0x00007f05daa7d000) liborocos-ocl-log4cpp-gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-log4cpp-gnulinux.= so.2.8.0 (0x00007f05da9f6000) liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-taskbrowser-gnuli= nux.so.2.8.0 (0x00007f05da9be000) liborocos-ocl-deployment-gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-deployment-gnulin= ux.so.2.8.0 (0x00007f05da7be000) libboost_program_options.so.1.54.0 =3D> /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 (0x00007f05da504000) liblog4cpp.so.6.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/liblog4cpp.so.6.0 (0x00007f05da276000) libpthread.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f05da058000) libstdc++.so.6 =3D> /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f05d9d4b000) libgcc_s.so.1 =3D> /lib/x86_64-linux-gnu/libgcc_s.so.1 (0x00007f05d9b34000) libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05d976f000) libboost_filesystem.so.1.54.0 =3D> /usr/lib/x86_64-linux-gnu/libboost_filesystem.so.1.54.0 (0x00007f05d9558000= ) libboost_system.so.1.54.0 =3D> /usr/lib/x86_64-linux-gnu/libboost_system.so.1.54.0 (0x00007f05d9354000) librt.so.1 =3D> /lib/x86_64-linux-gnu/librt.so.1 (0x00007f05d914c000) libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 (0x00007f05d8f47000) libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05d8c41000) libreadline.so.6 =3D> /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f05d89fa000) *librtt-scripting-gnulinux.so.2.8.0* =3D> /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* =3D> /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 =3D> /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=E2=80=99s process regarding = choosing > version numbers? IIRC there was some talk a while back about using semant= ic > versioning [1] to make these decisions. If that is a direction that we wa= nt > to take, then is a tool like the abi-compliance-checker part of that > approach? Otherwise, the maintainers can choose whatever version numberin= g > approach they like (good, bad, or otherwise). > > Cheers > S > > [1] http://semver.org > > -- > Orocos-Dev mailing list > [email protected] > http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev > > --=20 Ruben Smits, Roboticist - Founder +32 479 511 786 Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM www.intermodalics.eu --089e01494b68940ff705188918a2 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr">Hi Leopold,<br><div class=3D"gmail_extra"><br><div class= =3D"gmail_quote">On Sat, Jun 13, 2015 at 9:03 AM, S Roderick <span dir=3D"l= tr"><<a href=3D"mailto:[email protected]" target=3D"_blank">kiwi.net@mac.= com</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"mar= gin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,2= 04);border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break= -word"><span class=3D"">On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaned= a <<a href=3D"mailto:[email protected]" target=3D"_blank">leopold.p= [email protected]</a>> wrote:<br><div><br><blockquote type=3D"cite">Hi,<br><= br>today Ruben Smits =C2=A0merged a pull request [1]. We had an interchange= of <br>comments about if it was ABI compatible or affects too much.<br><br= >Well, this evening I have been playing a bit with a tool called<br>abi-com= pliance-checker [2].<br><br>The result is here [3]. The verdict says Incomp= atible in (1.2%). <br>I don't know if this is important or not, or we c= an trust it. I can provide <br>any file used or procedure if it's neede= d.<br></blockquote></div></span></div></blockquote><div><br></div><div>Than= ks for that analysis, this look really interesting, as I already pointed ou= t 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 dir= ectly 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.</div><div><br></div><div>What's more important is that your= tool also pointed out the addition of a virtual destructor, which I missed= beforehand.=C2=A0 I tested my application to run against the new Orocos RT= T 2.8.1 without recompilation of OCL or my application itself, and I did no= t notice any problems, but I might have been lucky of course.=C2=A0</div><d= iv><br></div><div>What's more problematic is that although rtt does its= best to be able to exploit the ABI compatibility by installing a major.min= or symlink for it's libraries:</div><div><a href=3D"https://github.com/= orocos-toolchain/rtt/blob/master/rtt/CMakeLists.txt#L197-L198">https://gith= ub.com/orocos-toolchain/rtt/blob/master/rtt/CMakeLists.txt#L197-L198</a></d= iv><div>OCL and probably all applications that directly link to the typekit= , scripting or marshalling library are not able to use new ABI compatible v= ersions 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!):</d= iv><div><br></div><div><div>=C2=A0ldd bin/deployer-gnulinux=C2=A0</div><div= ><span class=3D"" style=3D"white-space:pre"> </span>linux-vdso.so.1 =3D>= =C2=A0(0x00007ffcde9b3000)</div><div><span class=3D"" style=3D"white-space= :pre"> </span><b>liborocos-rtt-gnulinux.so.2.8</b> =3D> /home/rsmits/oro= cos_ws/install_isolated/lib/liborocos-rtt-gnulinux.so.2.8 (0x00007f05daa7d0= 00)</div><div><span class=3D"" style=3D"white-space:pre"> </span>liborocos-= ocl-log4cpp-gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolat= ed/lib/liborocos-ocl-log4cpp-gnulinux.so.2.8.0 (0x00007f05da9f6000)</div><d= iv><span class=3D"" style=3D"white-space:pre"> </span>liborocos-ocl-taskbro= wser-gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/= liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 (0x00007f05da9be000)</div><div>= <span class=3D"" style=3D"white-space:pre"> </span>liborocos-ocl-deployment= -gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/libo= rocos-ocl-deployment-gnulinux.so.2.8.0 (0x00007f05da7be000)</div><div><span= class=3D"" style=3D"white-space:pre"> </span>libboost_program_options.so.1= .54.0 =3D> /usr/lib/x86_64-linux-gnu/libboost_program_options.so.1.54.0 = (0x00007f05da504000)</div><div><span class=3D"" style=3D"white-space:pre"> = </span>liblog4cpp.so.6.0 =3D> /home/rsmits/orocos_ws/install_isolated/li= b/liblog4cpp.so.6.0 (0x00007f05da276000)</div><div><span class=3D"" style= =3D"white-space:pre"> </span>libpthread.so.0 =3D> /lib/x86_64-linux-gnu/= libpthread.so.0 (0x00007f05da058000)</div><div><span class=3D"" style=3D"wh= ite-space:pre"> </span>libstdc++.so.6 =3D> /usr/lib/x86_64-linux-gnu/lib= stdc++.so.6 (0x00007f05d9d4b000)</div><div><span class=3D"" style=3D"white-= space:pre"> </span>libgcc_s.so.1 =3D> /lib/x86_64-linux-gnu/libgcc_s.so.= 1 (0x00007f05d9b34000)</div><div><span class=3D"" style=3D"white-space:pre"= > </span>libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.so.6 (0x00007f05d976f= 000)</div><div><span class=3D"" style=3D"white-space:pre"> </span>libboost_= filesystem.so.1.54.0 =3D> /usr/lib/x86_64-linux-gnu/libboost_filesystem.= so.1.54.0 (0x00007f05d9558000)</div><div><span class=3D"" style=3D"white-sp= ace:pre"> </span>libboost_system.so.1.54.0 =3D> /usr/lib/x86_64-linux-gn= u/libboost_system.so.1.54.0 (0x00007f05d9354000)</div><div><span class=3D""= style=3D"white-space:pre"> </span>librt.so.1 =3D> /lib/x86_64-linux-gnu= /librt.so.1 (0x00007f05d914c000)</div><div><span class=3D"" style=3D"white-= space:pre"> </span>libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 (0x0= 0007f05d8f47000)</div><div><span class=3D"" style=3D"white-space:pre"> </sp= an>libm.so.6 =3D> /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05d8c41000)</= div><div><span class=3D"" style=3D"white-space:pre"> </span>libreadline.so.= 6 =3D> /lib/x86_64-linux-gnu/libreadline.so.6 (0x00007f05d89fa000)</div>= <div><span class=3D"" style=3D"white-space:pre"> </span><b>librtt-scripting= -gnulinux.so.2.8.0</b> =3D> /home/rsmits/orocos_ws/install_isolated/lib/= orocos/gnulinux/plugins/librtt-scripting-gnulinux.so.2.8.0 (0x00007f05d85b2= 000)</div><div><span class=3D"" style=3D"white-space:pre"> </span><b>librtt= -marshalling-gnulinux.so.2.8.0</b> =3D> /home/rsmits/orocos_ws/install_i= solated/lib/orocos/gnulinux/plugins/librtt-marshalling-gnulinux.so.2.8.0 (0= x00007f05d84d9000)</div><div><span class=3D"" style=3D"white-space:pre"> </= span>/lib64/ld-linux-x86-64.so.2 (0x00007f05dac6a000)</div><div><span class= =3D"" style=3D"white-space:pre"> </span>libtinfo.so.5 =3D> /lib/x86_64-l= inux-gnu/libtinfo.so.5 (0x00007f05d82b0000)</div></div><div><br></div><div>= 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.</div><div><= br></div><div>R.</div><div><br></div><blockquote class=3D"gmail_quote" styl= e=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(2= 04,204,204);border-left-style:solid;padding-left:1ex"><div style=3D"word-wr= ap:break-word"><span class=3D""><div><blockquote type=3D"cite"><br>Best reg= ards,<br><br>Leopold<br></blockquote></div><br></span><div>I guess the ques= tion is, what is the project=E2=80=99s process regarding choosing version n= umbers? IIRC there was some talk a while back about using semantic versioni= ng [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? Oth= erwise, the maintainers can choose whatever version numbering approach they= like (good, bad, or otherwise).<br><br>Cheers<br>S<br><br>[1]=C2=A0<a href= =3D"http://semver.org" target=3D"_blank">http://semver.org</a></div></div><= br>--<br> Orocos-Dev mailing list<br> <a href=3D"mailto:[email protected]">[email protected].= kuleuven.be</a><br> <a href=3D"http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev" rel= =3D"noreferrer" target=3D"_blank">http://lists.mech.kuleuven.be/mailman/lis= tinfo/orocos-dev</a><br> <br></blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div cla= ss=3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">Ruben Smits, = Roboticist - Founder<br>+32 479 511 786<br>Intermodalics - Kapeldreef 60, 3= 001 Heverlee - BELGIUM<br><a href=3D"http://www.intermodalics.eu" target=3D= "_blank">www.intermodalics.eu</a><br></div></div></div></div> </div></div> --089e01494b68940ff705188918a2-- --===============1056671738== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline -- Orocos-Dev mailing list [email protected] http://lists.mech.kuleuven.be/mailman/listinfo/orocos-dev --===============1056671738==--