Compiling problems Debian Sarge (32bit)

[robbo007]

Compiling problems Debian Sarge (32bit)

[kej715]

Hi, "useconds_t" is defined in unistd.h, and is defined by the usleep() system service. Debian Sarge is quite ancient (17+ years old), and it has been archived. More contemporary versions of Debian will have usleep() and useconds_t. Is it possible for you to upgrade? cheers, Kevin

…

On Mon, May 30, 2022 at 9:00 AM robbo007 ***@***.***> wrote: Hi, I'm trying to compile under Debian Sarge and I get the following error: CYBER:/cyber/DtCyber-main# make -f Makefile.linux32 dtcyber cc -02 -I. -I/usr/X11R6/include -std=gnu99 -c operator.c operator.c: In function 'opWait': operator.c:1886: error: useconds t'undeclared (first use in this function) operator.c:1086: error: (Each undeclared identifier is reported only once operator.c:1086: error: for each function it appears in.) make: *** [operator.o] Error 1 CYBER:/cuber/DtCyber-main# Any ideas? — Reply to this email directly, view it on GitHub <#4>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABALGRCWEHBVKGSUHUOUXTVMS3XHANCNFSM5XKQHP4Q> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[robbo007]

Hi Kevin,
Unfortunately I do as its the only version that seems to work with my hardware. Is there a work around for this?

[kej715]

Hi, The operator.c module needs to be able to sleep for a number of milliseconds. usleep() accomplishes this on Linux (except, apparently, old versions of Debian), and Sleep() accomplishes it on Windows. See this Stack Overflow article about sleeping for milliseconds in Linux: https://stackoverflow.com/questions/1157209/is-there-an-alternative-sleep-function-in-c-to-milliseconds The article provides a workaround for systems that do not have usleep() or nanosleep() -- it suggests using select() with all bit vectors NULL. The article also mentions that usleep() has been deprecated, and nanosleep() should be used instead, so DtCyber should be updated to use nanosleep instead of usleep. Unfortunately, that probably won't work on Debian Sarge either, so using select() is probably the best (and only) workaround. cheers, Kevin

…

On Mon, May 30, 2022 at 11:45 AM robbo007 ***@***.***> wrote: Hi Kevin, Unfortunately I do as its the only version that seems to work with my hardware. Is there a work around for this? — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABALGXORKO3K6UM5HCO6FTVMTPCFANCNFSM5XKQHP4Q> . You are receiving this because you commented.Message ID: ***@***.***>

[wschaub]

I pulled out a copy of sarge via the magic of docker and played around, it looks like what we need is hidden behind feature macro tests.

Try replacing the CFLAGS line in your Makefile with this and tell me how it goes, I got it to compile with the latest github checkout with this in the sarge docker container but I haven't tested the resulting binary.

CFLAGS = -O2 -D_GNU_SOURCE -I. $(INCL) -std=gnu99

[robbo007]

@wschaub Amazing thanks :) That seemed to compile ok. I forgot to install the libx11-dev package as well so I added them. I now need to configure and see if I can get it loading. I'll keep you posted. Regards.

[wschaub]

I just did another test on the sarge container, this time to test if the ancient glibc supports nanosleep. looks like it does, and without any need to set a define, pulling in <time.h> will get you the definition of timespec and nanosleep.

The sarge manpage for nanosleep has this in the BUGS section:
`BUGS
The current implementation of nanosleep is based on the normal kernel timer mechanism, which has a resolution of 1/HZ s (i.e, 10 ms on Linux/i386 and 1 ms on Linux/Alpha).
Therefore, nanosleep pauses always for at least the specified time, however it can take up to 10 ms longer than specified until the process becomes runnable again. For the same
reason, the value returned in case of a delivered signal in *rem is usually rounded to the next larger multiple of 1/HZ s.

Old behaviour
In order to support applications requiring much more precise pauses (e.g., in order to control some time-critical hardware), nanosleep would handle pauses of up to 2 ms by busy
waiting with microsecond precision when called from a process scheduled under a real-time policy like SCHED_FIFO or SCHED_RR. This special extension was removed in kernel
2.5.39, hence is still present in current 2.4 kernels, but not in 2.6 kernels.
`

[kej715]

Thanks William! If nanosleep is supported in the ancient version of Debian, then that makes replacing usleep by nanosleep even more compelling. I'll set to work on that right away. cheers, Kevin

…

On Mon, May 30, 2022 at 3:59 PM William Schaub ***@***.***> wrote: I just did another test on the sarge container, this time to test if the ancient glibc supports nanosleep. looks like it does, and without any need to set a define, pulling in <time.h> will get you the definition of timespec and nanosleep. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABALGR2XMK3UUVY6GTYWDLVMUM2JANCNFSM5XKQHP4Q> . You are receiving this because you commented.Message ID: ***@***.***>

[wschaub]

I went through and tried to get everything working possible on sarge, I got enough working to run the automation scripts to build NOS1.3 and NOS2.8.7 but I wasn't able to get git-lfs working because Go does not support 2.6 and below kernels anymore.

I uploaded the updated curl, openssl, git, tcl and expect here https://steubentech.com/sarge-tools/

[robbo007]

Hi @wschaub,
Does this mean NOS won't run then. Not having support for git-lfs-3.2.0 and go1.18.2? Should I concentrate getting my hardware to work with maybe Debian Lenny?

[wschaub]

dtcyber and NOS will run just fine, only git-lfs doesn't work. Basically what that means is you would probably need to fetch dtcyber on a machine that you can install git-lfs on and then copy the tap.bz2 files over to the sarge machine. I have a snapshot of Dtcyber on that page from earlier today that has all the tape files expanded so you can easily test.

[robbo007]

@wschaub ok thanks for clarifying that. I've manged to get it compiled. I have all the files that Tom Hunter gave me back in the day.

dtcyber loads but then dumps back to Debian with a "could not open display" error. Could this be because Xwindows is holding the resources?

Desktop CYBER 5.6.1 - Copyright (C) Tom Hunter
Licensed under the terms of the GNU General Public License version 3

Starting initialisation
Unexpected length of CM backing file, clearing CM
CPU model CYBER865 initialised (CM: 4000000, ECS: 0)
Unexpected length of PPM backing file, clearing PPM
PPs initialised (number of PPUs 24)
Channels initialised (number of channels 40)
Using gettimeofday() clock at 1.000000 MHz
Status/Control Register initialised on channel 16
Status/Control Register initialised on channel 36
Disk with 843 cylinders initialised on channel 1 unit 0
Disk with 843 cylinders initialised on channel 2 unit 0
Disk with 843 cylinders initialised on channel 3 unit 0
Disk with 843 cylinders initialised on channel 4 unit 0
Disk with 843 cylinders initialised on channel 1 unit 1
Disk with 843 cylinders initialised on channel 2 unit 1
Disk with 843 cylinders initialised on channel 3 unit 1
Disk with 843 cylinders initialised on channel 4 unit 1
Disk with 843 cylinders initialised on channel 1 unit 2
Disk with 843 cylinders initialised on channel 2 unit 2
Disk with 843 cylinders initialised on channel 3 unit 2
Disk with 843 cylinders initialised on channel 4 unit 2
Console initialised on channel 10
Equipment 07, Unit 00 attached to DCC6681 on channel 7
LP3555/512 initialised on channel 7 equipment 7
Equipment 07, Unit 00 attached to DCC6681 on channel 11
CR3447 initialised on channel 11 equipment 7
Equipment 06, Unit 00 attached to DCC6681 on channel 11
CP3446 initialised on channel 11 equipment 6
MT679 initialised on channel 13 equipment 0 unit 0
MT679 initialised on channel 13 equipment 0 unit 1
MT679 initialised on channel 13 equipment 0 unit 2
MT679 initialised on channel 13 equipment 0 unit 3
Two port MUX initialised on channel 15
NPU initialised on channel 5 equipment 7
       Host ID: CYBER
  Coupler node: 1
      NPU node: 2

Desktop CYBER 5.6.1 - Copyright (C) Tom Hunter.
Licensed under the terms of the GNU General Public License version 3.
For details see included text file 'license-gpl-3.0.txt' or visit
'http://www.gnu.org/licenses'.

Operator interface
Please enter 'help' to get a list of commands

Operator>/cyber/CybisRelease1#

[kej715]

If you are running DtCyber on a different host than the host serving the display, then "could not open display" might indicate that you have not authorized other hosts to connect to the display server. In this case, you can execute the "xhost" command on the host serving the display to make the display available to other hosts. If you are running DtCyber on the same host that is serving the display, then the error might mean that your DISPLAY variable is not set, or it is set to an incorrect value. This could also be the cause when DtCyber is running on a different host then the one serving the display.

…

On Tue, May 31, 2022 at 6:58 AM robbo007 ***@***.***> wrote: @wschaub <https://github.com/wschaub> ok thanks for clarifying that. I've manged to get it compiled. I have all the files that Tom Hunter gave me back in the day. dtcyber loads but then dumps back to Debian with a "could not open display" error. Could this be because Xwindows is holding the resources? Desktop CYBER 5.6.1 - Copyright (C) Tom Hunter Licensed under the terms of the GNU General Public License version 3 Starting initialisation Unexpected length of CM backing file, clearing CM CPU model CYBER865 initialised (CM: 4000000, ECS: 0) Unexpected length of PPM backing file, clearing PPM PPs initialised (number of PPUs 24) Channels initialised (number of channels 40) Using gettimeofday() clock at 1.000000 MHz Status/Control Register initialised on channel 16 Status/Control Register initialised on channel 36 Disk with 843 cylinders initialised on channel 1 unit 0 Disk with 843 cylinders initialised on channel 2 unit 0 Disk with 843 cylinders initialised on channel 3 unit 0 Disk with 843 cylinders initialised on channel 4 unit 0 Disk with 843 cylinders initialised on channel 1 unit 1 Disk with 843 cylinders initialised on channel 2 unit 1 Disk with 843 cylinders initialised on channel 3 unit 1 Disk with 843 cylinders initialised on channel 4 unit 1 Disk with 843 cylinders initialised on channel 1 unit 2 Disk with 843 cylinders initialised on channel 2 unit 2 Disk with 843 cylinders initialised on channel 3 unit 2 Disk with 843 cylinders initialised on channel 4 unit 2 Console initialised on channel 10 Equipment 07, Unit 00 attached to DCC6681 on channel 7 LP3555/512 initialised on channel 7 equipment 7 Equipment 07, Unit 00 attached to DCC6681 on channel 11 CR3447 initialised on channel 11 equipment 7 Equipment 06, Unit 00 attached to DCC6681 on channel 11 CP3446 initialised on channel 11 equipment 6 MT679 initialised on channel 13 equipment 0 unit 0 MT679 initialised on channel 13 equipment 0 unit 1 MT679 initialised on channel 13 equipment 0 unit 2 MT679 initialised on channel 13 equipment 0 unit 3 Two port MUX initialised on channel 15 NPU initialised on channel 5 equipment 7 Host ID: CYBER Coupler node: 1 NPU node: 2 Desktop CYBER 5.6.1 - Copyright (C) Tom Hunter. Licensed under the terms of the GNU General Public License version 3. For details see included text file 'license-gpl-3.0.txt' or visit 'http://www.gnu.org/licenses'. Operator interface Please enter 'help' to get a list of commands Operator>/cyber/CybisRelease1# — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABALGU3PW5QTR6JSRAKB7TVMXWEVANCNFSM5XKQHP4Q> . You are receiving this because you commented.Message ID: ***@***.***>

[robbo007]

Got it working :) Thanks to you both. Problem was with Xwindows.

[kej715]

Normally, the value of the DISPLAY variable should look like ":0.0" (notice the leading colon) when the client is running on the same host as the display server, not "0.0" (lacking a leading colon). The colon separates the host name of the display server from the display identifier, so if you're specifying "0.0" instead of ":0.0", DtCyber is probably trying to connect to a display server on a host named "0.0".

…

On Tue, May 31, 2022 at 11:39 AM robbo007 ***@***.***> wrote: Closed #4 <#4> as completed. — Reply to this email directly, view it on GitHub <#4 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AABALGTRBA4VF7TQEJ4EHTLVMYXDRANCNFSM5XKQHP4Q> . You are receiving this because you commented.Message ID: ***@***.***>