deimos\openssl\bio.d(385): Error: undefined identifier uint16_t
Gack, stupid thunderbird decided to send on its own. Let's try this again:
Trying to use deimos openssl master with vibe.d (vibe.d seems to expect
the master), but I keep getting a bunch of this:
deimos\openssl\bio.d(385): Error: undefined identifier uint16t
deimos\openssl\bio.d(388): Error: undefined identifier uint32t
etc.
Any idea what's up?
On 8/18/2014 3:47 PM, Nick Sabalausky wrote:
deimos\openssl\bio.d(385): Error: undefined identifier uint16_t
On 8/18/2014 3:49 PM, Nick Sabalausky wrote:
Gack, stupid thunderbird decided to send on its own. Let's try this again:
Trying to use deimos openssl master with vibe.d (vibe.d seems to expect
the master), but I keep getting a bunch of this:deimos\openssl\bio.d(385): Error: undefined identifier uint16t
deimos\openssl\bio.d(388): Error: undefined identifier uint32tetc.
Any idea what's up?
Tracked it down. It's not a vibe issue, it's the latest commit to
deimos's openssl:
https://github.com/D-Programming-Deimos/openssl/issues/20
On Mon, 18 Aug 2014 16:41:48 -0400, Nick Sabalausky wrote:
On 8/18/2014 3:49 PM, Nick Sabalausky wrote:
Gack, stupid thunderbird decided to send on its own. Let's try this
again:Trying to use deimos openssl master with vibe.d (vibe.d seems to expect
the master), but I keep getting a bunch of this:
This is actually very unfortunate. I've opened a ticket #17, but so far - no reaction whatsoever. This is also why I think that the whole Deimos project is actually a bad idea in its current form, at least if there is no designated package maintainer with push access, who actually has enough time to maintain the project.
deimos\openssl\bio.d(385): Error: undefined identifier uint16t
deimos\openssl\bio.d(388): Error: undefined identifier uint32tetc.
Any idea what's up?
Tracked it down. It's not a vibe issue, it's the latest commit to
deimos's openssl:https://github.com/D-Programming-Deimos/openssl/issues/20
That's interesting, because I'm successfully building with that change since a few months (DMD, win32). No idea why it fails for you.
On 8/19/2014 3:33 AM, Sönke Ludwig wrote:
On Mon, 18 Aug 2014 16:41:48 -0400, Nick Sabalausky wrote:
On 8/18/2014 3:49 PM, Nick Sabalausky wrote:
Gack, stupid thunderbird decided to send on its own. Let's try this
again:Trying to use deimos openssl master with vibe.d (vibe.d seems to expect
the master), but I keep getting a bunch of this:This is actually very unfortunate. I've opened a ticket #17, but so far - no reaction whatsoever. This is also why I think that the whole Deimos project is actually a bad idea in its current form, at least if there is no designated package maintainer with push access, who actually has enough time to maintain the project.
Yea, I've had some big concerns over Demios's ability to handle versions
appropriately. A major part of my concern was that GitHub doesn't
(didn't?) allow sumbitting a pull request for a specifically-named new
branch. Not sure if that's changed or not though. Been awhile since I
looked.
deimos\openssl\bio.d(385): Error: undefined identifier uint16t
deimos\openssl\bio.d(388): Error: undefined identifier uint32tetc.
Any idea what's up?
Tracked it down. It's not a vibe issue, it's the latest commit to
deimos's openssl:https://github.com/D-Programming-Deimos/openssl/issues/20
That's interesting, because I'm successfully building with that change since a few months (DMD, win32). No idea why it fails for you.
Odd. You're absolutely certain it was using the latest HEAD (commit
51abbb34cbe6f31b9d72b2f4c40b759b96f0447f) and not an older
locally-cached version of HEAD? Or an already-compiled .obj of an older
HEAD?
Which DMD? I was doing it with 2.065.
On 8/19/2014 3:37 PM, Nick Sabalausky wrote:
On 8/19/2014 3:33 AM, Sönke Ludwig wrote:
That's interesting, because I'm successfully building with that change
since a few months (DMD, win32). No idea why it fails for you.Odd. You're absolutely certain it was using the latest HEAD (commit
51abbb34cbe6f31b9d72b2f4c40b759b96f0447f) and not an older
locally-cached version of HEAD? Or an already-compiled .obj of an older
HEAD?Which DMD? I was doing it with 2.065.
Are you using any of the "OPENSSL_*" version defines? I'm not.
Am 19.08.2014 21:53, schrieb Nick Sabalausky:
On 8/19/2014 3:37 PM, Nick Sabalausky wrote:
On 8/19/2014 3:33 AM, Sönke Ludwig wrote:
That's interesting, because I'm successfully building with that change
since a few months (DMD, win32). No idea why it fails for you.Odd. You're absolutely certain it was using the latest HEAD (commit
51abbb34cbe6f31b9d72b2f4c40b759b96f0447f) and not an older
locally-cached version of HEAD? Or an already-compiled .obj of an older
HEAD?Which DMD? I was doing it with 2.065.
Are you using any of the "OPENSSL_*" version defines? I'm not.
Okay.. got it. It's simply that I have registered my own fork of the
bindings on code.dlang.org and that still dates back to April 21th
(instead of April 24th). I'll pull the latest changes once the errors
are fixed. The reason why I have a fork is simply to supply proper
.lib/.dll files on Windows, so that no additional setup is required.