I know there are not many of us Synchronet running on Raspberry Pi, but I was doing some testing on my second Pi which is running the latest Raspbian Wheezy build (just downloaded yesterday). Installed all pre-requisites and downloaded latest source and compiled... I didn't notice any errors and it appeared everything compiled correctly but when I run scfg, the entire screen goes blank
and nothing happens. I actually freezes the whole system and I cannot get into the other consoles (Alt-F1, Alt-F2, etc). I have to power off the system and start it up again. Just out of curisoity, I compared the executuable files from
a working scfg and the bad scfg and the file size of the bad one is approximatly doubled.

First I thought it was a complile issue so I deleted the sbbs folder (including
source) and started over... same issue. Next step, I started the whole system over from scratch (reinstalled Raspbian Wheezy, latest build) but still had the
problem.

I am now trying it on the other Raspberry Pi with and old OS build... I had just re-compiled on it a few days ago without any issue.

Now unfortunatly, it takes about 2.5 hours to complile on the PI, so I will know in an hour or so if it works...

Is it possible to recompile just the scfg file by itself?

Is there a compile log (or a switch to turn on the log) that I can examine later?

Anyone else think of something else I can do to figure this out?

Thanks for any ideas / help. :)


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: High Spirit to All on Sun May 24 2015 03:10 pm

I am now trying it on the other Raspberry Pi with and old OS build... I had just re-compiled on it a few days ago without any issue.

Just got home and confirmed the build on the old OS works fine.

Filesize of the old os build (Working): 697026
Filesize of the new os build (Not Working): 1070920

I also never bothered to check the filesizes of the other executables...

Filesize of old os build files:
-rwxr-xr-x 1 root root 190454 May 24 16:12 addfiles
-rwxr-xr-x 1 root root 55896 May 24 16:13 allusers
-rwxr-xr-x 1 root root 11038 May 24 16:12 ans2asc
-rwxr-xr-x 1 root root 10393 May 24 16:12 asc2ans
-rwxr-xr-x 1 root root 102879 May 24 16:07 baja
-rwxr-xr-x 1 root root 118171 May 24 16:06 chksmb
-rwxr-xr-x 1 root root 123585 May 24 16:13 delfiles
-rwxr-xr-x 1 root root 37960 May 24 16:14 dstsedit
-rwxr-xr-x 1 root root 113111 May 24 16:13 dupefind
-rwxr-xr-x 1 root root 212233 May 24 16:11 echocfg
-rwxr-xr-x 1 root root 132111 May 24 16:12 filelist
-rwxr-xr-x 1 root root 112169 May 24 16:05 fixsmb
-rwxr-xr-x 1 root root 245166 May 24 16:16 jsexec
-rwxr-xr-x 1 root root 160300 May 24 16:12 makeuser
-rwxr-xr-x 1 root root 18594 May 24 16:07 node
-rwxr-xr-x 1 root root 168546 May 24 16:13 qwknodes
-rwxr-xr-x 1 root root 148492 May 24 16:16 sbbs
-rwxr-xr-x 1 root root 387130 May 24 16:11 sbbsecho
-rwxr-xr-x 1 root root 161338 May 24 16:14 sexyz
-rwxr-xr-x 1 root root 30870 May 24 16:13 slog
-rwxr-xr-x 1 root root 158681 May 24 16:13 smbactiv
-rwxr-xr-x 1 root root 143839 May 24 16:06 smbutil
-rwxr-xr-x 1 root root 92456 May 24 16:13 unbaja

Filesizes of new os build:
-rwxr-xr-x 1 root root 190453 May 24 15:51 addfiles
-rwxr-xr-x 1 root root 55904 May 24 15:53 allusers
-rwxr-xr-x 1 root root 10985 May 24 15:51 ans2asc
-rwxr-xr-x 1 root root 10340 May 24 15:51 asc2ans
-rwxr-xr-x 1 root root 102878 May 24 15:47 baja
-rwxr-xr-x 1 root root 118170 May 24 15:45 chksmb
-rwxr-xr-x 1 root root 123601 May 24 15:53 delfiles
-rwxr-xr-x 1 root root 37968 May 24 15:54 dstsedit
-rwxr-xr-x 1 root root 113119 May 24 15:53 dupefind
-rwxr-xr-x 1 root root 589031 May 24 15:51 echocfg
-rwxr-xr-x 1 root root 132110 May 24 15:51 filelist
-rwxr-xr-x 1 root root 112168 May 24 15:45 fixsmb
-rwxr-xr-x 1 root root 617669 May 24 15:56 jsexec
-rwxr-xr-x 1 root root 160299 May 24 15:51 makeuser
-rwxr-xr-x 1 root root 18561 May 24 15:47 node
-rwxr-xr-x 1 root root 168545 May 24 15:52 qwknodes
-rwxr-xr-x 1 root root 148500 May 24 15:55 sbbs
-rwxr-xr-x 1 root root 387176 May 24 15:50 sbbsecho
-rwxr-xr-x 1 root root 161432 May 24 15:54 sexyz
-rwxr-xr-x 1 root root 30886 May 24 15:53 slog
-rwxr-xr-x 1 root root 158689 May 24 15:53 smbactiv
-rwxr-xr-x 1 root root 143806 May 24 15:46 smbutil
-rwxr-xr-x 1 root root 92423 May 24 15:52 unbaja

There is no problem running the executables if I copy them over to the new OS from the old.

Any ideas where I should start? :)

-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: High Spirit to All on Sun May 24 2015 03:10 pm

I know there are not many of us Synchronet running on Raspberry Pi, but I was doing some testing on my second Pi which is running the latest Raspbian Wheezy build (just downloaded yesterday). Installed all pre-requisites and downloaded latest source and compiled... I didn't notice any errors and it appeared everything compiled correctly but when I run scfg, the entire screen goes blank and nothing happens. I actually freezes the whole system and I cannot get into the other consoles (Alt-F1, Alt-F2, etc). I have to power off the system and start it up again. Just out of curisoity, I compared the executuable files from a working scfg and the bad scfg and the file size of the bad one is approximatly doubled.

Release builds are smaller than debug builds. 32-bit builds are smaller than 64-bit builds. Could either of those explain the file size change?

First I thought it was a complile issue so I deleted the sbbs folder (including source) and started over... same issue. Next step, I started the whole system over from scratch (reinstalled Raspbian Wheezy, latest build) but still had the problem.

SCFG can be run with different user interfaces. Try "scfg -id" for example for the simplest of user interfaces and see if that works.

I am now trying it on the other Raspberry Pi with and old OS build... I had just re-compiled on it a few days ago without any issue.

Now unfortunatly, it takes about 2.5 hours to complile on the PI, so I will know in an hour or so if it works...

Is it possible to recompile just the scfg file by itself?

Yes. Running 'make' in the src/sbbs3/scfg director will just remake SCFG.

Is there a compile log (or a switch to turn on the log) that I can examine later?

Just the scroll-back of your console.

digital man

Synchronet "Real Fact" #68:
You can purchase the BBS Documentary DVD set at http://bbsdocumentary.com/order/
Norco, CA WX: 60.1øF, 79.0% humidity, 4 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Sun May 24 2015 09:39 pm

Release builds are smaller than debug builds. 32-bit builds are smaller than 64-bit builds. Could either of those explain the file size change?

Raspberry Pi is 32-bit. I had thought of that... The latest OS has support for the Raspberry Pi 2 which is a newer Arm CPU (still don't think it is 64-bit though).

SCFG can be run with different user interfaces. Try "scfg -id" for example for the simplest of user interfaces and see if that works.

Will give that a try. :)

Yes. Running 'make' in the src/sbbs3/scfg director will just remake SCFG. Just the scroll-back of your console.

I had a feeling that would be the case. It will save a lot of compiling time! :)

Thanks DM.

-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Mon May 25 2015 07:56 am

SCFG can be run with different user interfaces. Try "scfg -id" for example for the simplest of user interfaces and see if that works.

Will give that a try. :)

I have confirmed, "scfg -id" does work. I get the basic menu and can work around in scfg.

Now I just noticed something, previous attempts running the executable blanked the screen and locked up the system. I just ran the executable in a SSH session
from another system and I got the scfg copyright message in my terminal and the
screen that is plugged into the Raspberry Pi went blank and is locked up. So it
is getting to a certain point and then crashing...

I also have a post in the Raspberry Pi support boards to see if anyone else has
issues compiling stuff or if anyone has any ideas.

My Pi OS is from a year and a half ago. Newer OS's are built to work on the Older Pi (ARM11) and Raspberry Pi 2 (ARM Cortex-A7) so there are big differences in the OS, I belive.


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

On Sun, 24 May 2015, High Spirit wrote to All:

Is there a compile log (or a switch to turn on the log) that I can examine later?

we use the following script when we update sbbs... we start it like this...

cd /sbbs
./updatesbbs.sh 2>&1 | tee /sbbs/updatesbbs_$(date +'%Y%m%d%H%M').log

the script pulls everything from the repo and then runs the compile process...

watch the line wrap in the "compiling" section below... there's only 7 lines counting the one that echos "compiling synchronet [...]"...

===== snip updatesbbs.sh =====
#!/bin/bash
cd /sbbs
echo "saving CTRL directory"
echo "tar -czf ctrl_$(date '+%Y%m%d%H%M').tgz ctrl"
tar -czf ctrl_$(date '+%Y%m%d%H%M').tgz ctrl

echo "saving EXEC directory"
echo "tar -czf exec_$(date '+%Y%m%d%H%M').tgz exec"
tar -czf exec_$(date '+%Y%m%d%H%M').tgz exec

export CVSROOT=:pserver:anonymous@cvs.synchro.net:/cvsroot/sbbs
echo "cvs update of EXEC directory"
cvs update -d exec

echo "cvs update of SRC and 3RDP directory"
cvs update -d src 3rdp

echo "cvs update of XTRN directory"
cvs update -d xtrn

echo "cleaning source directories"
echo "** CONIO **"
cd /sbbs/src/conio; sudo gmake clean
echo "** SBBS3 **"
cd /sbbs/src/sbbs3; sudo gmake clean
echo "** SBBS3/SCFG **"
cd /sbbs/src/sbbs3/scfg; sudo gmake clean
echo "** EXEC **"
cd /sbbs/exec; sudo gmake clean

echo "compiling synchronet and baja modules"
echo "** SBBS3 **"
cd /sbbs/src/sbbs3; sudo gmake RELEASE=1 SYMLINK=1 USEDOSEMU=1 SBBSUSER=sbbs SBBSGROUP=sbbs
echo "** SBBS3/SCFG **"
cd /sbbs/src/sbbs3/scfg; sudo gmake RELEASE=1 SYMLINK=1 USEDOSEMU=1 SBBSUSER=sbbs SBBSGROUP=sbbs
echo "** EXEC **"
cd /sbbs/exec; sudo gmake RELEASE=1 SYMLINK=1 USEDOSEMU=1 SBBSUSER=sbbs SBBSGROUP=sbbs

#echo running UPDATE.JS
#/sbbs/exec/jsexec update.js
cd /sbbs
echo "SBBS CVS update and compile complete!"
echo "restart sbbs by entering \"sudo /etc/init.d/sbbs restart\""

===== snip =====


)\/(ark


* Origin: (1:3634/12)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: mark lewis to High Spirit on Mon May 25 2015 12:30 pm

we use the following script when we update sbbs... we start it like this...

I have a script on the current BBS which I can do exactly that. I am upgrading my host OS and it is causing compile issues for some reason. The executables work fine if I copy them over from the old OS, but once I am running on the new
OS, I will not be able to re-compile unless I do it on the old OS.

It's challenging me and I like it. ;)

-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Mon May 25 2015 10:42 am

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Mon May 25 2015 07:56 am

SCFG can be run with different user interfaces. Try "scfg -id" for example for the simplest of user interfaces and see if that works.

Will give that a try. :)

I have confirmed, "scfg -id" does work. I get the basic menu and can work around in scfg.

Now I just noticed something, previous attempts running the executable blanked the screen and locked up the system. I just ran the executable in a SSH session from another system and I got the scfg copyright message in my terminal and the screen that is plugged into the Raspberry Pi went blank and is locked up. So it is getting to a certain point and then crashing...

Crashing (e.g. segfaulting) or just hanging? There is a difference.

There are other inteface/output modes SCFG supports as well. Experiment with the differnet "-i" options and find out what might be the problematic mode.

digital man

Synchronet "Real Fact" #19:
Michael Swindell was directly responsible for Synchronet's commercial success. Norco, CA WX: 69.7øF, 63.0% humidity, 7 mph SSE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 03:58 pm

Crashing (e.g. segfaulting) or just hanging? There is a difference.

It is taking out the whole system as I cannot do a Alt-F1, Alt-F2, etc to get into the other consoles in linux and it kills my SSH connections into it.

There are other inteface/output modes SCFG supports as well. Experiment with the differnet "-i" options and find out what might be the problematic mode.

I will give that a shot tomorrow and see what modes work. Hopfully it will point me in the right direction... any thoughts on why the scfg executable would compile twice it's normal size on the new OS?

Thanks DM for all your help. :)


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

On Mon, 25 May 2015, High Spirit wrote to mark lewis:

we use the following script when we update sbbs... we start it like
this...

I have a script on the current BBS which I can do exactly that. I
am upgrading my host OS and it is causing compile issues for some reason. The executables work fine if I copy them over from the
old OS, but once I am running on the new OS, I will not be able
to re-compile unless I do it on the old OS.

It's challenging me and I like it. ;)

i hear ya... hopefully the command line i posted that we used for our script will be handy for you... it provides the logging part you were initially asking
about ;)

)\/(ark


* Origin: (1:3634/12)

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Mon May 25 2015 09:47 pm

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 03:58 pm

Crashing (e.g. segfaulting) or just hanging? There is a difference.

It is taking out the whole system as I cannot do a Alt-F1, Alt-F2, etc to get into the other consoles in linux and it kills my SSH connections into it.

Does it respond to a 'ping'?

There are other inteface/output modes SCFG supports as well. Experiment with the differnet "-i" options and find out what might be the problematic mode.

I will give that a shot tomorrow and see what modes work. Hopfully it will point me in the right direction... any thoughts on why the scfg executable would compile twice it's normal size on the new OS?

Debug builds are larger than release builds, as I already mentioned. Could that
be it?

digital man

Synchronet "Real Fact" #22:
The third ever Synchronet BBS was The Beast's Domain (sysop: King Drafus). Norco, CA WX: 59.0øF, 86.0% humidity, 5 mph SE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 09:56 pm

Does it respond to a 'ping'?

No reponse from ping.

Debug builds are larger than release builds, as I already mentioned. Could that be it?

I will check that out for sure.

Thanks

-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 09:56 pm

Debug builds are larger than release builds, as I already mentioned. Could that be it?

Just confirmed that I am compiling a release and not a debug build...

Here is what I got when I compiled the SCFG executabe on the NEW OS:

make DEBUG=1 : 1957891 bytes.
make RELEASE=1: 1070920 bytes.

For the hell of it, I did the same on the old OS/working executables:

make DEBUG=1 : 1432083 bytes.
make RELEASE=1: 697026 bytes.


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 03:58 pm

There are other inteface/output modes SCFG supports as well. Experiment with the differnet "-i" options and find out what might be the problematic mode.

Got strange results on this...

Command Result
./scfg Crash system
./scfg -iD Works
./scfg -iC Works
./scfg -af Works
./scfg -aA Works but seems sluggish.

So would that be something in the auto detect if '-i' is not provided?


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Wed May 27 2015 09:43 am

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 09:56 pm

Debug builds are larger than release builds, as I already mentioned. Could that be it?

Just confirmed that I am compiling a release and not a debug build...

Here is what I got when I compiled the SCFG executabe on the NEW OS:

make DEBUG=1 : 1957891 bytes.
make RELEASE=1: 1070920 bytes.

For the hell of it, I did the same on the old OS/working executables:

make DEBUG=1 : 1432083 bytes.
make RELEASE=1: 697026 bytes.

SCFG statically links some libraries which help to make up the size of the executable (it's not all Synchronet source). So it could be the size of the [g]libc on the new OS or SDL (if it's statically linked, I forget). I don't think the size difference is actually an indicator of any problem.

digital man

Synchronet "Real Fact" #46:
The Synchronet Museum is online at http://wiki.synchro.net/history:museum: Norco, CA WX: 73.6øF, 54.0% humidity, 9 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Wed May 27 2015 10:02 am

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Mon May 25 2015 03:58 pm

There are other inteface/output modes SCFG supports as well. Experiment with the differnet "-i" options and find out what might be the problematic mode.

Got strange results on this...

Command Result
./scfg Crash system
./scfg -iD Works
./scfg -iC Works
./scfg -af Works
./scfg -aA Works but seems sluggish.

So would that be something in the auto detect if '-i' is not provided?

Does 'scfg -ix' work? That mode uses X11 which I believe is the auto-detected default when running under X.

digital man

Synchronet "Real Fact" #52:
Synchronet Blackjack was the first multi-node/multi-user game for Synchronet. Norco, CA WX: 73.6øF, 54.0% humidity, 9 mph ESE wind, 0.00 inches rain/24hrs

---
þ Synchronet þ Vertrauen þ Home of Synchronet þ telnet://vert.synchro.net

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Digital Man on Wed May 27 2015 10:02 am

There are other inteface/output modes SCFG supports as well. Experiment with the differnet "-i" options and find out what might be the problematic mode.

Got strange results on this...

Command Result
./scfg Crash system

My bet is that the system is not actually crashing, but that SDL is taking over
the console and failing to display anything.

Try a clean build specifying WITHOUT_SDL=1 on the make command-line to completely disable SDL support.

If this "fixes" the problem, look into how SDL is configured and built, since the problem lies there.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)

Re: Compile Issue (Raspberry Pi)
By: Digital Man to High Spirit on Wed May 27 2015 04:58 pm

Does 'scfg -ix' work? That mode uses X11 which I believe is the auto-detected default when running under X.

Yes... -ix works... all the switches work if I use them. Only have problems when I don't use the -i option. Weird eh?


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: Deuce to High Spirit on Wed May 27 2015 06:06 pm

My bet is that the system is not actually crashing, but that SDL is taking over the console and failing to display anything.

Try a clean build specifying WITHOUT_SDL=1 on the make command-line to completely disable SDL support.

If this "fixes" the problem, look into how SDL is configured and built, since the problem lies there.

It fixed the problem. Where do I go from here? :)

Thanks Deuce.


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: Deuce to High Spirit on Wed May 27 2015 06:06 pm

Just an update... I have a new Raspberry Pi 2 on the way and should be here tomorrow. Testing on it will be one of the first things I do. :)

Thanks to everyone for the help. Will keep you updated.


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: Deuce to High Spirit on Wed May 27 2015 06:06 pm

My bet is that the system is not actually crashing, but that SDL is taking over the console and failing to display anything.

Try a clean build specifying WITHOUT_SDL=1 on the make command-line to completely disable SDL support.

If this "fixes" the problem, look into how SDL is configured and built, since the problem lies there.

It has been a while since my last update on this problem. Received my Raspberry
Pi 2 and did some testing last week. Still have the same issue. I did the compile with the "WITHOUT_SDL=1" and everything works fine. I left it for a few
days and just returned it the problem today. I did a quick search on google for
SDL1.2 blank screen turned up a lot of people having this problem on the Raspberry Pi since February 2015. So it looks like there is a SDL issue with the latest OS on the Pi. Hope there is a fix soon.

In the mean time, is there any draw backs to compiling without SDL? My BBS runs
on a dedicated Pi with no display, audio or input devices.

Thank you to everyone who helped me figure this out.


-- High Spirit

---
þ Synchronet þ Digital Creation BBS -- bbs.digitalcreationbbs.com:2323

Re: Compile Issue (Raspberry Pi)
By: High Spirit to Deuce on Tue Jun 09 2015 03:23 pm

In the mean time, is there any draw backs to compiling without SDL? My BBS runs on a dedicated Pi with no display, audio or input devices.

If you're not going to use a local display, SDL is not useful.

---
http://DuckDuckGo.com/ a better search engine that respects your privacy.
Mro is an idiot. Please ignore him, we keep hoping he'll go away.
þ Synchronet þ My Brand-New BBS (All the cool SysOps run STOCK!)