On Wed, 20 Aug 2014 12:42:01 +0300
Konstantinos Margaritis via digitalmars-d-ldc
<digitalmars-d-ldc@puremagic.com> wrote:

> I've modifed the packaging to produce both static and shared libs of phobos2 and provide them in separate packages -with a small change needed in the tarball (patch attached).

And of course I forgot to attach the patch... :)

Hi Konstantinos,

On 20 Aug 2014, at 11:42, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> So, which one is the "proper" soversion to be used? 2.0.65 or .65?

65 is the soversion, 2.0.65 is the library version. Because we break binary compatibility on every release right now, they are effectively incremented in lockstep. But in principle they are not related at all.

In other words, if we ever reach a state where the ABI is stable across releases, we might, say, have libphobos2-ldc.so.97 symlinking to libphobos2-ldc.so.2.0.99. I don't think the scheme is different from the established convention at all.

Best,
David

On Wednesday, 20 August 2014 at 22:45:30 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> I don't think the scheme is different from the established convention at all.

(But if it is a problem for Debian packaging regardless, please be sure to let us know! -- David)

On Thu, 21 Aug 2014 15:43:43 +0000
David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com>
wrote:

> On Wednesday, 20 August 2014 at 22:45:30 UTC, David Nadlinger via digitalmars-d-ldc wrote:
> > I don't think the scheme is different from the established convention at all.
> 
> (But if it is a problem for Debian packaging regardless, please be sure to let us know! -- David)

Well, not sure if it is right now. The convention with lib packages is
that the actual binary (with the actual soname used be it 2.0.65
or .65) is included in the libs package (in this case since 65 is an
ABI version, libphobos2-ldc65 is chosen). The other can be symlinks, so
I guess something like the following would be acceptable -though it
might raise a few questions from some Debian guys):

lib*-ldc.so.65     ---> libphobos2-ldc65 (lib package)
lib*-ldc.so.2.0.65 ---> libphobos2-ldc-dev (-dev package)
lib*-ldc.so        ---> libphobos2-ldc-dev (-dev package)

The last two are symlinks to the .so.65 libs.

As for the debug libs, I think I'm just going to install them to a single -debug package.

Regards

Konstantinos

On 21 Aug 2014, at 18:01, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> Well, not sure if it is right now. The convention with lib packages is
> that the actual binary (with the actual soname used be it 2.0.65
> or .65) is included in the libs package (in this case since 65 is an
> ABI version, libphobos2-ldc65 is chosen).

Is it?

$ cat /etc/debian_version
6.0.10
$ ls -l /usr/lib/libz.so*
lrwxrwxrwx  1 root root      15 Aug  8  2012 libz.so.1 -> libz.so.1.2.3.4
-rw-r--r--  1 root root   79980 Dec 28  2009 libz.so.1.2.3.4

libz.so.1 is the soname, and a symlink. I still don't see how this is different from what we are doing, or how it would make sense to do this the other way round.

Cheers,
David

On Thu, 21 Aug 2014 18:33:54 +0200
David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com>
wrote:

> Is it?
> 
> $ cat /etc/debian_version
> 6.0.10
> $ ls -l /usr/lib/libz.so*
> lrwxrwxrwx  1 root root      15 Aug  8  2012 libz.so.1 ->
> libz.so.1.2.3.4
> -rw-r--r--  1 root root   79980 Dec 28  2009 libz.so.1.2.3.4
> 
> libz.so.1 is the soname, and a symlink. I still don't see how this is different from what we are doing, or how it would make sense to do this the other way round.

Well, the difference between the two cases is obvious though. In the case of libz (and a few others as I checked, and you were right in pointing out) is that the libz.so.1 which is the ABI version is the symlink to the actual full soname library, but in lib*-ldc.so case, the ABI version is the actual binary and the full soname is a symlink, which was what got me confused in the first place. Looking at other libs in /lib and /usr/lib, it's probably the first case that I encounter that the ABI lib is _not_ the symlink itself to the full soname. I'm fine with it if you intend to keep it like that, I'll just include both ones in the lib package and upload it as it is -just need to fix one more thing and I hope to do it today.

Regards

Konstantinos

On 21 Aug 2014, at 18:47, Konstantinos Margaritis via digitalmars-d-ldc wrote:
> On Thu, 21 Aug 2014 18:33:54 +0200
> David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com>
> wrote:
>> lrwxrwxrwx  1 root root      15 Aug  8  2012 libz.so.1 ->
>> libz.so.1.2.3.4
>> -rw-r--r--  1 root root   79980 Dec 28  2009 libz.so.1.2.3.4
>>
>> libz.so.1 is the soname, and a symlink. I still don't see how this is
>> different from what we are doing, or how it would make sense to do
>> this the other way round.
>
> Well, the difference between the two cases is obvious though. In the
> case of libz (and a few others as I checked, and you were right in
> pointing out) is that the libz.so.1 which is the ABI version is the
> symlink to the actual full soname library

It seems like we are talking past each other, although I'm not quite sure why.

"libz.so.1" *is* the soname:

$ objdump /usr/lib/libz.so.1.2.3.4 -p | fgrep SONAME
  SONAME               libz.so.1

Same is true for

libdruntime-ldc.so.2.0.65
libdruntime-ldc.so.65 -> libdruntime-ldc.so.2.0.65

and

$ objdump libdruntime-ldc.so.2.0.65 -p | fgrep SONAME
  SONAME               libdruntime-ldc.so.65

You might not want to ship the additional libdruntime-ldc.so -> libdruntime-ldc.so.65 symlink in your packages, but that's a Debian thing and the same as for any other library (Arch Linux for example ships all those links).

If there is something unusual about the way LDC handles things, I'm quite interested in fixing them to avoid irritation for packagers. But I honestly have no clue what the issue is here.

Cheers,
David

On Thu, 21 Aug 2014 21:35:27 +0200
David Nadlinger via digitalmars-d-ldc <digitalmars-d-ldc@puremagic.com>
wrote:

> It seems like we are talking past each other, although I'm not quite sure why.

[snip]

> If there is something unusual about the way LDC handles things, I'm quite interested in fixing them to avoid irritation for packagers. But I honestly have no clue what the issue is here.

No, I see it now, you were right, I had the impression (wrongly) that
the 2.0.65 was the soname. My mistake, you did nothing wrong :)

I'll fix some remaining issue and I'll upload the new versions asap.

Btw, regarding the libz thing (and the patch I applied), I didn't see any comments, I removed the embedded linking from the shared libs and used the system libz, is there any particular reason not to?

Regards

Konstantinos

Sorry Konstantinos, the below mail was stuck in my outbox since Aug 22 due to connection issues.

On 22 Aug 2014, at 9:22, Konstantinos Margaritis via digitalmars-d-ldc wrote:
>> If there is something unusual about the way LDC handles things, I'm
>> quite interested in fixing them to avoid irritation for packagers.
>> But I honestly have no clue what the issue is here.
>
> No, I see it now, you were right, I had the impression (wrongly) that
> the 2.0.65 was the soname. My mistake, you did nothing wrong :)

Ah, okay, makes sense then. ;)

> Btw, regarding the libz thing (and the patch I applied), I didn't see
> any comments, I removed the embedded linking from the shared libs and
> used the system libz, is there any particular reason not to?

Not really, no, that's just something we inherited from the way DMD builds static libraries. I suppose having an embedded libz also makes building on Windows/MSVC more straightforward.

Would be great if you could open a pull request with your changes. I hope I'll have some time for LDC-related work this weekend.

Cheers,
David