lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/18/90)
A couple of problems have been noted at patchlevel 36 so far. First, the selection of -lm has been moved from the Makefile into Configure. Unfortunately, if you already have a config.sh out there, it selects the libraries you specified previously, which doesn't include -lm. The result is undefined symbols like pow(), etc. Add -lm by hand at the libraries prompt of Configure, or delete config.sh before running Configure. Or edit config.sh at the end and add -lm to $libs. The other problem is on machines that only support old dbm, there is a reference to a new dbm function call at line 405 in hash.c. As a workaround, you can throw in a #define dbm_nextkey(d, k) nextkey(k) into perl.h where the other dbm defines are. If this is all that goes wrong, I'll be a happy man. Larry
don@eecs.umich.edu (Don Winsor) (10/18/90)
One more little gremlin in patchlevel 36; there is an RCS entry at the top of lib/syslog.pl that isn't commented out: # # syslog.pl # # $Log: syslog.pl,v $ Revision 3.0.1.3 90/10/15 17:42:18 lwall patch29: various portability fixes # Revision 3.0.1.1 90/08/09 03:57:17 lwall # patch19: Initial revision The fix is obvious; comment out the two offending lines Don Winsor don@eecs.umich.edu Electrical Engineering and Computer Science University of Michigan, Ann Arbor
tkacik@rphroy.uucp (Tom Tkacik) (10/19/90)
In article <10009@jpl-devvax.JPL.NASA.GOV>, lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) writes: |> The other problem is on machines that only support old dbm, there is a |> reference to a new dbm function call at line 405 in hash.c. As a |> workaround, you can throw in a |> |> #define dbm_nextkey(d, k) nextkey(k) |> |> into perl.h where the other dbm defines are. |> |> If this is all that goes wrong, I'll be a happy man. I am trying to compile perl3 p36 on an Apollo. The Apollo does have ndbm, so the above is not a problem, dbm_nextkey if defined. It thinks it has an ANSI C compiler, it doesn't really, but it does have prototypes for many, (if not all library functions). In particular, it has one for dbm_nextkey(), datum dbm_nextkey(DBM *db); Hash.c fails to compile because of the wrong number of arguments. Wondering if the Apollo has it wrong, I also looked at the manuals for SUN and SGI machines, and they also show the same thing, (dbm_nextkey takes a single argument). I can get it to compile be adding a -U__STDC__ option to CFLAGS, (never a bad thing to do on the Apollo), but this really otta' be fixed. -- Tom Tkacik ...uunet!edsews!rphroy!tkacik GM Research Labs tkacik@kyzyl.mi.org "I'm president of the United States, and I'm not going to eat anymore broccoli." --- George Bush
lwall@jpl-devvax.JPL.NASA.GOV (Larry Wall) (10/20/90)
In article <35805@rphroy.UUCP> tkacik@rphroy.uucp (Tom Tkacik) writes:
: Hash.c fails to compile because of the wrong number of arguments.
: Wondering if the Apollo has it wrong, I also looked at the manuals for
: SUN and SGI machines, and they also show the same thing,
: (dbm_nextkey takes a single argument).
:
: I can get it to compile be adding a -U__STDC__ option to CFLAGS,
: (never a bad thing to do on the Apollo), but this really otta' be fixed.
There's actually a difference of opinion about it, unfortunately. After
the next patch, the code will read:
#ifdef NDBM
#ifdef _CX_UX
nextdkey = dbm_nextkey(tb->tbl_dbm, dkey);
#else
nextdkey = dbm_nextkey(tb->tbl_dbm);
#endif
#else
nextdkey = nextkey(dkey);
#endif
Larry