Linux assembly failure, and "savedir support FUBAR"

[thewanderer]

On my Linux system, tracking ZSNES SVN, video/newg162.asm has failed to assemble for quite some time now when using the (default with --enable-release) -O99999999 option to nasm. There are no error messages; it just sits there with max CPU usage indefinitely. Manually running the command with -O0 instead completes without problems. (This is with both my installed 0.98.38-1.2, the latest available via Debian unstable, and a copy of 0.98.39 which I compiled from source.) For the record, the resulting zsnes binary appears to work just fine - and does not exhibit the fweird problem I've been seeing in Breath of Fire for ages now, which I hadn't reported because I was never sure it was not some problem with my own system.

Given the lack of error messages, what can I do to figure out more precisely what the cause of this problem is?


Also, as long as I'm here: back on May 31, there was a SVN commit whose commit message carried a warning that it rendered save-directory support FUBAR and that 'production' use of SVN was not recommended until the problem was fixed. No further mention of this has been made in commit messages since that time that I've been able to see. Can I get an official word as to whether or not the problem has been resolved, so that I can know whether or not it is safe to actually install new ZSNES binaries again?

(I mean, I can infer certain things from the fact that a release was made, but I am Not Comfortable taking risks with things which were explicitly stated to be not working.)

[Nach]

On my Linux system, tracking ZSNES SVN, video/newg162.asm has failed to assemble for quite some time now when using the (default with --enable-release) -O99999999 option to nasm. There are no error messages; it just sits there with max CPU usage indefinitely. Manually running the command with -O0 instead completes without problems. (This is with both my installed 0.98.38-1.2, the latest available via Debian unstable, and a copy of 0.98.39 which I compiled from source.) For the record, the resulting zsnes binary appears to work just fine - and does not exhibit the fweird problem I've been seeing in Breath of Fire for ages now, which I hadn't reported because I was never sure it was not some problem with my own system.

Given the lack of error messages, what can I do to figure out more precisely what the cause of this problem is?

The problem is your lack of patience. Let it finish compiling.

Also, as long as I'm here: back on May 31, there was a SVN commit whose commit message carried a warning that it rendered save-directory support FUBAR and that 'production' use of SVN was not recommended until the problem was fixed. No further mention of this has been made in commit messages since that time that I've been able to see. Can I get an official word as to whether or not the problem has been resolved, so that I can know whether or not it is safe to actually install new ZSNES binaries again?

(I mean, I can infer certain things from the fact that a release was made, but I am Not Comfortable taking risks with things which were explicitly stated to be not working.)

Every single path fix was mentioned explicitly in SVN. As well as officially mentioned here on the forum when a WIP some months later was made.

We would not have any kind of release knowing that save paths is completely broken.

[Deathlike2]

On my Linux system, tracking ZSNES SVN, video/newg162.asm has failed to assemble for quite some time now when using the (default with --enable-release) -O99999999 option to nasm. There are no error messages; it just sits there with max CPU usage indefinitely. Manually running the command with -O0 instead completes without problems. (This is with both my installed 0.98.38-1.2, the latest available via Debian unstable, and a copy of 0.98.39 which I compiled from source.) For the record, the resulting zsnes binary appears to work just fine - and does not exhibit the fweird problem I've been seeing in Breath of Fire for ages now, which I hadn't reported because I was never sure it was not some problem with my own system.

Given the lack of error messages, what can I do to figure out more precisely what the cause of this problem is?

The problem is your lack of patience. Let it finish compiling.

To add, the slower your computer, the longer it will take to compile.

Also, as long as I'm here: back on May 31, there was a SVN commit whose commit message carried a warning that it rendered save-directory support FUBAR and that 'production' use of SVN was not recommended until the problem was fixed. No further mention of this has been made in commit messages since that time that I've been able to see. Can I get an official word as to whether or not the problem has been resolved, so that I can know whether or not it is safe to actually install new ZSNES binaries again?

(I mean, I can infer certain things from the fact that a release was made, but I am Not Comfortable taking risks with things which were explicitly stated to be not working.)

Every single path fix was mentioned explicitly in SVN. As well as officially mentioned here on the forum when a WIP some months later was made.

We would not have any kind of release knowing that save paths is completely broken.

We intentionally held off releasing a WIP until this was explicitly resolved. If you paid any attention to the commit messages between that period of time, it was fixed in a timely manner and every bug that came up was addressed (including ones for the DOS port).

[thewanderer]

On my Linux system, tracking ZSNES SVN, video/newg162.asm has failed to assemble for quite some time now when using the (default with --enable-release) -O99999999 option to nasm. There are no error messages; it just sits there with max CPU usage indefinitely. Manually running the command with -O0 instead completes without problems. (This is with both my installed 0.98.38-1.2, the latest available via Debian unstable, and a copy of 0.98.39 which I compiled from source.) For the record, the resulting zsnes binary appears to work just fine - and does not exhibit the fweird problem I've been seeing in Breath of Fire for ages now, which I hadn't reported because I was never sure it was not some problem with my own system.

Given the lack of error messages, what can I do to figure out more precisely what the cause of this problem is?

The problem is your lack of patience. Let it finish compiling.

To add, the slower your computer, the longer it will take to compile.

Naturally. However, I don't think this is plausible.

Every other file in the compilation process takes, ballpark, no more than around a minute to finish compiling with -O999999 (or whatever it was). I've routinely seen this one file take five to ten minutes without finishing; I'm fairly sure I've seen it take more than half an hour (when I start the compile, go do other things, and come back later to realize it's still hung there). Changing to -O0 let it finish in less than a minute.

However, we can test this; before I leave for work today, I will start the process of recompiling that file,. We'll see if it's still going when I get back this evening.

Also, as long as I'm here: back on May 31, there was a SVN commit whose commit message carried a warning that it rendered save-directory support FUBAR and that 'production' use of SVN was not recommended until the problem was fixed. No further mention of this has been made in commit messages since that time that I've been able to see. Can I get an official word as to whether or not the problem has been resolved, so that I can know whether or not it is safe to actually install new ZSNES binaries again?

(I mean, I can infer certain things from the fact that a release was made, but I am Not Comfortable taking risks with things which were explicitly stated to be not working.)

Every single path fix was mentioned explicitly in SVN. As well as officially mentioned here on the forum when a WIP some months later was made.

We would not have any kind of release knowing that save paths is completely broken.

We intentionally held off releasing a WIP until this was explicitly resolved. If you paid any attention to the commit messages between that period of time, it was fixed in a timely manner and every bug that came up was addressed (including ones for the DOS port).

I did pay attention to the commit messages. I saw many things which looked to be path-related of the form "XXX is dead, long live YYY", but those of us who do not know the code have no way of knowing how closely (or indeed even whether) these were related to the breakage mentioned - and, even if we assume that they all are, we have no way of knowing when *all* of them have been fixed and the overall problem is resolved. IIRC I once asked on IRC whether or not a note like the one announcing the breakage would be made when the last of the problem was resolved; I don't think I got an answer, but apparently no such note did get made. (I don't have the time to follow the forum closely, so it's no surprise that I missed that announcement.)

Regardless, however, I'm glad to know that I can in fact comfortably use ZSNES once again without having to worry about minor things. Thank you for the work you've put into this.