On 2018-03-19 18:03, Perry E. Metzger wrote: > On Mon, 19 Mar 2018 17:10:52 +0100 Mojca Miklavec >> Last time I checked this PR was not entirely complete and from my >> understanding that was the only reason why it was not merged. We >> certainly need a solution for 64-bit wine in some not-too-distant >> future; whether an incomplete patch helps with that, I don't know. >> We should certainly keep at least a ticket on Trac with a reference >> to the code. > > So my understanding (and I might be mangling it) is that the issue > here is that there are two x86_64 registers that are reasonable > candidates for pointing at thread local data, and Windows has picked > a different one from macOS. The result of this is that a register > that Windows programs expect will be preserved gets destroyed in the > course of calling in to the rest of the OS.
I have no idea how they solved it, but upstream claims that 64-bit is supported on macOS. I added more comments and commits to the PR: https://github.com/macports/macports-ports/pull/442 >>> 2: mosh: Switch to protobuf3-cpp >>> https://github.com/macports/macports-ports/pull/690 >>> Aug 17, 2017 >>> >>> Zero King correctly notes in the course of the PR's comment thread >>> that protobuf3-cpp conflicts with protobuf-cpp, so all >>> protobuf-cpp using ports probably should be migrated. >>> >>> This seems entirely straightforward to do (I made the needed >>> changes in my own git repo in a couple of minutes) but rather >>> difficult to test. To close this out, we probably need some >>> volunteer who is in a position to test such an update. >> >> Can you please update the PR with your changes (replacing all >> dependencies on protobuf-cpp with protobuf3-cpp) or perhaps open a >> new one? > > I could open a new one, but I'd prefer if someone had committed to > help before I do that. > >> Travis certainly won't be able to build them all, but the >> list of ports to test seems reasonable. Either someone can run >> destroot, or we can simply submit the builds to the buildbot and be >> ready to quickly patch the failing builds. > > So lets say that I submit a PR, do you think you would be in a > position to help watch the buildbot (or do a test run?) Unfortunately, we have no support to run builds from pull requests or custom branches on the buildbot, as it would immediately publish the resulting archives. This sounds like a nice enhancement for our buildbot, though. On a forced build, we can already specify a branch name. If buildbot would only try to publish binary archives when running for the master branch, we could use it to test changes like this. Rainer
