burdick@hpindda.HP.COM (Matt Burdick) (11/15/89)
Here are a few compilation problems I noticed while running 'make
dependInstall' on my HP9000/350 under HPUX 6.5:
Compilation Problems for Andrew - patchlevel 6
1) While compiling atk/eq/parse.c, it fails with the following message:
parse.y: 34: Can't find include file eq.ih
The eq.ih file is produced by running class on atk/eq/eq.ih file and should
happen before parse.c is compiled. Since I am not familiar with imake, I'm
not sure of what should be changed in the Imakefile, but I'm sure it's
minor.
2) A number of errors of the following format:
strip: file /sam/andrew/build_dir/config/loginstall.hpindlw format error, improper system id 0x2321
strip: file /sam/andrew/build_dir/bin/genmake.hpindlw format error, improper system id 0x2321
3) The following message appears when compiling overhead/mail/lib/dropoff.c:
"dropoff.c", line 633: warning: incorrect combination of pointer and integer, op =
This is the line it is complaining about:
fp = qopen(oldsendmail, SMVec, "w");
Here is the relevant declaration in dropoff.c:
FILE *fp;
... in util.h (included by dropoff.c):
extern FILE *qopen(); /* topen() with simplified calling
* sequence */
... and in fdplumb.h (also included by dropoff.h):
#define qopen dbg_qopen
Because of the #define in fdplumb.h, the line in dropoff.c that opens the
file with qopen is really calling dbg_qopen, which returns an int by
default. At least I assume dbg_qopen returns an int, since I haven't found
any code for it yet.
4) In atk/zip/lib/zipve02.c, in the function Create_Shade_Palette, there
are a number of lines in the declaration of the 'source' array that begin
with the '#' character, causing some problems for makedepend:
Adding dependencies...
zipve02.c, line 653: unknown directive == "#White\n\"
zipve02.c, line 691: unknown directive == "#Black\n\"
zipve02.c, line 694: unknown directive == "#*G;1100,100\n\"
... etc
This is a pretty minor problem, I know.
5) In helpindex/Makefile, the help.aliases file is installed using the
$(INSTINCFLAGS) flags, which are mode 444. This means that when it comes
time to run 'make Aliases', addalias will be unable to append to that file.
Instead, the $(INSTLIBFLAGS) flag should be used, since this is 0664.
-matt
--
Matt Burdick | Hewlett-Packard
burdick%hpda@hplabs.hp.com | Technical Communications Lab (IND/TCL)ghoti+@ANDREW.CMU.EDU (Adam Stoller) (11/15/89)
Excerpts from internet.info-andrew: 14-Nov-89 Some compilation problems Matt Burdick@ucbvax.Berk (2439) > 1) While compiling atk/eq/parse.c, it fails with the following message: > parse.y: 34: Can't find include file eq.ih We're working on this one - it's similar [though *not* the same] to a circular dependency - basically there are dependencies on generated include files - and we're working on making sure they're done in the correct order. Excerpts from internet.info-andrew: 14-Nov-89 Some compilation problems Matt Burdick@ucbvax.Berk (2439) > 2) A number of errors of the following format: > strip: file /sam/andrew/build_dir/config/loginstall.hpindlw format > error, improper system id 0x2321 > strip: file /sam/andrew/build_dir/bin/genmake.hpindlw format error, > improper system id 0x2321 I take it that these are errors from the 'install' program/script you are using - the files you mention above are actually c-shell scripts. You might try defining BUILDANDREWINSTALL_ENV which will build a program called 'install' which we use locally. Excerpts from internet.info-andrew: 14-Nov-89 Some compilation problems Matt Burdick@ucbvax.Berk (2439) > Adding dependencies... > zipve02.c, line 653: unknown directive == "#White\n\" > zipve02.c, line 691: unknown directive == "#Black\n\" > zipve02.c, line 694: unknown directive == "#*G;1100,100\n\" > ... etc This is an unfortuante cosmetic problem - the 'makedepend' program is parsing a string constant in the .c file - and the string constant includes these '#<string>'s in it. -- you should be able to safely ignore it. Excerpts from internet.info-andrew: 14-Nov-89 Some compilation problems Matt Burdick@ucbvax.Berk (2439) > 5) In helpindex/Makefile, the help.aliases file is installed using the > $(INSTINCFLAGS) flags, which are mode 444. This means that when it comes > time to run 'make Aliases', addalias will be unable to append to that file. > Instead, the $(INSTLIBFLAGS) flag should be used, since this is 0664. Good point, I'm surprised nobody caught this before - consider it done (though it's possible you won't see the change until the actual release, if it doesn't make it into our last pre-release patch) Thanks for the input. --fish
burdick@hpindda.HP.COM (Matt Burdick) (11/16/89)
>> 2) A number of errors of the following format: >> >> strip: file /sam/andrew/build_dir/bin/genmake.hpindlw format error, >> improper system id 0x2321 > I take it that these are errors from the 'install' program/script you are > using - the files you mention above are actually c-shell scripts. > > You might try defining BUILDANDREWINSTALL_ENV which will build a program > called 'install' which we use locally. After a bit of poking around, I found out that the problem is caused by the Andrew install program. Apparently, if it is used on an executable and there is no file extension (ie: no period in the filename), it is stripped before installing. Since some scripts fall into this catagory, a 'strip' is attempted on them before installation. Here are the scripts I could find without periods in the filename: atk/text/ezpostprocess atk/text/indexpro atkams/messages/cmd/binopts ams/demo/gendemo ams/demo/amsdemo config/linkinst config/loginstall overhead/genmake/mkgenmk overhead/genmake/genmake As far as I know, this doesn't cause any problems except a few harmless error messages during compilation. To fix it, however, would only entail changing the names of the scripts. This feature of the install program explains why I haven't gotten a nonstripped version of runapp compiled yet, though. BTW, what is the normal way you CMU people debug binaries that are dynamically loaded? -matt -- Matt Burdick | Hewlett-Packard burdick%hpda@hplabs.hp.com | Technical Communications Lab (IND/TCL)
ghoti+@ANDREW.CMU.EDU (Adam Stoller) (11/17/89)
Thanks for the information - we're looking into fixing it now before the final release for the Xtape. Excerpts from internet.info-andrew: 15-Nov-89 Re: Some compilation problems Matt Burdick@ucbvax.Berk (1546) > This feature of the install program explains why I haven't gotten a > nonstripped version of runapp compiled yet, though. The nonstripped version is stored in the "objects" tree - or where the program was actually built - you can debug a core file from the stripped version against the nonstripped version (this of course, does eat up filespace - keeping both copies around) --fish