as of 2017-08-16 13:11:01 we can't connect to cvs or vert :(
as of 2017-08-16 13:11:01 we can't connect to cvs or vert :(
We had about a 2 hour ISP outage today. Now fixed.
oh! before i forget, the dance described above also brought out that the scfghelp.dat and scfghelp.ibx files are still required in the build... when trying to get the symlinks recreated or the binaries copied over, the make process kept failing on those two files until we went to the cvs and pulled the
two 15 year old ones from there and manually copied them into the gcc.linux.x64.exe.debug directory... we'll have to remember to copy them to the
gss.linux.x86.exe.release directory, too, when we decide to go back to release builds... just thought we'd let you know about that so the make files could be updated...
now that we refreshed everything from the repo, we also had to adjust the scripts in xtrn/dpoker, xtrn/sbj, xtrn/sbl, and xtrn/tbd... on our systems sh is pointing to dash... the first problem was no double quotes around "$machine"
in the last test... then there was the uname stuff piped thru "egrep -v"... there wasn't any output even though these systems are x86_64... we had to remove the "-v" parms from the egrep lines and then the scripts started working
properly...
FWIW: here's a diff of the scripts... since they're all identical, this should apply to all of them... we invalidated the first line's three dashes so the mail system would not think it was a tear line...
----->8 snip 8<-----
-!- /sbbs/xtrn/sbl/sbl,old 2017-08-16 17:49:38.000000000 -0400
+++ /sbbs/xtrn/sbl/sbl.new 2017-08-17 00:38:13.000000000 -0400
@@ -1,14 +1,14 @@
#!/bin/sh
os=`uname | tr "[A-Z]" "[a-z]"`
-if uname -m | egrep -v "(i[3456789]*|x)86" > /dev/null
+if uname -m | egrep "(i[3456789]*|x)86" > /dev/null
then
machine=`uname -m | tr "[A-Z]" "[a-z]" | tr " " "_"`
fi
-if uname -m | egrep -v "64" > /dev/null
+if uname -m | egrep "64" > /dev/null
then
machine=`uname -m | tr "[A-Z]" "[a-z]" | tr " " "_"`
fi
-if [ $machine = "x86_64" ]
+if [ "$machine" = "x86_64" ]
then
machine=x64
fi
----->8 snip 8<-----
as of 2017-08-16 13:11:01 we can't connect to cvs or vert :(
We had about a 2 hour ISP outage today. Now fixed.
someoh! before i forget, the dance described above also brought out that the
scfghelp.dat and scfghelp.ibx files are still required in the build...
when trying to get the symlinks recreated or the binaries copied over,
the make process kept failing on those two files until we went to the
cvs and pulled the two 15 year old ones from there and manually copied
them into the gcc.linux.x64.exe.debug directory... we'll have to
remember to copy them to the gss.linux.x86.exe.release directory, too,
when we decide to go back to release builds... just thought we'd let
you know about that so the make files could be updated...
I could find no lasting references to scfghelp.*. Perhaps you just had
old dependency (*.d) files. Runnnig 'make clean' should clear that up.
now that we refreshed everything from the repo, we also had to adjust
the scripts in xtrn/dpoker, xtrn/sbj, xtrn/sbl, and xtrn/tbd... on our
Deuce made the most recent changes to those scripts. I'm not sure why the use of '-v' (Invert the sense of matching), but that seems like a
pretty significant change. The quotes around $machine, probably not.
On 2017 Aug 17 13:00:44, you wrote to me:
oh! before i forget, the dance described above also brought out that the
scfghelp.dat and scfghelp.ibx files are still required in the build...
when trying to get the symlinks recreated or the binaries copied over,
the make process kept failing on those two files until we went to the
cvs and pulled the two 15 year old ones from there and manually copied
them into the gcc.linux.x64.exe.debug directory... we'll have to
remember to copy them to the gss.linux.x86.exe.release directory, too,
when we decide to go back to release builds... just thought we'd let
you know about that so the make files could be updated...
I could find no lasting references to scfghelp.*. Perhaps you just hadsome
old dependency (*.d) files. Runnnig 'make clean' should clear that up.
where would that be executed from?
we've been cleaning our script and adding
the new things that have appeared on the wiki... now our script automatically cleans
$SBBSDIR/src/comio
$SBBSDIR/src/conio
$SBBSDIR/src/smblib
$SBBSDIR/src/uifc
$SBBSDIR/src/xpdev
$SBBSDIR/src/sbbs3
$SBBSDIR/src/sbbs3/scfg
$SBBSDIR/exec
by stepping into each and executing
gmake $BUILDOPTS clean
where BUILDOPTS is our current options of
DEBUG=1 USEDOSEMU=1 INSTALL=CLASSIC SBBSDIR=/sbbs SBBSUSER=sbbs SBBSGROUP=sbbs
we use these BUILDOPTS everywhere to try to ensure that everything is built with the same settings...
our current workflow is:
1. save exec and ctrl
2. update from CVS
3. apply our patches
4. clean
5. compile
are we missing anything?
FWIW, we don't understand the makefile build stuff but we found these... perhaps the targets.mk file is at fault? where is $SCFGHELP defined?
/sbbs/src $ egrep -ir "scfghelp*" *
sbbs2/scfg/makehelp.c:if((out=fopen("SCFGHELP.DAT","wb"))==NULL) {
Binary file sbbs2/scfg/makehelp.exe matches
sbbs3/scfg/makehelp.vcxproj: <Outputs>$(OutDir)scfghelp.dat;$(OutDir)scfghelp.ixb;%(Outputs)</Outputs> sbbs3/scfg/makehelp.vcxproj: <Outputs>$(OutDir)scfghelp.dat;$(OutDir)scfghelp.ixb;%(Outputs)</Outputs> sbbs3/scfg/makehelp.dsp:"$(OutDir)\scfghelp.dat" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
sbbs3/scfg/makehelp.dsp:"$(OutDir)\scfghelp.ixb" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
sbbs3/scfg/makehelp.dsp:"$(OutDir)\scfghelp.dat" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
sbbs3/scfg/makehelp.dsp:"$(OutDir)\scfghelp.ixb" : $(SOURCE) "$(INTDIR)" "$(OUTDIR)"
sbbs3/scfg/makehelp.c: sprintf(str,"%s/scfghelp.dat",dir); sbbs3/scfg/makehelp.c: sprintf(str,"%s/scfghelp.ixb",dir);
sbbs3/scfg/targets.mk: $(SCFG) $(SCFGHELP) sbbs3/install.iwz:Group1File55=C:\SBBS\EXEC\Scfghelp.dat sbbs3/install.iwz:Group1File56=C:\SBBS\EXEC\Scfghelp.ixb
all we know is we had to make those two files available and the script completed...
we also checked in scfg and the help F1 does work but we've not
tried it without those two files...
now that we refreshed everything from the repo, we also had to adjust
the scripts in xtrn/dpoker, xtrn/sbj, xtrn/sbl, and xtrn/tbd... on our
[trim]
Deuce made the most recent changes to those scripts. I'm not sure why the use of '-v' (Invert the sense of matching), but that seems like a pretty significant change. The quotes around $machine, probably not.
as noted previously, on our ubuntu based systems sh is symlinked to dash... apparently dash is extremely POSIX... it definitely whined about the missing quotes around "$machine" in that one test... after we fixed that, we found the other problems by manually running each line and looking for the results... there was nothing output at all for any of them until we removed the "-v"... when we finally got things working, we knew it was right when the scripts lead to "SBBSNODE is not set" or something to that effect... since we were running the script, sbl in this case, manually from the command line, this was a good thing :)
I could find no lasting references to scfghelp.*. Perhaps you just
had some old dependency (*.d) files. Runnnig 'make clean' should
clear that up.
where would that be executed from?
From src/sbbs3/scfg
our current workflow is:
1. save exec and ctrl
2. update from CVS
3. apply our patches
4. clean
5. compile
are we missing anything?
Not that I can think of.
FWIW, we don't understand the makefile build stuff but we found
these... perhaps the targets.mk file is at fault? where is $SCFGHELP
defined?
It's not, so it'd just be a blank string and do nothing. I've since removed it anyway.
/sbbs/src $ egrep -ir "scfghelp*" *
sbbs2/scfg/makehelp.c:if((out=fopen("SCFGHELP.DAT","wb"))==NULL) {
Binary file sbbs2/scfg/makehelp.exe matches
You're not running sbbs2, so that's not relevant.
sbbs3/install.iwz:Group1File55=C:\SBBS\EXEC\Scfghelp.dat
sbbs3/install.iwz:Group1File56=C:\SBBS\EXEC\Scfghelp.ixb
Just legacy files, unused.
all we know is we had to make those two files available and the script
completed...
And my builds work just fine without those files as do the nightlies which are built in a sandbox.
as noted previously, on our ubuntu based systems sh is symlinked to
dash... apparently dash is extremely POSIX... it definitely whined
about the missing quotes around "$machine" in that one test... after we
fixed that, we found the other problems by manually running each line
and looking for the results... there was nothing output at all for any
of them until we removed the "-v"... when we finally got things
working, we knew it was right when the scripts lead to "SBBSNODE is
not set" or something to that effect... since we were running the
script, sbl in this case, manually from the command line, this was a
good thing :)
My Debian system is the same. I don't normally use those scripts (I
use symlinks), but I tested and reproduced the same failure you
reported.
And my builds work just fine without those files as do the nightlies
which are built in a sandbox.
it may have been the install stuff where it came up... remember, we were trying to get the symlinks rebuilt or have the files copied to the exec directory...
all we know is we had to make those two files available and the script
completed...
And my builds work just fine without those files as do the nightlies which are built in a sandbox.
it may have been the install stuff where it came up... remember, we were trying
to get the symlinks rebuilt or have the files copied to the exec directory... building after cvs updates doesn't do that... at elast not that we've seen... only the install does that but the only install we've found is the one in the "quick install from CVS" where the makefile stuff actually starts an update and
build run... we did find the "nocvs" option to take care of that, though...
we did an update and build with our script, now that we've switched to copying the binaries instead of symlinks... the new binaries are built but they're not copied to exec by the makefiles... we're not sure what the best solution would be... symlinks are good for this except when you change between release and debug modes because the links are not updated to point to the freshly built binaries... that's why we switched to the copy option... things that make ya go
"hummmmm" ;)
it may have been the install stuff where it came up... remember, we
were trying to get the symlinks rebuilt or have the files copied to the
exec directory... building after cvs updates doesn't do that... at
elast not that we've seen... only the install does that but the only
install we've found is the one in the "quick install from CVS" where
the makefile stuff actually starts an update and build run... we did
find the "nocvs" option to take care of that, though...
Referring to this: http://wiki.synchro.net/install:nix#non-cvs ?
we did an update and build with our script, now that we've switched to
copying the binaries instead of symlinks... the new binaries are built
but they're not copied to exec by the makefiles... we're not sure what
the best solution would be... symlinks are good for this except when
you change between release and debug modes because the links are not
updated to point to the freshly built binaries... that's why we
switched to the copy option... things that make ya go "hummmmm" ;)
When you say "the makefiles", I assume you're referring to src/sbbs3/GNUmakefile (and scfg/GNUmakefile). The makefile in the
install directory does perform the copy or symlink of the output files
to the Synchronet "exec" directory. The src/*/GNUmakefiles do not know where your Synchronet exec directory is located, so they're not going
to mess with it.
Another option is to just not use the Synchronet exec directory for
your native executable binaries. This would require updating anything/anywhere that executes exec/sbbs, exec/sbbsecho, etc. and changing to use either the full path to the build output directory or (preferably) a short symlink that you could then change to point to
either *.exe.release or *.exe.debug output directories. You'd also
need to update your LD_LIBRARY_PATH environment variable to point to either the *.lib.debug or *.lib.release directories. The symlink or
copy method is simpler, but I use all of these methods myself at
different times and under different testing conditions.
| Sysop: | Winzlo |
|---|---|
| Location: | Minnesota, USA |
| Users: | 11 |
| Nodes: | 16 (0 / 16) |
| Uptime: | 495941:13:13 |
| Calls: | 82 |
| Files: | 1,070 |
| D/L today: |
27 files (11,920K bytes) |
| Messages: | 286,980 |