I understand. I've already appealed to a perl.HPUX list to no avail. I've only been dealing with HP-UX myself for about a year now (mostly Linux and Solaris before this). I agree though. This is most likely not a problem with mod_perl itself, but rather some interaction with perl 5.6 and HP-UX. I may return with other questions if I decide to pursue the non LFS install (which at least completes the make test with failed tests rather than hanging).
I will post the particulars if I ever track down this particular bugaboo. Thanks for your time. --- Will Fulmer Database Administrator Northampton Community College Bethlehem, PA >>> Stas Bekman <[EMAIL PROTECTED]> 8/12/2004 3:32:49 PM >>> William Fulmer wrote: > I did find some discussion of old HP-UX patches that fixed problems with > stat calls that some of HP's apps had. There are no particulars and > none pertain to system libraries, so they were no help. The issue here > may be that I'm a relative novice when it comes to C/C++ programming. > For instance, where does the magic happen that masks all of perls stat > calls to stat64 when you compile with LFS support? Some of the info out > there may contain the answer, but I can't see it for lack of this > knowledge. It happens during Perl compilation, where depending on compilation flags, either stat or stat64 is chosen. > I'm also wondering if the problem is not the actually call to stat64, > which looks like it returns the requested info, but whatever comes next. > That last line of the trace bothers me: > > [5889] In > user-mode.................................................................................[running] > > Very uninformative. Any guesses as to the meaning? Not really. > One of the other things that has been bothering me is that when I built > MP2 with perl 5.8.2, I couldn't get it to work without useshrlib > defined. For perl 5.6.2, perl won't even compile successfully if you > define this option. It tries to run miniperl during the compile and > that hangs with a trace ending in the same mysterious line. The > frustration thing about that is that LFS does not seem to affect this > particular problem. I'm left wondering if perhaps the real problem here > is that these two scenarios are trying to dynamically load libraries > that don't lend themselves to dynamic loading (e.g. libpthread.sl) I > eliminated the usual culprits such as pthread and libcl.sl and of course > there are no helpful messages to point at something else. > > I do see warnings about a symbol _attribute_ being defined again and > internal linking will occur, but as I said before, I don't know enough > about C to know if that has any significance at all. > > Any thought on these? All I can say that these aren't really mod_perl problems per se, even though they prevent you from using mod_perl. They are all OS level issues. You need to find someone who groks your platform's specifics and can advise us on using the right compile/linking flags to get things working. HP-UX is not the only platform mod_perl has a problem with. We have issues with AIX and other platforms. We have Randy Kobes and Steve Hay who do a great work handling the win32 build (which won't be possible w/o having an inhouse expert). The rest of us develop and familiar with Linux. We get random help for other platforms. Ideally what we need is to have an expert on those platforms Apache and Perl are running on to get mod_perl to run. I apologize for not being much of help with the problems you are having, William. -- __________________________________________________________________ Stas Bekman JAm_pH ------> Just Another mod_perl Hacker http://stason.org/ mod_perl Guide ---> http://perl.apache.org mailto:[EMAIL PROTECTED] http://use.perl.org http://apacheweek.com http://modperlbook.org http://apache.org http://ticketmaster.com -- Report problems: http://perl.apache.org/bugs/ Mail list info: http://perl.apache.org/maillist/modperl.html List etiquette: http://perl.apache.org/maillist/email-etiquette.html
