Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!stl!robobar!ronald From: ronald@robobar.co.uk (Ronald S H Khoo) Newsgroups: comp.lang.perl Subject: Re: compiling perl 4.003 on a Convex Message-ID: <1991Apr26.132814.7939@robobar.co.uk> Date: 26 Apr 91 13:28:14 GMT References: <1991Apr24.232208.24472@convex.com> <130322@uunet.UU.NET> Organization: Robobar Ltd., Perivale, Middx., ENGLAND. Lines: 27 rbj@uunet.UU.NET (Root Boy Jim) writes: > The right one is the only one. Why do you have two? I have several libc.a's, for compiling for different target systems. Yes, I can actually execute the executables of all of them on this system, but not necessarily the other way round ... I'm grateful that Configure now parameterizes the location of /usr/include, but I wish that it wouldn't go ahead an use /lib/libc.a when I'm actually going to link against /221/lib/Slibc.a. Seeing as /lib is going to be in libpth for systems that want /lib/libc.a anyway, why not dispense with the hardcoded /lib/libc.a ? The last time I compiled perl, I used libpth=/ESRCH and xlibpth=/221/lib *and I meant it!* > I assume you know how to make fake prototypes? > extern int open PROTO((char *path, int flags, int mode)); > Perhaps Larry should adopt that style. > Perhaps vendors should as well. The real point is that, for ANSI conformance, you should *not* redeclare stuff that's in the standard haders. So, if __STDC__, you *should* assume that they are adequately declared already. On the other hand, I'd have no truck with __stdc__, adding -D__STDC__ to hints/whatever should be the case, since this is an exception. -- Ronald Khoo +44 81 991 1142 (O) +44 71 229 7741 (H)