RE: mod_perl make failed: cannot find -lapr
Here is an update: But before I begin, let me say thank you for both Stan Bekman and Randy Kobes for your assistance. So far, result was both good and bad. The original issue which I was facing appears to have been resolved. Unfortunately, yet another problem has been created. Hence, this problem may branch into a new issue for which I have started a new newsgroup thread. I would like to recap the measures which were taken for the benefit of others. So I'll discuss these points first. This will show what fix was used in order to resolve the initial problem. Then I'll address the new development. Refer below section Still again, another option to get the punch line. Background: To solve the original problem I was having, it appears as if a new set of source was needed, or the it might be resolved by acquiring just incremental changes. I didn't' have a client edition of CVS on my system, and I was trying to avoid bringing that package online. But I also can appreciate the difficulty of segregating non-CVS files from the entire release just to fix the problem I was having. So there seamed to be merit bringing going through yet another learning curve. The first set of alternatives: So, therefore, it looked as if I had two options to choose from 1) install CVS and get incremental code that way; or, 2) acquire an entire 'bleeding edge' software release. This wouldn't be 1.99_07 but result in acquiring the work in process edition-which was yet another item I was trying to avoid. I did work with CVS to bring it on line. (I did not have a CVS client established. I acquired the manuals, set up the environment variables, learned the syntax, etc. I stumbled for a while because I wasn't aware the package needed to be 'init'(ialized) before it would work. So although I used the proper command line syntax, it gave me numerous error messages. I eventually got to the point where the code imported, and the incremental updates were applied. But regretfully, the compilation still failed. The comment I would make about this is having both a CVS and non-CVS edition of source code available to the public is good. At time it maybe necessary to get the CVS code but for some this may turn out to be somewhat of a headache to bring online. Unfortunately, in my case, this turn out to be yet another rabbit trail. Yet another alternative was considered: At one point, to solve my problem, I tried to get another edition of apr, in the hope it might resolve issues with incompatibilities between software packages. Perhaps, I could go forward or backward one resolve to fix problems with the naming conventions. At least on my own system, conflicts were created with I downloaded the latest edition of apr. When this was compiled, I was no longer was I able to recompile apache and the issues with mod_perl compiling were not resolved. There appears to be a conflict with apache 2.0.43 with apr-0.9.2. Now things were definitely getting worse. Now web server was offline too and an important library directory had incompatible libraries in it. I lost territory. And I not so sure there is an issue with naming conventions after all, for I tried to use an earlier edition of apr dating back to august and it problems still existed. Further, between the different apr compilations the naming conventions did not change. I could investigate this further but I am not it would be worth the energy. Changes may have occurred but not with the source for which I was working with. Still again, another option: Then I hunted and pecked for a while for another alternative. (At this point, I was on a mission. Some minds are like finished cement, thoroughly mixed and permanently set. I would really like to get this online.) Finally, I discovered http://cvs.apache.org/snapshots/ and it was from this resource for which I able to get an easier solution. The is a different source rather than that found under http://perl.apache.org/dist/ and provided from http://perl.apache.org/download/source.html#2_0_Development_Source_Distr ibution Finally, a step in the right direction: I don't know if the is a difference between the distribution source vs. that found in the CVS source, or it there just happened to be recent changes (directories/links to these files), but there is a change in the outcome than what I was first working with. Through this new resource, I downloaded an entire software release and began to work with that. Fortunately, I was able to compile mod_perl. Progress at last! Working with mod_perl 2.0 was definitely better than edition 1.99_07. The bad news: But now a new problem has developed-the bad news. When httpd.conf configured to invoke the new mod_perl module, and when httpd is started, Apache is generates the following error message httpd failed. The error was: Starting httpd: httpd: module mod_perl.c is not compatible with this version of Apache. Please contact the vendor for the correct version.
mod_perl.c Not Compatible with Apache
Upon successfully compiling mod_perl 2.0, and modifying httpd.conf so that it becomes invoked at the start of Apache 2.0.43, the following error message is gernerated. It is httpd failed. The error was: Starting httpd: httpd: module mod_perl.c is not compatible with this version of Apache. Please contact the vendor for the correct version. [FAILED] If you would like you, may refer to the previous thread named mod_perl make failed: cannot find -lapr for a history of the root of this problem-particularly the last post directly before this article. This also shows the detail environment and configuration for the server in question. Else, I would be glad more details to this post. In brief, let me say, the system consists of RH 8.0, apache 2.0.43, and current CVS edition of mod_perl 2.0. It has a date stamp of 1/1/03. This is one problem which I don't know how to proceed with. Is this message saying the code in mod_perl's mod_perl.c is using an edition of 'C' code that is incompatible with Apache 2.0? Is the development environment for which mod_perl 2.0 is being developed, by its creators, using a 'C' compiler that is different than what is found on RH 8.0? Does any one have an idea of how I might go about solving this problem? Any advance given would be appreciated. Steve D
RE: mod_perl.c Not Compatible with Apache
Randy, All of what I've done, in the form of compiling software, has been done on the same computer and with the same release of the RH. So, there is nothing for which I'm doing to distinctly change which compiler is being used between the compilations of the packages. As best as I can recall, the answer is 'yes' to the last three questions you asked. 1) Everything compiles successfully. 2) The edition of mod_perl was obtained from cvs.apache.org while the Apache was from the distribution source repository. 3) The various release numbers for the packages where the most current; hence, 2.0.43 of Apache and 2.0 for mod_perl. Maybe there is some difference between the distribution and CVS versions of Apache. Perhaps, the next step will be to match packages via obtaining CVS editions from both packages and see what happens then. This shouldn't take to long. I'll give it a shot and provide an update. Let me also add, I'm grateful for your help. Thank you. Steve D The following comments were provided from Randy Kobes: I think in general the problem mod_perl.c is not compatible with this version of Apache. means that mod_perl was compiled against a different set of Apache sources than that used to build the server trying to load the mod_perl module (assuming that the same compiler is being used in building Perl, Apache, and mod_perl). Just to clarify what came from where - are you using a modperl-2.0 cvs snapshot from http://cvs.apache.org/snapshots/modperl-2.0/? - are you running Apache 2.0.43, compiled from the sources httpd-2.0.43.tar.gz from http://httpd.apache.org/dist/httpd/? If so, does modperl-2.0 compile against these apache 2.0 sources successfully? -- best regards, randy
RE: mod_perl.c Not Compatible with Apache
Randy, You 'maybe' on to something here. Let me report to you what I found. In order to be as careful and consistent as possible, I've actually started to keep a log of my activities. It records which commands which I've been used to compile the packages. So I can saw with certainty the following. Here are the parameters which I used to compile both Apache and mod_perl. To configure Apache: ./configure --prefix=/etc/httpd --with-mpm=prefork To configure mod_perl: perl Makefile.PL MP_AP_PREFIX=/etc/httpd MP_APXS=/etc/httpd/bin/apxs MP_INST_APACHE2=1 MP_DEBUG=1 Also, when I examine /etc/httpd/bin/httpd (the executable), /etc/httpd/lib/libarp*, and /etc/module/mod_perl.so, all the theses files have a creation date that's current (today's date). Plus, /etc/httpd/httpd.conf points to the current file locations. According to the RH 8.0 docs regarding Apache 2.X, they suggest modifying httpd.conf to incorporate the use of an include statement which invokes /etc/conf.d/perl.conf. This latter file points to /etc/httpd/module/mod_perl.3.0. I've mapped the files and dates. There doesn't appear to be any conflict here. However, for good measure, I just completed a search of the /etc/* and /usr/* directories for the presence of the httpd executable. And there are two of them on the system. To be expected, the /etc/httpd/bin/httpd executable is present. However, these is also an existence of a httpd executable under /usr/sbin. When I changed the name of /etc/sbin/httpd to /etc/sbin/httpd-bu (backup). The httpd web server wouldn't start any longer (I toggled this off and on via the service utilility [start - system settings - service]). /etc/sbin/httpd has a footprint of 384.7K where as /etc/httpd/bin/httpd is a 2meg file. I don't know whether /etc/sbin/httpd is being used to merely start /etc/httpd/bin/httpd or not. If you can advise further it would be helpful. This is the first time which I had to gain the merits (and subsequent challenges) of dealing with the open source world. Bringing mod_perl on-line has been a bitter-sweet experience. On the up side, it is certainly sweet to gain help from others for which I am exceedingly grateful for. In this regard, the help being provided is making this a better experience. To your credit, I not accustom to this type of aid when dealing with the proprietary world. That is, I am not familiar with receiving the same degree of cooperation, support, and camaraderie. Therefore, let me continue to express my gratitude. It means a lot to me. Thank you. Steve Steve D -Original Message- From: Randy Kobes [mailto:[EMAIL PROTECTED]] Sent: Friday, January 03, 2003 5:19 PM To: Steve Davis Cc: [EMAIL PROTECTED] Subject: RE: mod_perl.c Not Compatible with Apache On Fri, 3 Jan 2003, Steve Davis wrote: Randy, All of what I've done, in the form of compiling software, has been done on the same computer and with the same release of the RH. So, there is nothing for which I'm doing to distinctly change which compiler is being used between the compilations of the packages. As best as I can recall, the answer is 'yes' to the last three questions you asked. 1) Everything compiles successfully. 2) The edition of mod_perl was obtained from cvs.apache.org while the Apache was from the distribution source repository. 3) The various release numbers for the packages where the most current; hence, 2.0.43 of Apache and 2.0 for mod_perl. Maybe there is some difference between the distribution and CVS versions of Apache. Perhaps, the next step will be to match packages via obtaining CVS editions from both packages and see what happens then. This shouldn't take to long. I'll give it a shot and provide an update. This is strange ... I just tried, on a RedHat 7.1 system, the cvs modperl-2.0 sources compiled against Server version: Apache/2.0.43 built using stock httpd-2.0.43 sources, and it went fine. You shouldn't have to use the cvs apache sources. mod_perl was built as perl Makefile.PL MP_AP_PREFIX=/usr/local/httpd MP_INST_APACHE2=1 where the httpd binary is installed under /usr/local/httpd/bin. One thought ... Some Linux distributions come with their own Apache server, which may be in a different location than the Apache 2.0.43 you built and installed. Are you sure that the mod_perl you built is being used with your Apache-2.0.43 specified under MP_AP_PREFIX? -- best regards, randy
mod_perl make failed: cannot find -lapr
Your help will be very much appreciated to resolve the following issue. When attempting to make mod_perl.so, the make script 'almost' makes a touchdown but fails before getting to the finishing line. Now it is time get some help from a coach. Hopefully, with a little help, a touchdown will soon follow. Below, I present was appears to be the problem, but someone else will have to direct me to the next set of steps. I've spend an extensive amount of time trying to resolve this myself and it needs another set of eyes. The news groups were reviewed (repeatedly) for assistance, on-line docs, and what available books I could find. The environment is RH 8.0, Apache 2.0.43, Perl 5.8.0, mod_perl 1.99_07. As best as I can tell, Apache, Perl, and mod_perl have been compiled using the recommended configuration options listed in either Redhat's instructions or mod_perl's on-line docs. Get care has been taken to try to dot every one and cross every 't' to my ability. This problem 'may' have to do with an issue of a change of naming conventions which were adapted by the apr apache group. Confer with Stas Bekman's post on Nov 26, 2002 with a title of Problems compiling mod_perl 1.99_07 in RH 8.0. He provides a cvs patch; but, unfortunately, I'm not familiar with using that-as least-as of yet. (Look's like I might have learn this package real soon.) Are they any intentions to update the mod_perl-1.99_07.tar.gz? If my conclusion is correct, then currently, and according to the on-line instructions, the present tar.gz edition is not compatible to the latest edition of apache. (2.0.43). So, 'maybe' the cause of my make failure. It appears as if, only the cvs repository maybe a valid for compiling. If my analysis is correct, and a new edition of the respective non-cvs files be acquired somehow. I confuse my ignorance and lack of familiarity with these packages so I could be off. Thank you. Steve The environment is described below. Apache has been configured with --prefix=/etc/httpd --with-mpm=prefork. Perl has been configured with -des -Dusethreads -Doptimize='-g' -Dusedevel. The perl Makefile.PL was flagged with MP_AP_PREFIX=/etc/httpd MP_INST_APACHE2=1 MP_APXS=/etc/httpd/bin. (I also, attempted to configure the mod_perl makefile with the MP_APXS which generated the same error message.) The details follow below. Here is excerpt from the screen dump from the make output. make[1] : Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/WrapXS' make[1] : Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0' make[1] : Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/docs/api/mod_perl-2.0' make[1] : Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs' make[2] : Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR' make[3] : Entering directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR' rm -f ../../../blib/arch/Apache2/auto/APR/APR.so LD_RUN_PATH=/usr/lib cc -shared -L/usr/local/lib APR.o -o ../../../blib/arch/Apache2-lapr -laprutil /usr/bin/ld : cannot find -lapr collect2 : ld returned 1 exit status make[3] : *** [../../../blib/arch/Apache2/auto/APR/APR.so] Error 1 make[3] : Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR/APR' make[2] : *** [subdirs] Error 2 make[2] : Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs/APR' make[1] : *** [subdirs] Error 2 make[1]: Leaving directory `/usr/src/mod_perl/mod_perl-1.99_07/xs' m Here is a list of the files within /etc/httpd/lib. -rw-r--r-- 1 root root 6996 Dec 30 21:04 apr.exp -rw-r--r-- 1 root root 3481 Dec 30 21:04 aprutil.exp -rwxr-xr-x 1 root root 21354 Dec 30 21:01 apxs -rw-r--r-- 1 root root 2685082 Dec 30 21:03 libapr-0.a -rw-r--r-- 1 root root 628 Dec 30 21:03 libapr-0.la lrwxrwxrwx 1 root root 17 Dec 30 01:42 libapr-0.so - libapr-0.so.0.9.2 lrwxrwxrwx 1 root root 17 Dec 30 01:42 libapr-0.so.0 - libapr-0.so.0.9.2 -rwxr-xr-x 1 root root 1282063 Dec 30 01:42 libapr-0.so.0.9.2 -rw-r--r-- 1 root root 1425080 Dec 30 21:04 libaprutil-0.a -rw-r--r-- 1 root root 640 Dec 30 21:04 libaprutil-0.la lrwxrwxrwx 1 root root 21 Dec 30 01:42 libaprutil-0.so - libaprutil-0.so.0.9.2 lrwxrwxrwx 1 root root 21 Dec 30 01:42 libaprutil-0.so.0 - libaprutil-0.so.0.9.2 -rwxr-xr-x 1 root root 765330 Dec 30 01:42 libaprutil-0.so.0.9.2 In case the following can be of any value, here is further info. from the perl REPORT program. (In this case that would be, /usr/src/mod_perl/mod_perl-1.99_07/t.) . Problem Description: [DESCRIBE THE PROBLEM HERE] 2. Used Components and their Configuration: *** using /usr/src/mod_perl/mod_perl-1.99_07/t/../lib/Apache/BuildConfig.pm *** Makefile.PL options: MP_APXS =
