4 Mar
2020
4 Mar
'20
6:01 p.m.
Wonder why I can't make(1) rogue on my 11/83, 2044KW, latest patch
release from sms.
[16] root--> make
cc -O -DUNIX -DUNIX_BSD4_2 -c curses.c
cc -O -DUNIX -DUNIX_BSD4_2 -c hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c init.c
cc -O -DUNIX -DUNIX_BSD4_2 -c inventory.c
cc -O -DUNIX -DUNIX_BSD4_2 -c level.c
cc -O -DUNIX -DUNIX_BSD4_2 -c machdep.c
cc -O -DUNIX -DUNIX_BSD4_2 -c main.c
cc -O -DUNIX -DUNIX_BSD4_2 -c message.c
cc -O -DUNIX -DUNIX_BSD4_2 -c monster.c
cc -O -DUNIX -DUNIX_BSD4_2 -c move.c
cc -O -DUNIX -DUNIX_BSD4_2 -c object.c
cc -O -DUNIX -DUNIX_BSD4_2 -c pack.c
cc -O -DUNIX -DUNIX_BSD4_2 -c play.c
cc -O -DUNIX -DUNIX_BSD4_2 -c random.c
cc -O -DUNIX -DUNIX_BSD4_2 -c ring.c
cc -O -DUNIX -DUNIX_BSD4_2 -c room.c
cc -O -DUNIX -DUNIX_BSD4_2 -c save.c
cc -O -DUNIX -DUNIX_BSD4_2 -c score.c
cc -O -DUNIX -DUNIX_BSD4_2 -c spec_hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c throw.c
cc -O -DUNIX -DUNIX_BSD4_2 -c trap.c
cc -O -DUNIX -DUNIX_BSD4_2 -c use.c
cc -O -DUNIX -DUNIX_BSD4_2 -c zap.c
cc -i curses.o hit.o init.o inventory.o
level.o machdep.o main.o message.o
monster.o move.o object.o pack.o
play.o random.o ring.o room.o save.o
score.o spec_hit.o throw.o
trap.o use.o zap.o -o rogue -lcurses -ltermlib
ld:/usr/lib/libcurses.a(refresh.o): text overflow
*** Exit 4
Stop.
[17] root-->
4 Mar
4 Mar
8:15 p.m.
On Wed, Mar 4, 2020 at 6:02 PM Jacob Ritorto via cctalk
<cctalk at classiccmp.org> wrote:
Wonder why I can't make(1) rogue on my 11/83, 2044KW, latest patch
release from sms.
The ld "text overflow" error is probably due to the the total size of
text (executable code) exceeding 64KB. The sum of the object files I
get without anything pulled in from the libraries is 62136 bytes.
I'm pretty sure I built this successfully in the past. I'll have to
try it again later with the generic installation before any patches
are applied, in case that makes a difference for some reason.
# pwd
/usr/src/games/rogue
# make
cc -O -DUNIX -DUNIX_BSD4_2 -c curses.c
cc -O -DUNIX -DUNIX_BSD4_2 -c hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c init.c
cc -O -DUNIX -DUNIX_BSD4_2 -c inventory.c
cc -O -DUNIX -DUNIX_BSD4_2 -c level.c
cc -O -DUNIX -DUNIX_BSD4_2 -c machdep.c
cc -O -DUNIX -DUNIX_BSD4_2 -c main.c
cc -O -DUNIX -DUNIX_BSD4_2 -c message.c
cc -O -DUNIX -DUNIX_BSD4_2 -c monster.c
cc -O -DUNIX -DUNIX_BSD4_2 -c move.c
cc -O -DUNIX -DUNIX_BSD4_2 -c object.c
cc -O -DUNIX -DUNIX_BSD4_2 -c pack.c
cc -O -DUNIX -DUNIX_BSD4_2 -c play.c
cc -O -DUNIX -DUNIX_BSD4_2 -c random.c
cc -O -DUNIX -DUNIX_BSD4_2 -c ring.c
cc -O -DUNIX -DUNIX_BSD4_2 -c room.c
cc -O -DUNIX -DUNIX_BSD4_2 -c save.c
cc -O -DUNIX -DUNIX_BSD4_2 -c score.c
cc -O -DUNIX -DUNIX_BSD4_2 -c spec_hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c throw.c
cc -O -DUNIX -DUNIX_BSD4_2 -c trap.c
cc -O -DUNIX -DUNIX_BSD4_2 -c use.c
cc -O -DUNIX -DUNIX_BSD4_2 -c zap.c
cc -i curses.o hit.o init.o inventory.o level.o
machdep.o main.o message.o monster.o move.o
object.o pack.o play.o random.o ring.o
room.o save.o score.o spec_hit.o throw.o
trap.o use.o zap.o -o rogue -lcurses -ltermlib
ld:/usr/lib/libcurses.a(refresh.o): text overflow
*** Exit 4
Stop.
# size *.o
text data bss dec hex
0 38 0 38 26 curses.o
2322 264 0 2586 a1a hit.o
1620 304 0 1924 784 init.o
4212 2760 0 6972 1b3c inventory.o
6790 410 0 7200 1c20 level.o
1060 116 12 1188 4a4 machdep.o
82 36 0 118 76 main.o
2688 548 0 3236 ca4 message.o
5234 1856 0 7090 1bb2 monster.o
3408 294 4 3706 e7a move.o
4042 3642 0 7684 1e04 object.o
2760 568 0 3328 d00 pack.o
682 370 0 1052 41c play.o
474 180 0 654 28e random.o
1320 382 0 1702 6a6 ring.o
4322 402 0 4724 1274 room.o
2966 346 0 3312 cf0 save.o
4850 1222 8 6080 17c0 score.o
3162 242 0 3404 d4c spec_hit.o
2094 164 4 2262 8d6 throw.o
1726 394 2 2122 84a trap.o
3452 1500 0 4952 1358 use.o
2870 358 2 3230 c9e zap.o
>> 2322 + 1620 + 4212 + 6790 + 1060 + 82 + 2688 +
5234 + 3408 + 4042 + 2760 + 682 + 474 + 1320 + 4322 + 2966 + 4850 + 3162 + 2094 + 1726 +
3452 + 2870
62136
5 Mar
5 Mar
3:33 p.m.
I'm pretty sure I built this successfully in the past. I'll have to
try it again later with the generic installation before any patches
are applied, in case that makes a difference for some reason.
I took another look to refresh my memory. I assume now that I never
successfully built rogue on 2.11BSD in the past, and what I actually
did was just run the already built hack binary.
If you look at the hack binary it is built with 5 text overlays in
addition to the base text:
# pwd
/usr/games
# ls -l hack
-rws--x--x 1 daemon 195175 Nov 26 1999 hack
# size hack
text data bss dec hex
37952 32424 12450 82826 1438a total text: 148608
overlays: 24512,24192,22528,18688,20736
If you look at the Makefile for hack it defines the BASE object files
and the OV1 - OV5 overlay objects files, then uses the ld -Z switch to
link the executable with the BASE object files plus the 5 overlay
object files OV1 - OV5.
If the total text size for rogue is slightly beyond 64KB after pulling
in object files from the libraries then the Makefile for rogue needs
to be modified to move some of the object files into overlays somewhat
similar to the way it is done for hack, for example.
# Hack overlay structure (PDP-11/{44,45,70})
#
# The BASE (should) occupy 5 segments, but extreme care has to be taken when
# any code is changed as those five segments have been filled to within bytes
# of that limit. Each of the overlays occupies 3 segments with similar
# restrictions on changing code (most have been filled to within a few hundred
# bytes). The wise and cautious programmer would be well advised to use
# size(1) heavily ...
#
BASE = strings.o hack.monst.o hack.Decl.o\
hack.invent.o hack.dog.o hack.mon.o\
hack.engrave.o rnd.o hack.track.o
OV1 = hack.shk.o hack.topl.o hack.o hack.end.o hack.trap.o
OV2 = hack.do_wear.o hack.main.o hack.eat.o hack.timeout.o hack.vault.o\
hack.wizard.o hack.topl.o hack.tty.o\
hack.do.o hack.search.o alloc.o\
hack.cmd.o hack.termcap.o hack.unix.o hack.ioctl.o
OV3 = hack.do_name.o hack.fight.o hack.mkobj.o hack.o_init.o hack.mhitu.o\
hack.makemon.o hack.worn.o hack.rumors.o hack.objnam.o hack.pri.o
OV4 = hack.zap.o hack.read.o hack.apply.o hack.potion.o\
hack.options.o hack.pager.o hack.wield.o
OV5 = hack.save.o hack.lev.o hack.mklev.o hack.mkshop.o hack.mkmaze.o\
hack.shknam.o hack.u_init.o\
hack.rip.o hack.bones.o hack.worm.o hack.steal.o hack.version.o
# Crypt *MUST be listed BEFORE $(HOBJ)
$(GAME): crypt $(HOBJ)
@echo "Loading ..."
@ld -i -X -x -o $(GAME) /lib/crt0.o $(BASE)\
-Z $(OV1) -Z $(OV2) -Z $(OV3) -Z $(OV4) -Z $(OV5) -Y\
$(TERMLIB) -lc
@echo "Load complete"
9:09 a.m.
I don't have knowledge of the system - just a programmer.
But could it be the difference of static vz dynamic libraries?
pulling in libnnn.a instead of libnnn.so /.sl / ?? runtime library?
That would make the text larger, if static linking.
Keven Miller
----- Original Message -----
From: "Jacob Ritorto via cctech" <cctech at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Wed 04 Mar 2020 06:01 PM
Subject: 2.11bsd rogue can't build
Wonder why I can't make(1) rogue on my 11/83,
2044KW, latest patch
release from sms.
[16] root--> make
cc -O -DUNIX -DUNIX_BSD4_2 -c curses.c
cc -O -DUNIX -DUNIX_BSD4_2 -c hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c init.c
cc -O -DUNIX -DUNIX_BSD4_2 -c inventory.c
cc -O -DUNIX -DUNIX_BSD4_2 -c level.c
cc -O -DUNIX -DUNIX_BSD4_2 -c machdep.c
cc -O -DUNIX -DUNIX_BSD4_2 -c main.c
cc -O -DUNIX -DUNIX_BSD4_2 -c message.c
cc -O -DUNIX -DUNIX_BSD4_2 -c monster.c
cc -O -DUNIX -DUNIX_BSD4_2 -c move.c
cc -O -DUNIX -DUNIX_BSD4_2 -c object.c
cc -O -DUNIX -DUNIX_BSD4_2 -c pack.c
cc -O -DUNIX -DUNIX_BSD4_2 -c play.c
cc -O -DUNIX -DUNIX_BSD4_2 -c random.c
cc -O -DUNIX -DUNIX_BSD4_2 -c ring.c
cc -O -DUNIX -DUNIX_BSD4_2 -c room.c
cc -O -DUNIX -DUNIX_BSD4_2 -c save.c
cc -O -DUNIX -DUNIX_BSD4_2 -c score.c
cc -O -DUNIX -DUNIX_BSD4_2 -c spec_hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c throw.c
cc -O -DUNIX -DUNIX_BSD4_2 -c trap.c
cc -O -DUNIX -DUNIX_BSD4_2 -c use.c
cc -O -DUNIX -DUNIX_BSD4_2 -c zap.c
cc -i curses.o hit.o init.o inventory.o
level.o machdep.o main.o message.o
monster.o move.o object.o pack.o
play.o random.o ring.o room.o save.o
score.o spec_hit.o throw.o
trap.o use.o zap.o -o rogue -lcurses -ltermlib
ld:/usr/lib/libcurses.a(refresh.o): text overflow
*** Exit 4
Stop.
[17] root-->
11:06 p.m.
On Thu, Mar 5, 2020, 11:15 PM Keven Miller(3k) via cctalk <
cctalk at classiccmp.org> wrote:
I don't have knowledge of the system - just a
programmer.
But could it be the difference of static vz dynamic libraries?
2.11 and all pdp-11 unix have no shared libraries. The hardware makes this
super hard to dom
pulling in libnnn.a instead of libnnn.so /.sl / ?? runtime library?
That would make the text larger, if static linking.
No. It's almost certainly the overlay structure is overflowing and needs to
be redone.
Warner
Keven Miller
----- Original Message -----
From: "Jacob Ritorto via cctech" <cctech at classiccmp.org>
To: "General Discussion: On-Topic and Off-Topic Posts"
<cctalk at classiccmp.org>
Sent: Wed 04 Mar 2020 06:01 PM
Subject: 2.11bsd rogue can't build
Wonder why I can't make(1) rogue on my 11/83,
2044KW, latest patch
release from sms.
[16] root--> make
cc -O -DUNIX -DUNIX_BSD4_2 -c curses.c
cc -O -DUNIX -DUNIX_BSD4_2 -c hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c init.c
cc -O -DUNIX -DUNIX_BSD4_2 -c inventory.c
cc -O -DUNIX -DUNIX_BSD4_2 -c level.c
cc -O -DUNIX -DUNIX_BSD4_2 -c machdep.c
cc -O -DUNIX -DUNIX_BSD4_2 -c main.c
cc -O -DUNIX -DUNIX_BSD4_2 -c message.c
cc -O -DUNIX -DUNIX_BSD4_2 -c monster.c
cc -O -DUNIX -DUNIX_BSD4_2 -c move.c
cc -O -DUNIX -DUNIX_BSD4_2 -c object.c
cc -O -DUNIX -DUNIX_BSD4_2 -c pack.c
cc -O -DUNIX -DUNIX_BSD4_2 -c play.c
cc -O -DUNIX -DUNIX_BSD4_2 -c random.c
cc -O -DUNIX -DUNIX_BSD4_2 -c ring.c
cc -O -DUNIX -DUNIX_BSD4_2 -c room.c
cc -O -DUNIX -DUNIX_BSD4_2 -c save.c
cc -O -DUNIX -DUNIX_BSD4_2 -c score.c
cc -O -DUNIX -DUNIX_BSD4_2 -c spec_hit.c
cc -O -DUNIX -DUNIX_BSD4_2 -c throw.c
cc -O -DUNIX -DUNIX_BSD4_2 -c trap.c
cc -O -DUNIX -DUNIX_BSD4_2 -c use.c
cc -O -DUNIX -DUNIX_BSD4_2 -c zap.c
cc -i curses.o hit.o init.o inventory.o
level.o machdep.o main.o message.o
monster.o move.o object.o pack.o
play.o random.o ring.o room.o save.o
score.o spec_hit.o throw.o
trap.o use.o zap.o -o rogue -lcurses -ltermlib
ld:/usr/lib/libcurses.a(refresh.o): text overflow
*** Exit 4
Stop.
[17] root-->
11:39 p.m.
On 3/6/2020 12:06 AM, Warner Losh via cctalk wrote:
On Thu, Mar 5, 2020, 11:15 PM Keven Miller(3k) via
cctalk <
cctalk at classiccmp.org> wrote:
Can curses be stripped down just for the terminals used?
I don't have knowledge of the system - just a
programmer.
But could it be the difference of static vz dynamic libraries?
2.11 and all pdp-11 unix have no shared libraries. The hardware makes this
super hard to dom
pulling in libnnn.a instead of libnnn.so /.sl / ?? runtime library?
That would make the text larger, if static
linking.
No. It's almost certainly the overlay structure is overflowing and needs to
be redone.
Warner
Keven Miller
6 Mar
6 Mar
12:03 a.m.
On Fri, Mar 6, 2020, 12:39 AM ben via cctalk <cctalk at classiccmp.org> wrote:
On 3/6/2020 12:06 AM, Warner Losh via cctalk wrote:
Curses is table driven from a file, so no. It already is small. There may
be a little bit of excess to trim, but it won't be a big win.
Warner
On Thu, Mar 5, 2020, 11:15 PM Keven Miller(3k)
via cctalk <
cctalk at classiccmp.org> wrote:
this
I don't have knowledge of the system - just a
programmer.
But could it be the difference of static vz dynamic libraries?
2.11 and all pdp-11 unix have no shared libraries. The hardware makes super hard to dom
pulling in libnnn.a instead of libnnn.so /.sl / ?? runtime library?
to
That would make the text larger, if static
linking.
No. It's almost certainly the overlay structure is overflowing and needs be redone.
Warner
Keven Miller
Can curses be stripped down just for the terminals used?
9:24 p.m.
Thanks for the leads, everyone!
I made a little progress: I did read enough about ld to get it to load
the .o files from the initial cc run into a separate I&d overlaid
executable. But when I execute it, it gives me Segmentation fault
(core dumped).. There was one complaint of Undefined during the ld run
even though I said -lc_p (and validated that _environ is in that .a
file using nm.
Undefined:
_environ
but it seemed to succeed in building the executable despite that.
Well, I'm guessing it succeeded because the output file rogue is
sitting there afterwards and has been marked executable, which,
according to the man page, ld doesn't mark that way unless it
succeeds.
[35] root--> ld -t -v -M -i -X -x init.o main.o level.o score.o
machdep.o inventory.o -Z hit.o monster.o -Z message.o move.o -Z
object.o pack.o play.o -Z curses.o random.o ring.o -Z room.o -Z save.o
spec_hit.o -Z throw.o trap.o -Z use.o zap.o -Y -o rogue -lcurses
-ltermlib -lc_p
[36] root--> size rogue
text data bss dec hex
44928 18554 10520 74002 12112 total text: 88704
overlays: 7616,6144,7488,1856,4352,6144,3840,6336
[37] root--> ./rogue
Segmentation fault (core dumped)
See anything amiss in my process? That Undefined _environ during ld
still bugs me.
Is the next step dissecting the program or its core with adb to find
what's wrong?
thx
jake
7 Mar
7 Mar
7 a.m.
On Fri, Mar 6, 2020 at 10:25 PM Jacob Ritorto via cctalk <
cctalk at classiccmp.org> wrote:
Thanks for the leads, everyone!
I made a little progress: I did read enough about ld to get it to load
the .o files from the initial cc run into a separate I&d overlaid
executable. But when I execute it, it gives me Segmentation fault
(core dumped).. There was one complaint of Undefined during the ld run
even though I said -lc_p (and validated that _environ is in that .a
file using nm.
Undefined:
_environ
but it seemed to succeed in building the executable despite that.
Well, I'm guessing it succeeded because the output file rogue is
sitting there afterwards and has been marked executable, which,
according to the man page, ld doesn't mark that way unless it
succeeds.
[35] root--> ld -t -v -M -i -X -x init.o main.o level.o score.o
machdep.o inventory.o -Z hit.o monster.o -Z message.o move.o -Z
object.o pack.o play.o -Z curses.o random.o ring.o -Z room.o -Z save.o
spec_hit.o -Z throw.o trap.o -Z use.o zap.o -Y -o rogue -lcurses
-ltermlib -lc_p
[36] root--> size rogue
text data bss dec hex
44928 18554 10520 74002 12112 total text: 88704
overlays: 7616,6144,7488,1856,4352,6144,3840,6336
[37] root--> ./rogue
Segmentation fault (core dumped)
See anything amiss in my process? That Undefined _environ during ld
still bugs me.
Is the next step dissecting the program or its core with adb to find
what's wrong?
You should check to see if crt saves the third argument to start/main.
That's what environ is. But you'll need to look at the code.
src/lib/libc/gen/getenv expects environ to be a global variable:
extern char **environ;
and if getenv is called, that may be where that comes from. It's defined in
pdp/csu/crt0.s:_environ: .=.+2 / others
where it also looks to be set. Is crt0.o not getting pulled in for some
reason?
Warner
5 Mar
5 Mar
2:10 p.m.
On 3/4/20 8:01 PM, Jacob Ritorto via cctech wrote:
Wonder why I can't make(1) rogue on my 11/83,
2044KW, latest patch
release from sms.
[16] root--> make
....
ld:/usr/lib/libcurses.a(refresh.o): text overflow
*** Exit 4
Stop.
[17] root-->
I'm going on 15-years-ago recollection here, but if that's the
problem I think it is, it can be fixed by reallocating driver
distribution in the overlays.
I tried to build 2.11 with ethernet support and piled all the extra
includes into one overlay. A more even distribution across overlays
fixed it.
Doc
1519
days inactive
1521
days old
9 comments
6 participants
participants (6)
-
bfranchuk＠jetnet.ab.ca -
doc＠vaxen.net -
glen.slick＠gmail.com -
imp＠bsdimp.com -
jacob.ritorto＠gmail.com -
kevenm＠3kranger.com