Received: (qmail 88638 invoked by uid 501); 15 Oct 2000 01:25:41 -0000 Message-Id: <20001015012541.88637.qmail@locus.apache.org> Date: 15 Oct 2000 01:25:41 -0000 From: Michael Long Reply-To: mlong@infoave.net To: submit@bugz.apache.org Subject: 2.0a7 osf - compile fails due to unresolved apr* X-Send-Pr-Version: 3.110 >Number: 6678 >Category: os-osf >Synopsis: 2.0a7 osf - compile fails due to unresolved apr* >Confidential: no >Severity: critical >Priority: medium >Responsible: apache >State: closed >Quarter: >Keywords: >Date-Required: >Class: sw-bug >Submitter-Id: apache >Arrival-Date: Sat Oct 14 18:30:00 PDT 2000 >Closed-Date: Sat Oct 21 06:21:48 PDT 2000 >Last-Modified: Sat Oct 21 06:21:48 PDT 2000 >Originator: mlong@infoave.net >Release: 2.0a7 >Organization: >Environment: [root@ml src]# uname -a OSF1 ml.is.infoave.net V5.0 1094 alpha [root@ml src]# sizer -v Compaq Tru64 UNIX V5.0A (Rev. 1094); Wed Sep 13 14:40:48 EDT 2000 [root@ml src]# cc -V Compaq C V6.1-019 on Compaq Tru64 UNIX V5.0A (Rev. 1094) >Description: Can't get apache 2.0 to compile: Making all in os Making all in unix Making all in support /bin/sh /usr/users/sysadmin/apache_2.0a7/src/libtool --silent --mode=link /bin/c c -I. -I/usr/users/sysadmin/apache_2.0a7/src/ -I/usr/users/sysadmin/apache_2.0a 7/src/modules/mpm/mpmt_pthread -I/usr/users/sysadmin/apache_2.0a7/src/include -I /usr/users/sysadmin/apache_2.0a7/src/lib/apr/include -I/usr/users/sysadmin/apach e_2.0a7/src/os/unix -I/usr/users/sysadmin/apache_2.0a7/src/lib/expat-lite -DOS F1 -pthread -export-dynamic -o httpd modules.lo buildmark.lo modules/standar d/libapachemod_env.la modules/standard/libapachemod_log_config.la modules/standa rd/libapachemod_mime.la modules/standard/libapachemod_negotiation.la modules/sta ndard/libapachemod_include.la modules/standard/libapachemod_autoindex.la modules /standard/libapachemod_dir.la modules/standard/libapachemod_asis.la modules/stan dard/libapachemod_imap.la modules/standard/libapachemod_actions.la modules/stand ard/libapachemod_userdir.la modules/standard/libapachemod_alias.la modules/stand ard/libapachemod_access.la modules/standard/libapachemod_auth.la modules/standar d/libapachemod_setenvif.la modules/standard/libapachemod_echo.la modules/standar d/libapachemod_cgid.la modules/mpm/mpmt_pthread/libmpmt_pthread.la main/libmai n.la os/unix/libos.la ap/libap.la lib/apr/libapr.a lib/pcre/libpcre.la lib/ex pat-lite/libexpat.la -lresolv -lm -lm ld: Unresolved: apr_unix_create_intra_lock apr_unix_lock_intra apr_unix_unlock_intra apr_unix_destroy_intra_lock *** Exit 1 Stop. *** Exit 1 Stop. >How-To-Repeat: >Fix: I'm not sure if this is a problem with apache or a problem with libtool. >Release-Note: >Audit-Trail: State-Changed-From-To: open-feedback State-Changed-By: rbb State-Changed-When: Sat Oct 14 19:40:50 PDT 2000 State-Changed-Why: Could you please provide the section of your apr.h header file that talks about locks? It should look something like: #define APR_USE_FLOCK_SERIALIZE 0 #define APR_USE_SYSVSEM_SERIALIZE 0 #define APR_USE_FCNTL_SERIALIZE 1 #define APR_USE_PROC_PTHREAD_SERIALIZE 0 #define APR_USE_PTHREAD_SERIALIZE 1 From: Michael Long To: rbb@apache.org Cc: apbugs@apache.org Subject: Re: os-osf/6678: 2.0a7 osf - compile fails due to unresolved apr* Date: Sun, 15 Oct 2000 00:25:47 -0400 src/lib/apr/include/apr.h #define APR_USE_FLOCK_SERIALIZE 0 #define APR_USE_SYSVSEM_SERIALIZE 0 #define APR_USE_FCNTL_SERIALIZE 1 #define APR_USE_PROC_PTHREAD_SERIALIZE 0 #define APR_USE_PTHREAD_SERIALIZE 0 --On Sunday, October 15, 2000 2:40 AM +0000 rbb@apache.org wrote: > [In order for any reply to be added to the PR database, you need] > [to include in the Cc line and make sure the] > [subject line starts with the report component and number, with ] > [or without any 'Re:' prefixes (such as "general/1098:" or ] > ["Re: general/1098:"). If the subject doesn't match this ] > [pattern, your message will be misfiled and ignored. The ] > ["apbugs" address is not added to the Cc line of messages from ] > [the database automatically because of the potential for mail ] > [loops. If you do not include this Cc, your reply may be ig- ] > [nored unless you are responding to an explicit request from a ] > [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] > > > Synopsis: 2.0a7 osf - compile fails due to unresolved apr* > > State-Changed-From-To: open-feedback > State-Changed-By: rbb > State-Changed-When: Sat Oct 14 19:40:50 PDT 2000 > State-Changed-Why: > Could you please provide the section of your apr.h header file > > that talks about locks? It should look something like: > > #define APR_USE_FLOCK_SERIALIZE 0 > #define APR_USE_SYSVSEM_SERIALIZE 0 > #define APR_USE_FCNTL_SERIALIZE 1 > #define APR_USE_PROC_PTHREAD_SERIALIZE 0 > #define APR_USE_PTHREAD_SERIALIZE 1 Michael Long Senior Systems Analyst Info Avenue Internet Services, LLC Comment-Added-By: rbb Comment-Added-When: Sat Oct 14 21:52:08 PDT 2000 Comment-Added: APR's configure script did not find a pthreads library on your system. Since you are using the mpmt_pthread MPM, you need to have some sort of thread locks. The configure script should have died when you tried to configure a threaded MPM without a pthreads library. Please run the following commands from your apache-2.0/src directory: cd lib/apr ./buildconf ./configure --enable-threads > output and send the output file to us. If your platform does not have a pthreads library, you will need one before Apache 2.0 will compile with any MPM other than prefork. To compile with a different MPM, in the apache-2.0/src directory run ./configure --with-mpm=foo, where foo is the name of the MPM. From: Michael Long To: rbb@apache.org Cc: apbugs@apache.org Subject: Re: os-osf/6678: 2.0a7 osf - compile fails due to unresolved apr* Date: Sun, 15 Oct 2000 01:36:52 -0400 Checking for Threads... checking for threads... yes checking for pthreads_cflags... -pthread checking for pthreads_lib... checking for pthread.h... yes checking whether pthread_getspecific takes two arguments... no checking whether pthread_attr_getdetachstate takes one argument... no checking for pthread_key_delete... yes APR will use threads checking for readdir in -lc_r... yes checking for poll... yes The system supports pthreads...but looks like configure can't find the library. Here is a list of the libraries on my system: /usr/shlib/libpthread.so /usr/shlib/libpthreaddebug.so /usr/shlib/libpthreads.so /usr/ccs/lib/lint/llib-lpthread.c /usr/ccs/lib/llib-lpthread.ln /usr/ccs/lib/libpthread.a /usr/ccs/lib/libpthreads.a /usr/lib/libpthread.a /usr/lib/libpthreads.a Although check this out from the pthread man page..it looks like cc may not require you to specify the library if you use the -pthread library: For users of the Compaq C and C++ compilers, compile a multithreaded appli- cation as follows: cc -c myprog.c -pthread For users of the Compaq C and C++ compilers, when linking your mul- tithreaded application that use DECthreads, include only the -pthread switch in the linker command line. Note that this switch also directs the linker to search for thread-reentrant variants (named with the "_r" suffix) of any libraries it searches. For users of other language environments or C and C++ compilers that do not support the -pthread linker switch, include these switches at the end of the linker command line: ld -o myprog myprog.o -lpthread -lexc -lc crt0.o or gcc -o myprog myprog.o -lpthread -lexc In this case, the -lpthread and -lexc switches direct the linker explicitly to use the DECthreads run-time and exception-handling libraries. These switches must immediately precede the -lc switch (if specified), which directs the linker to use the libc run-time library. If your application also requires specific thread-reentrant variants of libraries (such as the C run-time libraries), your linker command line must explicitly identify them or a search path for them. --On Sunday, October 15, 2000 4:52 AM +0000 rbb@apache.org wrote: > Comment-Added-By: rbb > Comment-Added-When: Sat Oct 14 21:52:08 PDT 2000 > Comment-Added: > APR's configure script did not find a pthreads library on your > system. Since you are using the mpmt_pthread MPM, you need > to have some sort of thread locks. > > The configure script should have died when you tried to configure > a threaded MPM without a pthreads library. > > Please run the following commands from your apache-2.0/src directory: > > cd lib/apr > ./buildconf > ./configure --enable-threads > output > > and send the output file to us. If your platform does not have > a pthreads library, you will need one before Apache 2.0 will > compile with any MPM other than prefork. > > To compile with a different MPM, in the apache-2.0/src > directory run ./configure --with-mpm=foo, where foo is the > name of the MPM. Michael Long Senior Systems Analyst Info Avenue Internet Services, LLC State-Changed-From-To: feedback-analyzed State-Changed-By: rbb State-Changed-When: Tue Oct 17 16:29:47 PDT 2000 State-Changed-Why: The issue. We have found pthreads and we know how to compile properly. Our autoconf script is able to determine that just using -pthreads will work on your system, and as soon as we know that, we also know that we don't need to use -lpthreads. This is why it looks like we didn't find the library. We could have found it, but we discovered we didn't need to. So, after we discover that you have pthreads, we need to find a way to serialize between threads. Unfortunately, this is done using a standard autoconf command AC_CHECK_FUNC. AC_CHECK_FUNC uses the LIBS variable when it looks for pthread_mutex_init later in the config process. If we found -pthread, then -lpthread is not in LIBS, and ld can't link a program with pthread_mnutex_init. Would you please apply this patch to the configure.in script in src/lib/apr and let us know if this solves the problem? Index: configure.in =================================================================== RCS file: /home/cvs/apache-2.0/src/lib/apr/configure.in,v retrieving revision 1.156 diff -u -d -b -w -u -r1.156 configure.in --- configure.in 2000/10/08 04:00:36 1.156 +++ configure.in 2000/10/17 23:28:20 @@ -606,6 +606,17 @@ AC_DEFINE(USE_PTHREAD_SERIALIZE) pthreadser="1" ]) fi + +if test "$pthreadser" = "0"; then + libstemp="$LIBS" + LIBS="$LIBS -lpthread" + AC_CHECK_FUNC(pthread_mutex_init, [ + AC_DEFINE(USE_PTHREAD_SERIALIZE) + pthreadser="1" ]) + LIBS="$libstemp" +fi + + AC_BEGIN_DECISION([ap_lock implementation method]) This should force autoconf to look for pthread_mutex_init a second time with -lpthread in the LIBS variable. From: Michael Long To: apache-bugdb@apache.org Cc: apbugs@apache.org Subject: Re: os-osf/6678: 2.0a7 osf - compile fails due to unresolved apr* Date: Tue, 17 Oct 2000 23:10:10 -0400 Almost but not quite... checking for sh... /bin/sh Check for compiler flags... Checking for Shared Memory Support... configuring package in shmem/unix/mm now /usr/users/sysadmin/cvsroot/apache-2.0/src/lib/apr/shmem/unix/mm/configure: sun4 : not found configure: error: cannot run configure failed for shmem/unix/mm configure failed for lib/apr -- It looks like $ac_config_sub is not defined...I don't see a definition for it anywhere in the configure script - is it supposed to pick it up from the calling script or the environment or something otherwise obscure? :) --On Tuesday, October 17, 2000 11:29 PM +0000 rbb@apache.org wrote: > [In order for any reply to be added to the PR database, you need] > [to include in the Cc line and make sure the] > [subject line starts with the report component and number, with ] > [or without any 'Re:' prefixes (such as "general/1098:" or ] > ["Re: general/1098:"). If the subject doesn't match this ] > [pattern, your message will be misfiled and ignored. The ] > ["apbugs" address is not added to the Cc line of messages from ] > [the database automatically because of the potential for mail ] > [loops. If you do not include this Cc, your reply may be ig- ] > [nored unless you are responding to an explicit request from a ] > [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] > > > Synopsis: 2.0a7 osf - compile fails due to unresolved apr* > > State-Changed-From-To: feedback-analyzed > State-Changed-By: rbb > State-Changed-When: Tue Oct 17 16:29:47 PDT 2000 > State-Changed-Why: > The issue. We have found pthreads and we know how to compile properly. > Our autoconf script is able to determine that just using -pthreads will > work on your system, and as soon as we know that, we also know that we > don't need to use -lpthreads. This is why it looks like we didn't find > the library. We could have found it, but we discovered we didn't need to. > > > > So, after we discover that you have pthreads, we need to find a way to > serialize between threads. Unfortunately, this is done using a standard > autoconf command AC_CHECK_FUNC. AC_CHECK_FUNC uses the LIBS variable > when it looks for pthread_mutex_init later in the config process. If we > found -pthread, then -lpthread is not in LIBS, and ld can't link a > program with pthread_mnutex_init. > > > > Would you please apply this patch to the configure.in script in > src/lib/apr and let us know if this solves the problem? > > > > > > Index: configure.in > > =================================================================== > > RCS file: /home/cvs/apache-2.0/src/lib/apr/configure.in,v > > retrieving revision 1.156 > > diff -u -d -b -w -u -r1.156 configure.in > > --- configure.in 2000/10/08 04:00:36 1.156 > > +++ configure.in 2000/10/17 23:28:20 > > @@ -606,6 +606,17 @@ > > AC_DEFINE(USE_PTHREAD_SERIALIZE) > > pthreadser="1" ]) > > fi > > + > > +if test "$pthreadser" = "0"; then > > + libstemp="$LIBS" > > + LIBS="$LIBS -lpthread" > > + AC_CHECK_FUNC(pthread_mutex_init, [ > > + AC_DEFINE(USE_PTHREAD_SERIALIZE) > > + pthreadser="1" ]) > > + LIBS="$libstemp" > > +fi > > + > > + > > AC_BEGIN_DECISION([ap_lock implementation method]) > > > > This should force autoconf to look for pthread_mutex_init a second time > with -lpthread in the LIBS variable. > Michael Long Senior Systems Analyst Info Avenue Internet Services, LLC From: rbb@covalent.net To: apache-bugdb@apache.org Cc: apbugs@apache.org Subject: Re: os-osf/6678: 2.0a7 osf - compile fails due to unresolved apr* Date: Tue, 17 Oct 2000 20:16:07 -0700 (PDT) But the patch did get us further, correct? I need to know so I can commit the change. Once we get past this issue, I will start to tackle the next one. Ryan On Tue, 17 Oct 2000, Michael Long wrote: > Almost but not quite... > > checking for sh... /bin/sh > > Check for compiler flags... > > Checking for Shared Memory Support... > > configuring package in shmem/unix/mm now > /usr/users/sysadmin/cvsroot/apache-2.0/src/lib/apr/shmem/unix/mm/configure: > sun4 > : not found > configure: error: cannot run > configure failed for shmem/unix/mm > configure failed for lib/apr > > -- > It looks like $ac_config_sub is not defined...I don't see a definition for > it anywhere in the configure script - is it supposed to pick it up from the > calling script or the environment or something otherwise obscure? :) > > --On Tuesday, October 17, 2000 11:29 PM +0000 rbb@apache.org wrote: > > > [In order for any reply to be added to the PR database, you need] > > [to include in the Cc line and make sure the] > > [subject line starts with the report component and number, with ] > > [or without any 'Re:' prefixes (such as "general/1098:" or ] > > ["Re: general/1098:"). If the subject doesn't match this ] > > [pattern, your message will be misfiled and ignored. The ] > > ["apbugs" address is not added to the Cc line of messages from ] > > [the database automatically because of the potential for mail ] > > [loops. If you do not include this Cc, your reply may be ig- ] > > [nored unless you are responding to an explicit request from a ] > > [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ] > > > > > > Synopsis: 2.0a7 osf - compile fails due to unresolved apr* > > > > State-Changed-From-To: feedback-analyzed > > State-Changed-By: rbb > > State-Changed-When: Tue Oct 17 16:29:47 PDT 2000 > > State-Changed-Why: > > The issue. We have found pthreads and we know how to compile properly. > > Our autoconf script is able to determine that just using -pthreads will > > work on your system, and as soon as we know that, we also know that we > > don't need to use -lpthreads. This is why it looks like we didn't find > > the library. We could have found it, but we discovered we didn't need to. > > > > > > > > So, after we discover that you have pthreads, we need to find a way to > > serialize between threads. Unfortunately, this is done using a standard > > autoconf command AC_CHECK_FUNC. AC_CHECK_FUNC uses the LIBS variable > > when it looks for pthread_mutex_init later in the config process. If we > > found -pthread, then -lpthread is not in LIBS, and ld can't link a > > program with pthread_mnutex_init. > > > > > > > > Would you please apply this patch to the configure.in script in > > src/lib/apr and let us know if this solves the problem? > > > > > > > > > > > > Index: configure.in > > > > =================================================================== > > > > RCS file: /home/cvs/apache-2.0/src/lib/apr/configure.in,v > > > > retrieving revision 1.156 > > > > diff -u -d -b -w -u -r1.156 configure.in > > > > --- configure.in 2000/10/08 04:00:36 1.156 > > > > +++ configure.in 2000/10/17 23:28:20 > > > > @@ -606,6 +606,17 @@ > > > > AC_DEFINE(USE_PTHREAD_SERIALIZE) > > > > pthreadser="1" ]) > > > > fi > > > > + > > > > +if test "$pthreadser" = "0"; then > > > > + libstemp="$LIBS" > > > > + LIBS="$LIBS -lpthread" > > > > + AC_CHECK_FUNC(pthread_mutex_init, [ > > > > + AC_DEFINE(USE_PTHREAD_SERIALIZE) > > > > + pthreadser="1" ]) > > > > + LIBS="$libstemp" > > > > +fi > > > > + > > > > + > > > > AC_BEGIN_DECISION([ap_lock implementation method]) > > > > > > > > This should force autoconf to look for pthread_mutex_init a second time > > with -lpthread in the LIBS variable. > > > > > > > Michael Long > Senior Systems Analyst > Info Avenue Internet Services, LLC > _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- From: rbb@covalent.net To: apache-bugdb@apache.org Cc: apbugs@apache.org Subject: Re: os-osf/6678: 2.0a7 osf - compile fails due to unresolved apr* Date: Wed, 18 Oct 2000 09:45:36 -0700 (PDT) Do me a favor, and re-run ./buildconf from the apache-2.0/src directory. It looks like something is really messed up with your autoconf. AC_CONFIG_AUX_DIRS should be defining ac_config_sub. Ryan On Tue, 17 Oct 2000, Michael Long wrote: > Almost but not quite... > > checking for sh... /bin/sh > > Check for compiler flags... > > Checking for Shared Memory Support... > > configuring package in shmem/unix/mm now > /usr/users/sysadmin/cvsroot/apache-2.0/src/lib/apr/shmem/unix/mm/configure: > sun4 > : not found > configure: error: cannot run > configure failed for shmem/unix/mm > configure failed for lib/apr > > -- > It looks like $ac_config_sub is not defined...I don't see a definition for > it anywhere in the configure script - is it supposed to pick it up from the > calling script or the environment or something otherwise obscure? :) _______________________________________________________________________________ Ryan Bloom rbb@apache.org 406 29th St. San Francisco, CA 94131 ------------------------------------------------------------------------------- State-Changed-From-To: analyzed-closed State-Changed-By: abagchi State-Changed-When: Sat Oct 21 06:21:48 PDT 2000 State-Changed-Why: This should be solved in CVS now. Instead of searching for pthreads mutex's, we just assume platforms have pthreads locks if they have pthreads. >Unformatted: [In order for any reply to be added to the PR database, you need] [to include in the Cc line and make sure the] [subject line starts with the report component and number, with ] [or without any 'Re:' prefixes (such as "general/1098:" or ] ["Re: general/1098:"). If the subject doesn't match this ] [pattern, your message will be misfiled and ignored. The ] ["apbugs" address is not added to the Cc line of messages from ] [the database automatically because of the potential for mail ] [loops. If you do not include this Cc, your reply may be ig- ] [nored unless you are responding to an explicit request from a ] [developer. Reply only with text; DO NOT SEND ATTACHMENTS! ]