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 -- Маленькие детки - маленькие бедки.
