Re: ABI compatibility between rtt-2.8.0 and rtt-2.8.1
Ruben Smits <[email protected]> Mon, 15 Jun 2015 09:21:22 +0200
| Newsgroups | gmane.science.robotics.orocos.devel |
|---|---|
| Message-ID | <CAN8PhbkjA0ugSfrVVW86GT52QzpQkYkAe8ZcK+Zeq9cUo3K_yw@mail.gmail.com> |
--===============0967715535== Content-Type: multipart/alternative; boundary=bcaec51a8c3a4856040518894fab --bcaec51a8c3a4856040518894fab Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: quoted-printable On Mon, Jun 15, 2015 at 9:06 AM, Ruben Smits <[email protected]> wrote: > 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. Onl= y > if you would directly include the BoolTypeInfo header you would be affect= ed > 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 t= o > 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#L1= 97-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-gnulinu= x.so.2.8.0 > (0x00007f05da9f6000) > liborocos-ocl-taskbrowser-gnulinux.so.2.8.0 =3D> > /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-taskbrowser-gnu= linux.so.2.8.0 > (0x00007f05da9be000) > liborocos-ocl-deployment-gnulinux.so.2.8.0 =3D> > /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-deployment-gnul= inux.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 (0x00007f05d9b3400= 0) > 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 (0x00007f05d95580= 00) > 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/librt= t-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/librt= t-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 (0x00007f05d82b000= 0) > > 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=E2=80=99s process regarding= choosing >> version numbers? IIRC there was some talk a while back about using seman= tic >> versioning [1] to make these decisions. If that is a direction that we w= ant >> to take, then is a tool like the abi-compliance-checker part of that >> approach? Otherwise, the maintainers can choose whatever version numberi= ng >> 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 >> >> > > > -- > Ruben Smits, Roboticist - Founder > +32 479 511 786 > Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM > www.intermodalics.eu > --=20 Ruben Smits, Roboticist - Founder +32 479 511 786 Intermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM www.intermodalics.eu --bcaec51a8c3a4856040518894fab Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable <div dir=3D"ltr"><br><div class=3D"gmail_extra"><br><div class=3D"gmail_quo= te">On Mon, Jun 15, 2015 at 9:06 AM, Ruben Smits <span dir=3D"ltr"><<a h= ref=3D"mailto:[email protected]" target=3D"_blank">ruben.smits@i= ntermodalics.eu</a>></span> wrote:<br><blockquote class=3D"gmail_quote" = style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:r= gb(204,204,204);border-left-style:solid;padding-left:1ex"><div dir=3D"ltr">= Hi Leopold,<br><div class=3D"gmail_extra"><br><div class=3D"gmail_quote"><s= pan class=3D"">On Sat, Jun 13, 2015 at 9:03 AM, S Roderick <span dir=3D"ltr= "><<a href=3D"mailto:[email protected]" target=3D"_blank">[email protected]= m</a>></span> wrote:<br><blockquote class=3D"gmail_quote" style=3D"margi= n:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204= );border-left-style:solid;padding-left:1ex"><div style=3D"word-wrap:break-w= ord"><span>On Jun 13, 2015, at 00:16, Leopold Palomo-Avellaneda <<a href= =3D"mailto:[email protected]" target=3D"_blank">[email protected]= </a>> wrote:<br><div><br><blockquote type=3D"cite">Hi,<br><br>today Rube= n Smits =C2=A0merged a pull request [1]. We had an interchange of <br>comme= nts about if it was ABI compatible or affects too much.<br><br>Well, this e= vening I have been playing a bit with a tool called<br>abi-compliance-check= er [2].<br><br>The result is here [3]. The verdict says Incompatible in (1.= 2%). <br>I don't know if this is important or not, or we can trust it. = I can provide <br>any file used or procedure if it's needed.<br></block= quote></div></span></div></blockquote><div><br></div></span><div>Thanks for= that analysis, this look really interesting, as I already pointed out in t= he PR, the change in the BoolTypeInfo is in theory ABI incompatible, but si= nce 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 t= o 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 doub= t 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 befor= ehand.=C2=A0 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 noti= ce any problems, but I might have been lucky of course.=C2=A0</div><div><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.minor sym= link for it's libraries:</div><div><a href=3D"https://github.com/orocos= -toolchain/rtt/blob/master/rtt/CMakeLists.txt#L197-L198" target=3D"_blank">= https://github.com/orocos-toolchain/rtt/blob/master/rtt/CMakeLists.txt#L197= -L198</a></div><div>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.p= atch library instead of the major.minor one (for the rtt library it's c= orrect!):</div><div><br></div><div><div>=C2=A0ldd bin/deployer-gnulinux=C2= =A0</div><div><span style=3D"white-space:pre-wrap"> </span>linux-vdso.so.1 = =3D> =C2=A0(0x00007ffcde9b3000)</div><div><span style=3D"white-space:pre= -wrap"> </span><b>liborocos-rtt-gnulinux.so.2.8</b> =3D> /home/rsmits/or= ocos_ws/install_isolated/lib/liborocos-rtt-gnulinux.so.2.8 (0x00007f05daa7d= 000)</div><div><span style=3D"white-space:pre-wrap"> </span>liborocos-ocl-l= og4cpp-gnulinux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/li= b/liborocos-ocl-log4cpp-gnulinux.so.2.8.0 (0x00007f05da9f6000)</div><div><s= pan style=3D"white-space:pre-wrap"> </span>liborocos-ocl-taskbrowser-gnulin= ux.so.2.8.0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-o= cl-taskbrowser-gnulinux.so.2.8.0 (0x00007f05da9be000)</div><div><span style= =3D"white-space:pre-wrap"> </span>liborocos-ocl-deployment-gnulinux.so.2.8.= 0 =3D> /home/rsmits/orocos_ws/install_isolated/lib/liborocos-ocl-deploym= ent-gnulinux.so.2.8.0 (0x00007f05da7be000)</div><div><span style=3D"white-s= pace:pre-wrap"> </span>libboost_program_options.so.1.54.0 =3D> /usr/lib/= x86_64-linux-gnu/libboost_program_options.so.1.54.0 (0x00007f05da504000)</d= iv><div><span style=3D"white-space:pre-wrap"> </span>liblog4cpp.so.6.0 =3D&= gt; /home/rsmits/orocos_ws/install_isolated/lib/liblog4cpp.so.6.0 (0x00007f= 05da276000)</div><div><span style=3D"white-space:pre-wrap"> </span>libpthre= ad.so.0 =3D> /lib/x86_64-linux-gnu/libpthread.so.0 (0x00007f05da058000)<= /div><div><span style=3D"white-space:pre-wrap"> </span>libstdc++.so.6 =3D&g= t; /usr/lib/x86_64-linux-gnu/libstdc++.so.6 (0x00007f05d9d4b000)</div><div>= <span style=3D"white-space:pre-wrap"> </span>libgcc_s.so.1 =3D> /lib/x86= _64-linux-gnu/libgcc_s.so.1 (0x00007f05d9b34000)</div><div><span style=3D"w= hite-space:pre-wrap"> </span>libc.so.6 =3D> /lib/x86_64-linux-gnu/libc.s= o.6 (0x00007f05d976f000)</div><div><span style=3D"white-space:pre-wrap"> </= span>libboost_filesystem.so.1.54.0 =3D> /usr/lib/x86_64-linux-gnu/libboo= st_filesystem.so.1.54.0 (0x00007f05d9558000)</div><div><span style=3D"white= -space:pre-wrap"> </span>libboost_system.so.1.54.0 =3D> /usr/lib/x86_64-= linux-gnu/libboost_system.so.1.54.0 (0x00007f05d9354000)</div><div><span st= yle=3D"white-space:pre-wrap"> </span>librt.so.1 =3D> /lib/x86_64-linux-g= nu/librt.so.1 (0x00007f05d914c000)</div><div><span style=3D"white-space:pre= -wrap"> </span>libdl.so.2 =3D> /lib/x86_64-linux-gnu/libdl.so.2 (0x00007= f05d8f47000)</div><div><span style=3D"white-space:pre-wrap"> </span>libm.so= .6 =3D> /lib/x86_64-linux-gnu/libm.so.6 (0x00007f05d8c41000)</div><div><= span style=3D"white-space:pre-wrap"> </span>libreadline.so.6 =3D> /lib/x= 86_64-linux-gnu/libreadline.so.6 (0x00007f05d89fa000)</div><div><span style= =3D"white-space:pre-wrap"> </span><b>librtt-scripting-gnulinux.so.2.8.0</b>= =3D> /home/rsmits/orocos_ws/install_isolated/lib/orocos/gnulinux/plugin= s/librtt-scripting-gnulinux.so.2.8.0 (0x00007f05d85b2000)</div><div><span s= tyle=3D"white-space:pre-wrap"> </span><b>librtt-marshalling-gnulinux.so.2.8= .0</b> =3D> /home/rsmits/orocos_ws/install_isolated/lib/orocos/gnulinux/= plugins/librtt-marshalling-gnulinux.so.2.8.0 (0x00007f05d84d9000)</div><div= ><span style=3D"white-space:pre-wrap"> </span>/lib64/ld-linux-x86-64.so.2 (= 0x00007f05dac6a000)</div><div><span style=3D"white-space:pre-wrap"> </span>= libtinfo.so.5 =3D> /lib/x86_64-linux-gnu/libtinfo.so.5 (0x00007f05d82b00= 00)</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 re= leased anyway, whatever that means) , 2.8.1 or 2.9.0, I'm more interest= ed in fixing the above.</div><div><br></div></div></div></div></blockquote>= <div><br></div><div>See=C2=A0<a href=3D"https://github.com/orocos-toolchain= /rtt/pull/104">https://github.com/orocos-toolchain/rtt/pull/104</a> for a f= ix for the linking.</div><div><br></div><div>R.</div><div>=C2=A0</div><bloc= kquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left-= width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;paddin= g-left:1ex"><div dir=3D"ltr"><div class=3D"gmail_extra"><div class=3D"gmail= _quote"><div></div><div>R.</div><div><br></div><blockquote class=3D"gmail_q= uote" style=3D"margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-c= olor:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><span class= =3D""><div style=3D"word-wrap:break-word"><span><div><blockquote type=3D"ci= te"><br>Best regards,<br><br>Leopold<br></blockquote></div><br></span><div>= I guess the question is, what is the project=E2=80=99s process regarding ch= oosing version numbers? IIRC there was some talk a while back about using s= emantic 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 th= at approach? Otherwise, the maintainers can choose whatever version numberi= ng 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></span><span class=3D""><font color=3D"#888888">--<br> Orocos-Dev mailing list<br> <a href=3D"mailto:[email protected]" target=3D"_blank">Oroc= [email protected]</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></font></span></blockquote></div><span class=3D""><font color=3D"#88888= 8"><br><br clear=3D"all"><div><br></div>-- <br><div><div dir=3D"ltr"><div><= div dir=3D"ltr">Ruben Smits, Roboticist - Founder<br>+32 479 511 786<br>Int= ermodalics - Kapeldreef 60, 3001 Heverlee - BELGIUM<br><a href=3D"http://ww= w.intermodalics.eu" target=3D"_blank">www.intermodalics.eu</a><br></div></d= iv></div></div> </font></span></div></div> </blockquote></div><br><br clear=3D"all"><div><br></div>-- <br><div class= =3D"gmail_signature"><div dir=3D"ltr"><div><div dir=3D"ltr">Ruben Smits, Ro= boticist - Founder<br>+32 479 511 786<br>Intermodalics - Kapeldreef 60, 300= 1 Heverlee - BELGIUM<br><a href=3D"http://www.intermodalics.eu" target=3D"_= blank">www.intermodalics.eu</a><br></div></div></div></div> </div></div> --bcaec51a8c3a4856040518894fab-- --===============0967715535== 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 --===============0967715535==--