View Single Post
2021-08-21, 15:44   #4
M344587487

"Composite as Heck"
Oct 2017

11011001102 Posts
r4

Here's some build results with different uasm versions with 30.3b6, uasmw means the windows binary wrapped with wine and the number is the version. Earlier I thought factor64 was successfully assembled with something but I'd accidentally tested with an altered asm file.

1 for successfully built on CentOS 7, 0 for fail:
Code:
CentOS7 factor32 factor64 gwnum32 gwnum64
uasm245       1        0       0       0
uasm250       1        0       1       0
uasm254       0        0       0       0
uasmw248      0        0       1       1
uasmw252      1        0       1       0
Ubuntu 20.04 was the same except uasm245 also successfully built gwnum32. The uasm binaries used are the same on both OS's so the difference is weird, at least the failures/successes have so far been repeatable. uasm245 and uasm254 were found online (v2.54 is from an experimental branch and v2.45 is the newest version available from the main site). George can you definitely successfully assemble factor32 and factor64 with v2.48? UASM is a strange one.

I have no confidence that 32 bit anything is actually built properly (or 64 bit for that matter), all success means is that every target in the makefile completed so all expected object files exist.

Attached are the scripts in their current state, and an (entirely at own risk) mprime binary built on CentOS 7 using gwnum64 built from scratch and the factor64 object supplied with the source. It seems to work but hasn't been tested thoroughly. To use the scripts put them in the root directory, see readme. To build the 64 bit binary as attached you run the build_gwnum64 script (using appropriate uasm location) from the root directory then build gwnum and mprime as normal with gwnum/make64 and linux64/make.
Attached Files
 mprime_r4.xz (1.91 MB, 42 views) r4.tar.xz (2.1 KB, 39 views)