[I7] error whose WASN'T here last time I work with I7

suddenly I7 has started spewing this error instead of compiling:

[code]Unable to load page

Problem occurred while loading the URL file:///home/pigi/if/wrk/inf7/aaa.inform/Build/Problems.html

Error opening file /home/pigi/if/wrk/inf7/aaa.inform/Build/Problems.html: File o directory non esistente

[/code]

some help ?

best regards from Italy,
dott. Piergiorgio.

That’s unexpected. Try navigating to that file and see which part is missing? (I.e. is there a missing directory somewhere along the line? Or is Inform actually failing to generate the Problems.html?)

from what I see, fail to generate (the Build directory is empty, also with ls -a). of course I have checked also the permissions (Debian Linux):

drwxr-xr-x 5 pigi pigi 4096 dic 20 21:25 aaa.inform

aaa.inform$ ls -la
totale 36
drwxr-xr-x 5 pigi pigi 4096 dic 20 21:25 .
drwxr-xr-x 28 pigi pigi 4096 dic 20 21:25 …
drwxr-xr-x 2 pigi pigi 4096 dic 20 21:25 Build
drwxr-xr-x 2 pigi pigi 4096 dic 20 21:25 Index
-rw-r–r-- 1 pigi pigi 217 dic 20 21:25 notes.rtf
-rw-r–r-- 1 pigi pigi 681 dic 20 21:25 Settings.plist
-rw-r–r-- 1 pigi pigi 537 dic 20 21:25 Skein.skein
drwxr-xr-x 2 pigi pigi 4096 dic 20 21:25 Source
-rw-r–r-- 1 pigi pigi 36 dic 20 21:25 uuid.txt

aaa.inform/Build$ ls -la
totale 8
drwxr-xr-x 2 pigi pigi 4096 dic 20 21:25 .
drwxr-xr-x 5 pigi pigi 4096 dic 20 21:25 …

aaa.inform/Build$ whoami
pigi

I have tested touch in all those dirs, and all is OK.

researching a bit more:

having noticed that together the Problems.htm there’s also a very brief “compiling failed” in the statusbar below, i put the commandline in the progress tab into the console:

/usr/lib/x86_64-linux-gnu/gnome-inform7/ni \

-internal /usr/share/gnome-inform7 -format=ulx -project /home/pigi/if/wrk/inf7/aaa.inform
Errore di segmentazione

the system uses my mothertongue when is available, and “Errore di segmentazione” is “Segmentation fault”.

doing the obvious moves here:

ldd /usr/lib/x86_64-linux-gnu/gnome-inform7/ni
non è un eseguibile dinamico
pigi@Dante:~$ file /usr/lib/x86_64-linux-gnu/gnome-inform7/ni
/usr/lib/x86_64-linux-gnu/gnome-inform7/ni: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.26, BuildID[sha1]=02a8ac3b08afbbcc7951dc34dd0b917f04afe6a5, stripped

(“non è un eseguibile dinamico” means “isn’t a dynamic executable”)

things start to be curiouser… mha. Interesting puzzle, I daresay.

Best regards from Italy,
dott. Piergiorgio.

Best

It looks like the original “nonexistent file” message is a consequence of the ni binary crashing. There are some known compiler bugs that result in crashes. Have you tried building a different Inform project? (A simple “Kitchen is a room” one-liner?)

Yes, Zarf, and even tried with the precedent version of I7 (6L38). with midsummer one-liner (aaa.inform being that) and with other small “messing” project(s) the results remains the same.

I have fully disinstalled and reinstalled multiple times both 6L38 and 6M62 (seems that we’re discussing about WWII aircrafts…) with the same result. But I known that during the prior “go” in IF working (from the timestamps, end-October this year) 6M62 worked as designed. and until now, 6L38 worked well in past.

also 6L38 segfaults from the commandline.

any suggestions and/or tests you want I do on this machine (Debian Linux) ?

Best regards from Italy,
dott. Piergiorgio.

I can only guess that some dynamic library in the OS has changed unexpectedly.

Or maybe a preferences file has gotten corrupted? One that would be used by all version of Inform, but not part of the Inform install? Again, I’m just guessing.

well, aside ~/Inform, seems to me that there’s no other preference file(s) that can be involved/corrupted (seems to me that gnome-inform7 for Debian don’t install/create files in /etc and/or /var) and I even moved out ~/Inform, but w/o changes. remain that some dynamic library of debian has changed, but this should not led to a segfault of a static binary, as ni is.

between October and now indeed some Debian libraries was upgraded, but seems that I’m the lone Debian user whose has this issue (of course, prior of posting here, I have checked the prior debates in this sub-forum and also the Inform 7 buglist)

tomorrow I’ll try to look into the libraries upgraded in that time thru apt-get logs.

Best regards from Italy,
dott. Piergiorgio.

no development on this issue; anyway, because on another machine here, I7 6L38 works well, and the WIP and messings are copied on said other machine (albeit more slow than the main one, is fast enough for compiling (I’m from those old days of “start the compilation and go make coffee/tea”, anyway…)

so “solved” in a non-solved manner, so to speak.

Indeed said machine hasn’t an updated Debian. if Nelson of Inform (being a Naval Historian, I must somewhat differentiate from Nelson of Copenaghen and the Nile…) can provide a list of the libraries (and versions…) used in building ni 6L38 and 6M62…

Update: looking from another angle, seems that I7 looks for both libglib2.0.0 i386 and libglib2.0.0 amd64. and for me calling a 32-bit library routine instead of a 64-bit lib routine (or vice-versa) makes inevitable that ni segfaults.

Any opinion on this point ?

Best regards from Italy,
dott. Piergiorgio.

update, hopefully final:

I7 6M62 automagickally works again, meaning that I don’t know why it returned to behave as designed.

I can only assume that the issue was what Zarf suggested, that some Debian library upgrade was bugged re. ni, and now is fixed.
so, I formally suggest that Graham gives the list of libraries used in building ni, so at least people whose hit this issue can figure what library/ies should be reverted to prior version(s).

so, case solved by itself… not a glorious thing for my coder/hacker pride, I admit.

Best regards from Italy,
dott. Piergiorgio.

It appears I have the same problem, except it didn’t solve itself.
My system is up to date:

Operating System: Debian GNU/Linux buster/sid
Kernel: Linux 4.13.0-1-amd64
Architecture: x86-64

Piergiorgio, does I7 still work for you?

yes, still work with zcode. often crash with glulx, but not always.