Thanks, Erdmut! Your description of file locations was very helpful. I actually got it to build. Unfortunately, it doesn't solve the problem, so I guess I may end up building an older version of php4. Unless there's a way to download?
Thanks again! Jen ----- Original Message ----- From: "Erdmut Pfeifer" <[EMAIL PROTECTED]> To: <debian-user@lists.debian.org> Sent: Friday, November 30, 2001 4:43 PM Subject: Re: Need help building php4 > On Fri, Nov 30, 2001 at 03:00:12PM -0800, jennyw wrote: > > Thanks! Actually, the thing I'm most unclear about is what all the output > > files are and where they go. I saw on another Web page that php4 is the > > only file that matters, so I'll try that this afternoon. But it seems that a > > lot of other files are generated, too. > > typically, a lot of intermediate files are being created (e.g. for > every source file (.c) there'll be an object file (.o) ). The configure > process itself also creates a couple of temporary files. You don't need > to worry about all those... > > Very generally speaking -- if we leave out any config and documentation > files for the moment -- the target of the build process will usually be > one or more of the following: (1) a binary executable (typically named > after the package), (2) a static library file (extension .a) or (3) a > dynamic library, also called shared object file (thus the extension > .so). Library filenames by convention start with "lib". > > If I understood you correctly, you're trying to build the dynamic php4 > module to be loaded into apache. In this case you probably only need > the "libphp4.so" shared-object file. After a successful build you can > fish that out of the ".lib" subdirectory (IIRC), that should've been > created in the source directory while building. Then simply replace the > other file of the same name (the one which refuses to work) with this > newly created one -- it should reside in /usr/lib/apache/1.3/. > > The php4 file you mentioned above is the stand-alone PHP binary for use > in conventional CGIs. I guess this is not the one you're interested in ;) > > If you'd rather like to try the automatic install, after having set up > the appropriate destination directories, but are still feeling a little > unsure about where stuff will be installed into, you can always try the > generic "dry run" facility of make (option -n), i.e. "make -n install" > (instead of the usual "make install"). This is supposed to cause make > to just print out what it *would* do without actually modifying > anything... It doesn't always work as desired under every circumstance, > though (i.e. if in intermediate steps some files need to be put in > their proper places to be able to continue with subsequent installation > steps...), so YMMV. But even then, you'll get a rough idea of where > stuff will be put, when looking at the directory names in the commands > being printed during the dry run... > > Cheers > > -- > Erdmut Pfeifer > science+computing ag > www.science-computing.de > > -- Bugs come in through open windows. Keep Windows shut! -- > > > -- > To UNSUBSCRIBE, email to [EMAIL PROTECTED] > with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED] > > > >
