Re: [SCM] liblas annotated tag, upstream/1.6.0, created. upstream/1.6.0
On Feb 13, 2011, at 10:22 AM, David Paleino wrote:
> On Sun, 13 Feb 2011 00:53:54 +0100, Francesco P. Lovergine wrote:
>> On Sat, Feb 12, 2011 at 06:51:58PM +0100, David Paleino wrote:
>> I'm taking hobu into the loop because he kindly contacted me about 1.6
>> last month. Do you have any comments? I guess the liblas_c contains
>> the C binding while the liblas.so is C++ (?), but I could be wrong.
> I would've said that as well, but "objdump -x" gives mangled C++-like symbols
> for both of them:
> $ objdump -t liblas_c.so.2.0.0
> 0003a000 w F .text 00000021 _ZN6liblas4guidC1ERKS0_
> 0003a022 w F .text 00000005 _ZN6liblas4guidD2Ev
> 0003a022 w F .text 00000005 _ZN6liblas4guidD1Ev
> $ objdump -t liblas.so.2.0.0
> 000f0a12 w F .text 0000003f _ZN6liblas4guidC1ERKjRKtS4_RA8_Kh
> 000f0a52 w F .text 00000005 _ZN6liblas4guidD2Ev
> 000f0a52 w F .text 00000005 _ZN6liblas4guidD1Ev
> 000f0a58 w F .text 0000002c _ZN6liblas4guidaSERKS0_
> Thus, I can't really tell the difference, apart from the huge difference in
> size :)
> $ ls -lah liblas*.so.2*
> -rwxrwxr-x 1 neo neo 1,3M 12 feb 18.33 liblas_c.so.2.0.0
> -rwxrwxr-x 1 neo neo 11M 12 feb 18.33 liblas.so.2.0.0
The *intent* was to have the _c only have the C API in it and dynamically link to the liblas.so which contains the entire C++ API. Stuff seems a bit mixed if the same symbols are showing up in both. I'll admit to being a CMake neophyte when it comes to controlling these kinds of things...
>> So maybe we should retain a versioned name for the C++ interface
>> to avoid possible future ABI breakage... Some clarifications about
>> the API roadmap for liblas would be great.
> Indeed :)
Agreed. The C++ API between 1.2.x and 1.6 has seen a number of additions and changes, with a few deletions. They are in no way compatible.
The C API has only had a few additions between 1.2 -> 1.6, and it should be binary compatible for the most part.
As far as a roadmap goes, my intention is that there will not be too many changes to either the C or C++ APIs going forward unless something clearly needs to be reversed. Versioning the APIs does makes sense, even for clarity's sake though.
PS: Adding liblas-devel to keep them aware of API issues as well.