Bitmessage/PyBitmessage-2024-12-19
Archived
2
0
Fork 0
Code Issues 168 Pull Requests 52 Actions Packages Projects Releases 5 Wiki Activity

Windows build C PoW doesn't work #1919

New Issue
Closed
opened 2022-01-18 08:04:13 +01:00 by PeterSurda · 17 comments
PeterSurda commented 2022-01-18 08:04:13 +01:00 (Migrated from github.com)
Copy Link

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.

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.
g1itch commented 2022-01-18 14:48:07 +01:00 (Migrated from github.com)
Copy Link

Cool! Let them try the exe from my release. Because I also could not test it properly.

Cool! Let them try the exe from [my release](https://github.com/g1itch/PyBitmessage/releases/tag/continuous). Because I also could not test it properly.
BeholdersEye commented 2022-01-21 22:52:30 +01:00 (Migrated from github.com)
Copy Link

@g1itch I am the person who reported it and can confirm that the release you linked:

  1. Does not display the C pow missing message.
  2. Creates identities / sends messages fast enough that I am comfortable saying it does have the working proof of work module (snapshots that display the message create identities and send messages very slowly).

In other words, working as expected.

@g1itch I am the person who reported it and can confirm that the release you linked: 1. Does not display the C pow missing message. 2. Creates identities / sends messages fast enough that I am comfortable saying it does have the working proof of work module (snapshots that display the message create identities and send messages very slowly). In other words, working as expected.
g1itch commented 2022-01-22 19:17:05 +01:00 (Migrated from github.com)
Copy Link

@g1itch I am the person who reported it and can confirm that the release you linked:

1. Does not display the C pow missing message.

...

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.

> @g1itch I am the person who reported it and can confirm that the release you linked: > > 1. Does not display the C pow missing message. > ... 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.
g1itch commented 2022-01-22 19:26:26 +01:00 (Migrated from github.com)
Copy Link

The first mention seems to be #1622

The first mention seems to be #1622
PeterSurda commented 2022-01-23 02:55:35 +01:00 (Migrated from github.com)
Copy Link

I suspect in this case it's also related to a CPU. Maybe some compilation flags can work around it.

I suspect in this case it's also related to a CPU. Maybe some compilation flags can work around it.
BeholdersEye commented 2022-01-26 22:48:00 +01:00 (Migrated from github.com)
Copy Link

@g1litch:

Also I cannot confirm that the issue appeared in November 2021, I started seeing it in 2019.

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.

@g1litch: > Also I cannot confirm that the issue appeared in November 2021, I started seeing it in 2019. 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.
BeholdersEye commented 2022-02-10 18:59:35 +01:00 (Migrated from github.com)
Copy Link

@PeterSurda: No change on today's snapshot. (20220210)

@PeterSurda: No change on today's snapshot. (20220210)
BeholdersEye commented 2022-02-16 15:09:03 +01:00 (Migrated from github.com)
Copy Link

@PeterSurda: No change on today's snapshot. (20220216)

Perhaps consulting the changelogs around the time of the 20211126 build might help diagnose the problem.

@PeterSurda: No change on today's snapshot. (20220216) Perhaps consulting the changelogs around the time of the 20211126 build might help diagnose the problem.
PeterSurda commented 2022-02-16 15:28:51 +01:00 (Migrated from github.com)
Copy Link

@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.

@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.
BeholdersEye commented 2022-02-16 17:55:45 +01:00 (Migrated from github.com)
Copy Link

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

Using -march=native enables all instruction subsets supported by the local machine (hence the result might not run on different machines).

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.

‘x86-64’

A generic CPU with 64-bit extensions.

Or, in the case of building for 32-bit targets, the march=i686 option.

‘i686’

When used with -march, the Pentium Pro instruction set is used, so the code runs on all i686 family chips. When used with -mtune, it has the same meaning as ‘generic’.

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.

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 > Using -march=native enables all instruction subsets supported by the local machine **(hence the result might not run on different machines).** 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. > ‘x86-64’ > A generic CPU with 64-bit extensions. Or, in the case of building for 32-bit targets, the march=i686 option. > ‘i686’ > When used with -march, the Pentium Pro instruction set is used, so the code runs on all i686 family chips. When used with -mtune, it has the same meaning as ‘generic’. 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.
👍 1
g1itch commented 2022-02-16 19:27:07 +01:00 (Migrated from github.com)
Copy Link

Hmm, I agree. march=native is definitely a mistake.

Hmm, I agree. `march=native` is definitely a mistake.
g1itch commented 2022-02-21 20:24:36 +01:00 (Migrated from github.com)
Copy Link

I've built another release with march=native removed.

I've built another release with `march=native` removed.
BeholdersEye commented 2022-02-22 03:19:04 +01:00 (Migrated from github.com)
Copy Link

@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.

@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.
PeterSurda commented 2022-02-22 03:39:40 +01:00 (Migrated from github.com)
Copy Link

@BeholdersEye if you want, you can make a pull request, then I can have the windows binary built and you can test it

@BeholdersEye if you want, you can make a pull request, then I can have the windows binary built and you can test it
👍 1
BeholdersEye commented 2022-02-22 14:34:29 +01:00 (Migrated from github.com)
Copy Link

@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?

@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?
BeholdersEye commented 2022-02-22 15:33:08 +01:00 (Migrated from github.com)
Copy Link

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.

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.
👍 1
g1itch commented 2022-02-22 15:52:33 +01:00 (Migrated from github.com)
Copy Link

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."

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.

> > 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." 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.
This repo is archived. You cannot comment on issues.
No Branch/Tag Specified
Branches Tags
Labels
Clear labels   
bug

Something isn't working as it's supposed to

  
build

Related to building or build system

  
dependencies

Pull requests that update a dependency file

  
developers

The issue is relevant mainly for developers rather than users

  
documentation

   
duplicate

   
enhancement

New feature

  
formatting

Code or UI text formatting

  
invalid

   
legal

   
mobile

Frontend for mobile devices (kivy)

  
obsolete

   
packaging

   
performance

   
protocol

Protocol change

  
question

   
refactoring

   
regression

Some issue, fixed in the past, appears again

  
security

   
test

   
translation

   
usability

   
wontfix
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
Milestone
Clear milestone
No items
No Milestone
Projects
Clear projects
No project
Assignees
Clear assignees
No Assignees
1 Participants
Due Date
The due date is invalid or out of range. Please use the format 'yyyy-mm-dd'.

No due date set.

Dependencies

No dependencies set.

Reference: Bitmessage/PyBitmessage-2024-12-19#1919
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?