Windows build C PoW doesn't work #1919
Labels
No Label
bug
build
dependencies
developers
documentation
duplicate
enhancement
formatting
invalid
legal
mobile
obsolete
packaging
performance
protocol
question
refactoring
regression
security
test
translation
usability
wontfix
No Milestone
No project
No Assignees
1 Participants
Due Date
No due date set.
Dependencies
No dependencies set.
Reference: Bitmessage/PyBitmessage-2024-12-22#1919
Loading…
Reference in New Issue
Block a user
No description provided.
Delete Branch "%!s()"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
I got a report that the windows executables report C Pow missing. I tried it in Windows Server 2012 and 2016 and couldn't reproduce it, but the person reporting claims on Windows 7 and Windows 10 they get an error message.
Cool! Let them try the exe from my release. Because I also could not test it properly.
@g1itch I am the person who reported it and can confirm that the release you linked:
In other words, working as expected.
Thanks, I read the reddit.
The difference in my release is Microsoft visual C compiler for python27 used to compile the ext: https://github.com/g1itch/PyBitmessage/tree/windows-binary
Also I cannot confirm that the issue appeared in November 2021, I started seeing it in 2019.
The first mention seems to be #1622
I suspect in this case it's also related to a CPU. Maybe some compilation flags can work around it.
@g1litch:
I don't meant to say that Nov. 2021 was the first appearance, only that in my testing of the snapshots @
https://download.bitmessage.org/snapshots/
"20211126" does not display the problem and every later snapshot does.
@PeterSurda:
I tested the 20220125 snapshot and it still shows the C PoW error message.
@PeterSurda: No change on today's snapshot. (20220210)
@PeterSurda: No change on today's snapshot. (20220216)
Perhaps consulting the changelogs around the time of the 20211126 build might help diagnose the problem.
@BeholdersEye There isn't anyone working on this issue for the time being. That being said, my educated guess is that this is caused by the dll compiler options at https://github.com/Bitmessage/PyBitmessage/blob/v0.6/buildscripts/winbuild.sh#L151 and https://github.com/Bitmessage/PyBitmessage/blob/v0.6/buildscripts/winbuild.sh#L157 . The build is done on a Zen 2 CPU so it probably tries to use instructions that Zen 2 understands but your CPU doesn't. Someone with adequate expertise can probably write a fix very quickly.
I agree that does appear to be the problem area. Specifically "march=native". Quoth the documentation:
https://gcc.gnu.org/onlinedocs/gcc/x86-Options.html
In the case of building for 64-bit targets, the march=x86-64 option seems more appropriate for release builds that are expected to be run on machines other than those on which the binaries were built.
Or, in the case of building for 32-bit targets, the march=i686 option.
Can this change be implemented, please? As you say, implementing the fix is not especially difficult but I suspect reproducing the build environment for bitmessage on windows might be more challenging.
Hmm, I agree.
march=native
is definitely a mistake.I've built another release with
march=native
removed.@g1itch: that release's proof of work is functional, though the release in your earlier reply also had functional proof-of-work.
I am using bitmessage in lieu of email on a website and would like to be able to recommend / point to the "official" release of bitmessage (which I take this repository to represent) to the website's users without saying "Make sure to download the snapshot from November 26, 2021 unless you have such-and-such CPU."
It is possible that many users won't even know their CPU's manufacturer so expecting them to pick the right version of bitmessage based on their processor's microarchitecture is optimistic.
@PeterSurda in case mentioning is necessary to notify someone on github.
@BeholdersEye if you want, you can make a pull request, then I can have the windows binary built and you can test it
@PeterSurda
Although I will if it is absolutely necessary, if at all possible I would rather avoid taking the trouble to fork this repository and make the changes just to correct two lines of code.
Is opening the issue and proposing the solution not sufficient to get this addressed?
Went ahead and made the pull request. It is possible the change might not solve the problem which would mean I may need to submit further changes in the future.
I think, that changing the
march
argument is more obvious fix, so it has more chances to merge into v0.6 soon. And then any snapshot on https://download.bitmessage.org will be compatible.