On Thu, 2019-01-10 at 07:36 +0000, Nicholas Wilson via Digitalmars-d-learn
wrote:
[…]
> Hmm, if you think the binding could be the problem you could try using app as an alternative, see if it makes any difference.

I did a proper update of the generated files of the binding, and magically everything works again. I do not recollect any change being significant, but clearly something was.

So the problem is that I had failed to notice the update of libdvbv5 with a breaking change and update the binding accordingly.

Of course I got lots of other good stuff done with the code by having this problem and people such as yourself commenting. Big win all round. :-)

Thanks again for helping on this.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
learn wrote:
[…]
> 
> Hm... your description of having the problem happen at the end of main seems to suggest it has something to do with destruction.
> 

It seems that there was a change in one file of libdvbv5 1.14.x → 1.16.y that introduced a breaking change wrt the D binding. I did a regeneration using DStep, didn't notice anything significant, and yet everything now works again. So it was very significant.

The underlying problem here was that I had failed to notice the upgrade of
libdvbv5!

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 1/10/19 12:30 PM, Russel Winder wrote:
> On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
> learn wrote:
> […]
>>
>> Hm... your description of having the problem happen at the end of main
>> seems to suggest it has something to do with destruction.
>>
> 
> It seems that there was a change in one file of libdvbv5 1.14.x → 1..16.y that
> introduced a breaking change wrt the D binding. I did a regeneration using
> DStep, didn't notice anything significant, and yet everything now works again.
> So it was very significant.
> 
> The underlying problem here was that I had failed to notice the upgrade of
> libdvbv5!
>     
> 

That is one problem with linking against C or C++ code -- changes to certain things (e.g. struct layout) don't change the mangling.

You may want to consider using dpp instead if possible.

-Steve

On Thu, Jan 10, 2019 at 01:09:22PM -0500, Steven Schveighoffer via Digitalmars-d-learn wrote:
> On 1/10/19 12:30 PM, Russel Winder wrote:
> > On Thu, 2019-01-10 at 10:00 -0500, Steven Schveighoffer via Digitalmars-d-
> > learn wrote:
> > […]
> > > Hm... your description of having the problem happen at the end of main seems to suggest it has something to do with destruction.
> > > 
> > 
> > It seems that there was a change in one file of libdvbv5 1.14.x → 1..16.y that introduced a breaking change wrt the D binding. I did a regeneration using DStep, didn't notice anything significant, and yet everything now works again.  So it was very significant.
> > 
> > The underlying problem here was that I had failed to notice the upgrade of libdvbv5!
> > 
> 
> That is one problem with linking against C or C++ code -- changes to certain things (e.g. struct layout) don't change the mangling.

Yeah, this is the same problem with shared library soname versioning on Posix.  Technically everytime the ABI changes the version must be bumped, but since this is not automated, it's prone to human error, or rather, negligence.

It makes one wonder if there should somehow be a way of encapsulating the changes to the ABI in a way that can be automatically checked. (It has to be automatic, otherwise it would be too onerous and nobody would do it in practice.)

The most obvious way is to mangle the field types of the struct as part of the struct's mangled name, though this does introduce a lot of symbol bloat (and may need another round of ridiculously-long symbol names that need some manner of compression to keep under control).  Barring that, perhaps some kind of low-collision hash of the struct contents where the kind of small changes that tend to happen in code will be highly unlikely to collide, so any such changes will be easily detected.  If one were paranoid, one could use cryptographic hashes for pretty much guaranteeing uniqueness, but that'd be total overkill.

//

OTOH, perhaps the more pertinent issue here is that the bindings were generated *manually as a separate step* outside of the build system. Ideally, you'd automate the generation of bindings as part of your build, so that they will *always* be up-to-date.  I'm a big fan of automation, because this is the kind of tedious housekeeping that humans are really, really good at forgetting and/or screwing up.

(Side-note: and this is why I insist that my build systems must support generic dependency building. All these sorts of tasks *need* to be part of the build rather than done by hand, precisely to prevent these sorts of time-wasting, head-scratching mishaps.)


> You may want to consider using dpp instead if possible.
[...]

Or this.  Which is essentially equivalent to automatically generating bindings.


T

-- 
Маленькие детки - маленькие бедки.

On Thu, 2019-01-10 at 13:09 -0500, Steven Schveighoffer via Digitalmars-d- learn wrote:
> 
[…]
> That is one problem with linking against C or C++ code -- changes to certain things (e.g. struct layout) don't change the mangling.

I am having nightmares trying to decide what to do with the Rust version based around generate on demand or on version change. With bindgen in Rust though, there is no need for manual tweaking so automated is possible. Except that it puts a massive dependency burden on any project using it.

DStep generated bindings tend to need some manual tweaking that cannot be automated, which is surprising given that bindgen can do things without manual intervention for Rust.

> You may want to consider using dpp instead if possible.

DPP cannot build "out of the box" on Debian Sid, so I have not actually tried it.

There are three audiences here:

1. People building libraries for their own use on their own machines.
2. People building for OS distributions.
3. People building to distribute to others who will not be building for
themselves.

Categories 1 and 2 could probably cope with automated generation despite the huge dependency burden, assuming there are no version conflicts – this seems to be a massive  unsolved problem with Rust/Cargo/crates.io :-( .

Category 3 needs as light a weight and speed of build as possible, and the ability to dynamically adapt to the APIs and ABIs of execution at run time.

On the other hand, suspect I may be the sole user of RUst and D bindings to libdvbv5!

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 2019-01-11 06:31, Russel Winder wrote:

> DStep generated bindings tend to need some manual tweaking that cannot be
> automated, which is surprising given that bindgen can do things without manual
> intervention for Rust.

It's not surprising at all. Different tools, different approaches, different amount of man power, different output languages and so on.

Please file any bugs and/or enhancement requests that you find.

-- 
/Jacob Carlborg

On Sun, 2019-01-13 at 21:56 +0100, Jacob Carlborg via Digitalmars-d-learn wrote:
> On 2019-01-11 06:31, Russel Winder wrote:
> 
> > DStep generated bindings tend to need some manual tweaking that cannot be
> > automated, which is surprising given that bindgen can do things without
> > manual
> > intervention for Rust.
> 
> It's not surprising at all. Different tools, different approaches, different amount of man power, different output languages and so on.

Indeed. Apologies for any aggressiveness that I might have appeared to set out, it was not intended. It's really just frustration.

To balance things out a bit: DStep does some stuff that Bindgen just doesn't even tackle. I am finding I am having to do some manual stuff with Bindgen.

> Please file any bugs and/or enhancement requests that you find.

Wilco. But I'll try and create test cases rather than just point at the full project.

-- 
Russel.
===========================================
Dr Russel Winder      t: +44 20 7585 2200
41 Buckmaster Road    m: +44 7770 465 077
London SW11 1EN, UK   w: www.russel.org.uk

On 2019-01-14 15:07, Russel Winder wrote:

> Wilco. But I'll try and create test cases rather than just point at the full
> project.

Reduced test cases are definitely appreciated.

Unfortunately I don't use DStep enough to find all bugs and enhancements. Hopefully that will change.

-- 
/Jacob Carlborg