[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

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.

Reply to: