mod_jk gmake recursion error on solaris 10 x86
I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX" to libtool checking for ld used by g++... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking whether the g++ linker (/usr/ccs/bin/ld) supports sha
Re: mod_jk gmake recursion error on solaris 10 x86
gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: > I am trying to compile mod_jk current on Solaris 10 x86 (intel). After > spending a huge amount of time, I finally get it to compile and this is > the output I receive. > > bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs > checking build system type... i386-pc-solaris2.10 > checking host system type... i386-pc-solaris2.10 > checking target system type... i386-pc-solaris2.10 > checking for a BSD-compatible install... scripts/build/unix/install-sh -c > checking whether build environment is sane... yes > checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d > checking for gawk... no > checking for mawk... no > checking for nawk... nawk > checking whether make sets $(MAKE)... yes > checking for test... /usr/bin/test > checking for rm... /usr/bin/rm > checking for grep... /usr/bin/grep > checking for echo... /usr/bin/echo > checking for sed... /usr/bin/sed > checking for cp... /usr/bin/cp > checking for mkdir... /usr/bin/mkdir > need to check for Perl first, apxs depends on it... > checking for perl... /usr/bin/perl > building connector for "apache-1.3" > checking for gcc... /usr/sfw/bin/gcc > checking for C compiler default output file name... a.out > checking whether the C compiler works... yes > checking whether we are cross compiling... no > checking for suffix of executables... > checking for suffix of object files... o > checking whether we are using the GNU C compiler... yes > checking whether /usr/sfw/bin/gcc accepts -g... yes > checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed > checking for style of include used by make... GNU > checking dependency style of /usr/sfw/bin/gcc... none > checking for a sed that does not truncate output... /usr/bin/sed > checking for grep that handles long lines and -e... (cached) /usr/bin/grep > checking for egrep... /usr/bin/egrep > checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld > checking if the linker (/usr/ccs/bin/ld) is GNU ld... no > checking for /usr/ccs/bin/ld option to reload object files... -r > checking for BSD-compatible nm... /usr/ccs/bin/nm -p > checking whether ln -s works... yes > checking how to recognize dependent libraries... pass_all > checking how to run the C preprocessor... /usr/sfw/bin/gcc -E > checking for ANSI C header files... yes > checking for sys/types.h... yes > checking for sys/stat.h... yes > checking for stdlib.h... yes > checking for string.h... yes > checking for memory.h... yes > checking for strings.h... yes > checking for inttypes.h... yes > checking for stdint.h... yes > checking for unistd.h... yes > checking dlfcn.h usability... yes > checking dlfcn.h presence... yes > checking for dlfcn.h... yes > checking for g++... g++ > checking whether we are using the GNU C++ compiler... yes > checking whether g++ accepts -g... yes > checking dependency style of g++... none > checking how to run the C++ preprocessor... g++ -E > checking for g77... no > checking for f77... no > checking for xlf... no > checking for frt... no > checking for pgf77... no > checking for cf77... no > checking for fort77... no > checking for fl32... no > checking for af77... no > checking for f90... no > checking for xlf90... no > checking for pgf90... no > checking for pghpf... no > checking for epcf90... no > checking for gfortran... no > checking for g95... no > checking for f95... no > checking for fort... no > checking for xlf95... no > checking for ifort... no > checking for ifc... no > checking for efc... no > checking for pgf95... no > checking for lf95... no > checking for ftn... no > checking whether we are using the GNU Fortran 77 compiler... no > checking whether accepts -g... no > checking the maximum length of command line arguments... 786240 > checking command to parse /usr/ccs/bin/nm -p output from > /usr/sfw/bin/gcc object... ok > checking for objdir... .libs > checking for ar... ar > checking for ranlib... ranlib > checking for strip... strip > checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no > checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC > checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes > checking if /usr/sfw/bin/gcc static flag -static works... no > checking if /usr/sfw/bin/gcc supports -c -o file.o... yes > checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports > shared libraries... yes > checking whether -lc should be explicitly linked in... yes > checking dynamic linker characteristics... solaris2.10 ld.so > checking how to hardcode library paths into programs... immediate > checking whether stripping libraries is possible... no > checking for shl_load... no > checking for shl_load in -ldld... no > checking for dlopen... yes > checking whether a program can dlopen itself... yes > checking whether a statically linked program can dlopen itself... yes > checking if
Re: mod_jk gmake recursion error on solaris 10 x86
ChrisS wrote: Partha Goswami wrote: gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending
Re: mod_jk gmake recursion error on solaris 10 x86
takeshi nakashima wrote: Please try: # mkdir /opt/SUNWspro # mkdir /opt/SUNWspro/bin # ln -s /usr/sfw/bin/gcc /opt/SUNWspro/bin/cc It seems that bundled *Apache2* is built by Sun Studio. (But bundled *Apache* is not clear for me...) # grep ^CC /var/apache2/build/libtool CC="/opt/SUNWspro/bin/cc" CC="/opt/SUNWspro/bin/cc" ChrisS wrote: ChrisS wrote: Partha Goswami wrote: gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -l
Re: mod_jk gmake recursion error on solaris 10 x86
no not , softlink, copy, the file & paste. On Wed, Mar 5, 2008 at 11:58 AM, ChrisS <[EMAIL PROTECTED]> wrote: > ChrisS wrote: > > Partha Goswami wrote: > >> gcc is, located, in /usr/sfw/bin you have to export part, or make > >> soft link, > >> for that... > >> > >> On Wed, Mar 5, 2008 at 11:17 AM, ChrisS > >> <[EMAIL PROTECTED]> > >> wrote: > >> > >> > >>> I am trying to compile mod_jk current on Solaris 10 x86 (intel). After > >>> spending a huge amount of time, I finally get it to compile and this > is > >>> the output I receive. > >>> > >>> bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs > >>> checking build system type... i386-pc-solaris2.10 > >>> checking host system type... i386-pc-solaris2.10 > >>> checking target system type... i386-pc-solaris2.10 > >>> checking for a BSD-compatible install... > >>> scripts/build/unix/install-sh -c > >>> checking whether build environment is sane... yes > >>> checking for a thread-safe mkdir -p... scripts/build/unix/install-sh > >>> -c -d > >>> checking for gawk... no > >>> checking for mawk... no > >>> checking for nawk... nawk > >>> checking whether make sets $(MAKE)... yes > >>> checking for test... /usr/bin/test > >>> checking for rm... /usr/bin/rm > >>> checking for grep... /usr/bin/grep > >>> checking for echo... /usr/bin/echo > >>> checking for sed... /usr/bin/sed > >>> checking for cp... /usr/bin/cp > >>> checking for mkdir... /usr/bin/mkdir > >>> need to check for Perl first, apxs depends on it... > >>> checking for perl... /usr/bin/perl > >>> building connector for "apache-1.3" > >>> checking for gcc... /usr/sfw/bin/gcc > >>> checking for C compiler default output file name... a.out > >>> checking whether the C compiler works... yes > >>> checking whether we are cross compiling... no > >>> checking for suffix of executables... > >>> checking for suffix of object files... o > >>> checking whether we are using the GNU C compiler... yes > >>> checking whether /usr/sfw/bin/gcc accepts -g... yes > >>> checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed > >>> checking for style of include used by make... GNU > >>> checking dependency style of /usr/sfw/bin/gcc... none > >>> checking for a sed that does not truncate output... /usr/bin/sed > >>> checking for grep that handles long lines and -e... (cached) > >>> /usr/bin/grep > >>> checking for egrep... /usr/bin/egrep > >>> checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld > >>> checking if the linker (/usr/ccs/bin/ld) is GNU ld... no > >>> checking for /usr/ccs/bin/ld option to reload object files... -r > >>> checking for BSD-compatible nm... /usr/ccs/bin/nm -p > >>> checking whether ln -s works... yes > >>> checking how to recognize dependent libraries... pass_all > >>> checking how to run the C preprocessor... /usr/sfw/bin/gcc -E > >>> checking for ANSI C header files... yes > >>> checking for sys/types.h... yes > >>> checking for sys/stat.h... yes > >>> checking for stdlib.h... yes > >>> checking for string.h... yes > >>> checking for memory.h... yes > >>> checking for strings.h... yes > >>> checking for inttypes.h... yes > >>> checking for stdint.h... yes > >>> checking for unistd.h... yes > >>> checking dlfcn.h usability... yes > >>> checking dlfcn.h presence... yes > >>> checking for dlfcn.h... yes > >>> checking for g++... g++ > >>> checking whether we are using the GNU C++ compiler... yes > >>> checking whether g++ accepts -g... yes > >>> checking dependency style of g++... none > >>> checking how to run the C++ preprocessor... g++ -E > >>> checking for g77... no > >>> checking for f77... no > >>> checking for xlf... no > >>> checking for frt... no > >>> checking for pgf77... no > >>> checking for cf77... no > >>> checking for fort77... no > >>> checking for fl32... no > >>> checking for af77... no > >>> checking for f90... no > >>> checking for xlf90... no > >>> checking for pgf90... no > >>> checking for pghpf... no > >>> checking for epcf90... no > >>> checking for gfortran... no > >>> checking for g95... no > >>> checking for f95... no > >>> checking for fort... no > >>> checking for xlf95... no > >>> checking for ifort... no > >>> checking for ifc... no > >>> checking for efc... no > >>> checking for pgf95... no > >>> checking for lf95... no > >>> checking for ftn... no > >>> checking whether we are using the GNU Fortran 77 compiler... no > >>> checking whether accepts -g... no > >>> checking the maximum length of command line arguments... 786240 > >>> checking command to parse /usr/ccs/bin/nm -p output from > >>> /usr/sfw/bin/gcc object... ok > >>> checking for objdir... .libs > >>> checking for ar... ar > >>> checking for ranlib... ranlib > >>> checking for strip... strip > >>> checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no > >>> checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC > >>> checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes > >>> checking if /usr/sfw/bin/gcc static flag -static works... no > >>> checking if /usr
Re: mod_jk gmake recursion error on solaris 10 x86
do one thing,, go /usr/sfw/bin folder, & copy the gcc file & paste it to, /usr/bin then try once again,, btw, which version of s-10 u r using? On Wed, Mar 5, 2008 at 11:46 AM, ChrisS <[EMAIL PROTECTED]> wrote: > ChrisS wrote: > > Partha Goswami wrote: > >> gcc is, located, in /usr/sfw/bin you have to export part, or make > >> soft link, > >> for that... > >> > >> On Wed, Mar 5, 2008 at 11:17 AM, ChrisS > >> <[EMAIL PROTECTED]> > >> wrote: > >> > >> > >>> I am trying to compile mod_jk current on Solaris 10 x86 (intel). After > >>> spending a huge amount of time, I finally get it to compile and this > is > >>> the output I receive. > >>> > >>> bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs > >>> checking build system type... i386-pc-solaris2.10 > >>> checking host system type... i386-pc-solaris2.10 > >>> checking target system type... i386-pc-solaris2.10 > >>> checking for a BSD-compatible install... > >>> scripts/build/unix/install-sh -c > >>> checking whether build environment is sane... yes > >>> checking for a thread-safe mkdir -p... scripts/build/unix/install-sh > >>> -c -d > >>> checking for gawk... no > >>> checking for mawk... no > >>> checking for nawk... nawk > >>> checking whether make sets $(MAKE)... yes > >>> checking for test... /usr/bin/test > >>> checking for rm... /usr/bin/rm > >>> checking for grep... /usr/bin/grep > >>> checking for echo... /usr/bin/echo > >>> checking for sed... /usr/bin/sed > >>> checking for cp... /usr/bin/cp > >>> checking for mkdir... /usr/bin/mkdir > >>> need to check for Perl first, apxs depends on it... > >>> checking for perl... /usr/bin/perl > >>> building connector for "apache-1.3" > >>> checking for gcc... /usr/sfw/bin/gcc > >>> checking for C compiler default output file name... a.out > >>> checking whether the C compiler works... yes > >>> checking whether we are cross compiling... no > >>> checking for suffix of executables... > >>> checking for suffix of object files... o > >>> checking whether we are using the GNU C compiler... yes > >>> checking whether /usr/sfw/bin/gcc accepts -g... yes > >>> checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed > >>> checking for style of include used by make... GNU > >>> checking dependency style of /usr/sfw/bin/gcc... none > >>> checking for a sed that does not truncate output... /usr/bin/sed > >>> checking for grep that handles long lines and -e... (cached) > >>> /usr/bin/grep > >>> checking for egrep... /usr/bin/egrep > >>> checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld > >>> checking if the linker (/usr/ccs/bin/ld) is GNU ld... no > >>> checking for /usr/ccs/bin/ld option to reload object files... -r > >>> checking for BSD-compatible nm... /usr/ccs/bin/nm -p > >>> checking whether ln -s works... yes > >>> checking how to recognize dependent libraries... pass_all > >>> checking how to run the C preprocessor... /usr/sfw/bin/gcc -E > >>> checking for ANSI C header files... yes > >>> checking for sys/types.h... yes > >>> checking for sys/stat.h... yes > >>> checking for stdlib.h... yes > >>> checking for string.h... yes > >>> checking for memory.h... yes > >>> checking for strings.h... yes > >>> checking for inttypes.h... yes > >>> checking for stdint.h... yes > >>> checking for unistd.h... yes > >>> checking dlfcn.h usability... yes > >>> checking dlfcn.h presence... yes > >>> checking for dlfcn.h... yes > >>> checking for g++... g++ > >>> checking whether we are using the GNU C++ compiler... yes > >>> checking whether g++ accepts -g... yes > >>> checking dependency style of g++... none > >>> checking how to run the C++ preprocessor... g++ -E > >>> checking for g77... no > >>> checking for f77... no > >>> checking for xlf... no > >>> checking for frt... no > >>> checking for pgf77... no > >>> checking for cf77... no > >>> checking for fort77... no > >>> checking for fl32... no > >>> checking for af77... no > >>> checking for f90... no > >>> checking for xlf90... no > >>> checking for pgf90... no > >>> checking for pghpf... no > >>> checking for epcf90... no > >>> checking for gfortran... no > >>> checking for g95... no > >>> checking for f95... no > >>> checking for fort... no > >>> checking for xlf95... no > >>> checking for ifort... no > >>> checking for ifc... no > >>> checking for efc... no > >>> checking for pgf95... no > >>> checking for lf95... no > >>> checking for ftn... no > >>> checking whether we are using the GNU Fortran 77 compiler... no > >>> checking whether accepts -g... no > >>> checking the maximum length of command line arguments... 786240 > >>> checking command to parse /usr/ccs/bin/nm -p output from > >>> /usr/sfw/bin/gcc object... ok > >>> checking for objdir... .libs > >>> checking for ar... ar > >>> checking for ranlib... ranlib > >>> checking for strip... strip > >>> checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no > >>> checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC > >>> checking if /usr/sfw/bin/gcc PIC flag -fPIC wo
Re: mod_jk gmake recursion error on solaris 10 x86
ChrisS wrote: Partha Goswami wrote: gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending
Re: mod_jk gmake recursion error on solaris 10 x86
ok. use this, # cd /usr/sfw/bin # ln-s gcc /usr/bin then try... & tell me.. On Wed, Mar 5, 2008 at 11:33 AM, ChrisS <[EMAIL PROTECTED]> wrote: > Partha Goswami wrote: > > gcc is, located, in /usr/sfw/bin you have to export part, or make soft > link, > > for that... > > > > On Wed, Mar 5, 2008 at 11:17 AM, ChrisS < > [EMAIL PROTECTED]> > > wrote: > > > > > >> I am trying to compile mod_jk current on Solaris 10 x86 (intel). After > >> spending a huge amount of time, I finally get it to compile and this is > >> the output I receive. > >> > >> bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs > >> checking build system type... i386-pc-solaris2.10 > >> checking host system type... i386-pc-solaris2.10 > >> checking target system type... i386-pc-solaris2.10 > >> checking for a BSD-compatible install... scripts/build/unix/install-sh > -c > >> checking whether build environment is sane... yes > >> checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c > -d > >> checking for gawk... no > >> checking for mawk... no > >> checking for nawk... nawk > >> checking whether make sets $(MAKE)... yes > >> checking for test... /usr/bin/test > >> checking for rm... /usr/bin/rm > >> checking for grep... /usr/bin/grep > >> checking for echo... /usr/bin/echo > >> checking for sed... /usr/bin/sed > >> checking for cp... /usr/bin/cp > >> checking for mkdir... /usr/bin/mkdir > >> need to check for Perl first, apxs depends on it... > >> checking for perl... /usr/bin/perl > >> building connector for "apache-1.3" > >> checking for gcc... /usr/sfw/bin/gcc > >> checking for C compiler default output file name... a.out > >> checking whether the C compiler works... yes > >> checking whether we are cross compiling... no > >> checking for suffix of executables... > >> checking for suffix of object files... o > >> checking whether we are using the GNU C compiler... yes > >> checking whether /usr/sfw/bin/gcc accepts -g... yes > >> checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed > >> checking for style of include used by make... GNU > >> checking dependency style of /usr/sfw/bin/gcc... none > >> checking for a sed that does not truncate output... /usr/bin/sed > >> checking for grep that handles long lines and -e... (cached) > /usr/bin/grep > >> checking for egrep... /usr/bin/egrep > >> checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld > >> checking if the linker (/usr/ccs/bin/ld) is GNU ld... no > >> checking for /usr/ccs/bin/ld option to reload object files... -r > >> checking for BSD-compatible nm... /usr/ccs/bin/nm -p > >> checking whether ln -s works... yes > >> checking how to recognize dependent libraries... pass_all > >> checking how to run the C preprocessor... /usr/sfw/bin/gcc -E > >> checking for ANSI C header files... yes > >> checking for sys/types.h... yes > >> checking for sys/stat.h... yes > >> checking for stdlib.h... yes > >> checking for string.h... yes > >> checking for memory.h... yes > >> checking for strings.h... yes > >> checking for inttypes.h... yes > >> checking for stdint.h... yes > >> checking for unistd.h... yes > >> checking dlfcn.h usability... yes > >> checking dlfcn.h presence... yes > >> checking for dlfcn.h... yes > >> checking for g++... g++ > >> checking whether we are using the GNU C++ compiler... yes > >> checking whether g++ accepts -g... yes > >> checking dependency style of g++... none > >> checking how to run the C++ preprocessor... g++ -E > >> checking for g77... no > >> checking for f77... no > >> checking for xlf... no > >> checking for frt... no > >> checking for pgf77... no > >> checking for cf77... no > >> checking for fort77... no > >> checking for fl32... no > >> checking for af77... no > >> checking for f90... no > >> checking for xlf90... no > >> checking for pgf90... no > >> checking for pghpf... no > >> checking for epcf90... no > >> checking for gfortran... no > >> checking for g95... no > >> checking for f95... no > >> checking for fort... no > >> checking for xlf95... no > >> checking for ifort... no > >> checking for ifc... no > >> checking for efc... no > >> checking for pgf95... no > >> checking for lf95... no > >> checking for ftn... no > >> checking whether we are using the GNU Fortran 77 compiler... no > >> checking whether accepts -g... no > >> checking the maximum length of command line arguments... 786240 > >> checking command to parse /usr/ccs/bin/nm -p output from > >> /usr/sfw/bin/gcc object... ok > >> checking for objdir... .libs > >> checking for ar... ar > >> checking for ranlib... ranlib > >> checking for strip... strip > >> checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no > >> checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC > >> checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes > >> checking if /usr/sfw/bin/gcc static flag -static works... no > >> checking if /usr/sfw/bin/gcc supports -c -o file.o... yes > >> checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld)
Re: mod_jk gmake recursion error on solaris 10 x86
Please try: # mkdir /opt/SUNWspro # mkdir /opt/SUNWspro/bin # ln -s /usr/sfw/bin/gcc /opt/SUNWspro/bin/cc It seems that bundled *Apache2* is built by Sun Studio. (But bundled *Apache* is not clear for me...) # grep ^CC /var/apache2/build/libtool CC="/opt/SUNWspro/bin/cc" CC="/opt/SUNWspro/bin/cc" ChrisS wrote: ChrisS wrote: Partha Goswami wrote: gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen.
Re: mod_jk gmake recursion error on solaris 10 x86
Partha Goswami wrote: gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -ldld... no checking for dlopen... yes checking whether a program can dlopen itself... yes checking whether a statically linked program can dlopen itself... yes checking if libtool supports shared libraries... yes checking whether to build shared libraries... yes checking whether to build static libraries... yes configure: creating libtool appending configuration tag "CXX
Re: mod_jk gmake recursion error on solaris 10 x86
takeshi nakashima wrote: Please try: # mkdir /opt/SUNWspro # mkdir /opt/SUNWspro/bin # ln -s /usr/sfw/bin/gcc /opt/SUNWspro/bin/cc It seems that bundled *Apache2* is built by Sun Studio. (But bundled *Apache* is not clear for me...) # grep ^CC /var/apache2/build/libtool CC="/opt/SUNWspro/bin/cc" CC="/opt/SUNWspro/bin/cc" ChrisS wrote: ChrisS wrote: Partha Goswami wrote: gcc is, located, in /usr/sfw/bin you have to export part, or make soft link, for that... On Wed, Mar 5, 2008 at 11:17 AM, ChrisS <[EMAIL PROTECTED]> wrote: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 checking for a BSD-compatible install... scripts/build/unix/install-sh -c checking whether build environment is sane... yes checking for a thread-safe mkdir -p... scripts/build/unix/install-sh -c -d checking for gawk... no checking for mawk... no checking for nawk... nawk checking whether make sets $(MAKE)... yes checking for test... /usr/bin/test checking for rm... /usr/bin/rm checking for grep... /usr/bin/grep checking for echo... /usr/bin/echo checking for sed... /usr/bin/sed checking for cp... /usr/bin/cp checking for mkdir... /usr/bin/mkdir need to check for Perl first, apxs depends on it... checking for perl... /usr/bin/perl building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc checking for C compiler default output file name... a.out checking whether the C compiler works... yes checking whether we are cross compiling... no checking for suffix of executables... checking for suffix of object files... o checking whether we are using the GNU C compiler... yes checking whether /usr/sfw/bin/gcc accepts -g... yes checking for /usr/sfw/bin/gcc option to accept ISO C89... none needed checking for style of include used by make... GNU checking dependency style of /usr/sfw/bin/gcc... none checking for a sed that does not truncate output... /usr/bin/sed checking for grep that handles long lines and -e... (cached) /usr/bin/grep checking for egrep... /usr/bin/egrep checking for ld used by /usr/sfw/bin/gcc... /usr/ccs/bin/ld checking if the linker (/usr/ccs/bin/ld) is GNU ld... no checking for /usr/ccs/bin/ld option to reload object files... -r checking for BSD-compatible nm... /usr/ccs/bin/nm -p checking whether ln -s works... yes checking how to recognize dependent libraries... pass_all checking how to run the C preprocessor... /usr/sfw/bin/gcc -E checking for ANSI C header files... yes checking for sys/types.h... yes checking for sys/stat.h... yes checking for stdlib.h... yes checking for string.h... yes checking for memory.h... yes checking for strings.h... yes checking for inttypes.h... yes checking for stdint.h... yes checking for unistd.h... yes checking dlfcn.h usability... yes checking dlfcn.h presence... yes checking for dlfcn.h... yes checking for g++... g++ checking whether we are using the GNU C++ compiler... yes checking whether g++ accepts -g... yes checking dependency style of g++... none checking how to run the C++ preprocessor... g++ -E checking for g77... no checking for f77... no checking for xlf... no checking for frt... no checking for pgf77... no checking for cf77... no checking for fort77... no checking for fl32... no checking for af77... no checking for f90... no checking for xlf90... no checking for pgf90... no checking for pghpf... no checking for epcf90... no checking for gfortran... no checking for g95... no checking for f95... no checking for fort... no checking for xlf95... no checking for ifort... no checking for ifc... no checking for efc... no checking for pgf95... no checking for lf95... no checking for ftn... no checking whether we are using the GNU Fortran 77 compiler... no checking whether accepts -g... no checking the maximum length of command line arguments... 786240 checking command to parse /usr/ccs/bin/nm -p output from /usr/sfw/bin/gcc object... ok checking for objdir... .libs checking for ar... ar checking for ranlib... ranlib checking for strip... strip checking if /usr/sfw/bin/gcc supports -fno-rtti -fno-exceptions... no checking for /usr/sfw/bin/gcc option to produce PIC... -fPIC checking if /usr/sfw/bin/gcc PIC flag -fPIC works... yes checking if /usr/sfw/bin/gcc static flag -static works... no checking if /usr/sfw/bin/gcc supports -c -o file.o... yes checking whether the /usr/sfw/bin/gcc linker (/usr/ccs/bin/ld) supports shared libraries... yes checking whether -lc should be explicitly linked in... yes checking dynamic linker characteristics... solaris2.10 ld.so checking how to hardcode library paths into programs... immediate checking whether stripping libraries is possible... no checking for shl_load... no checking for shl_load in -l
Re: mod_jk gmake recursion error on solaris 10 x86
Hi Chris, ChrisS schrieb: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 ... building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc Yu have gcc installed, and configure finds it as the first compiler it is looking for. It will use gcc to detect, how the build system should optimise itself to your environment. checking for C compiler default output file name... a.out checking whether the C compiler works... yes ... configure: WARNING: Using CC from environment: configure: WARNING: CC="/usr/sfw/bin/gcc" configure: WARNING: instead of CC from apxs: configure: WARNING: CC="cc" configure: WARNING: If "make" throws an error of the form configure: WARNING: "libtool: compile: unable to infer tagged configuration"configure: WARNING: "libtool: compile: specify a tag with `--tag'" configure: WARNING: try running configure without setting CC, configure: WARNING: or at least CC should start with "cc" bash-3.00# The apxs installed with your httpd tells us, that you httpd has been compiled with a different toolchain. it wasn't produced with a gcc based toolchain, but instead with Sun tools. I guess, the whole httpd is the one coming with Solaris. I have not been able to figure out the warnings on this as of yet and I have tried setting various enviroment variables to combat it, all to no avail. This is the output from my gmake attempt: bash-3.00#gmake Making all in common ... gmake[1]: Entering directory `/www/connectors/jk/native/apache-1.3' /bin/sh ../libtool --mode=link /usr/sfw/bin/gcc -o mod_jk.la -module -rpath /usr/apache/libexec mod_jk.lo ../common/jk_ajp12_worker.lo ../common/jk_connect.lo ../common/jk_msg_buff.lo ../common/jk_util.lo ../common/jk_ajp13.lo ../common/jk_pool.lo ../common/jk_worker.lo ../common/jk_ajp13_worker.lo ../common/jk_lb_worker.lo ../common/jk_sockbuf.lo ../common/jk_map.lo ../common/jk_uri_worker_map.lo ../common/jk_ajp14.lo ../common/jk_ajp14_worker.lo ../common/jk_md5.lo ../common/jk_shm.lo ../common/jk_ajp_common.lo ../common/jk_context.lo ../common/jk_url.lo ../common/jk_status.lo /usr/sfw/bin/gcc -shared -Wl,-h -Wl,mod_jk.so.0 -o .libs/mod_jk.so.0.0.0 .libs/mod_jk.o ../common/.libs/jk_ajp12_worker.o ../common/.libs/jk_connect.o ../common/.libs/jk_msg_buff.o ../common/.libs/jk_util.o ../common/.libs/jk_ajp13.o ../common/.libs/jk_pool.o ../common/.libs/jk_worker.o ../common/.libs/jk_ajp13_worker.o ../common/.libs/jk_lb_worker.o ../common/.libs/jk_sockbuf.o ../common/.libs/jk_map.o ../common/.libs/jk_uri_worker_map.o ../common/.libs/jk_ajp14.o ../common/.libs/jk_ajp14_worker.o ../common/.libs/jk_md5.o ../common/.libs/jk_shm.o ../common/.libs/jk_ajp_common.o ../common/.libs/jk_context.o ../common/.libs/jk_url.o ../common/.libs/jk_status.o -lc gcc: .libs/mod_jk.o: No such file or directory gcc: ../common/.libs/jk_ajp12_worker.o: No such file or directory gcc: ../common/.libs/jk_connect.o: No such file or directory ... gmake[1]: *** [mod_jk.la] Error 1 gmake[1]: Leaving directory `/www/connectors/jk/native/apache-1.3' gmake: *** [all-recursive] Error 1 bash-3.00# The module build system for mod_jk is based on the standard module build system for Apache httpd. The philosophy is: the module asks httpd how it got build and tries to use the same commands/flags in order to make the module most likely binary compatible with the web server. The facility to enable such a build system is apxs, which comes with htpd, and which can be asked about the original build flags used for httpd. Our mod_jk configure asks apxs about the right flags, but then you are actually using a totally different toolchain (gcc based), than the one used to build apache httpd (Sun Studio). That's a hard and unstable way to go. You could try to write a gcc wraper named cc which tries to tralsate all used cc flags to gcc ones, but that's more an experiment than building production software. So you should either: get the same toolchain, that was used to build your Apache httpd and use that toolchain to build your module. In your case: install Sun studio and take care, that configure does find /usr/ccs/bin/cc and nor /usr/sfw/bin/gcc. It could well be, that it's not enough to put /usr/ccs/bin in front f /zsr/sfw/bin in the PATH, but that you would furthermore need to temporarily remove/rename gcc, s.t. configure doesn't find it. Removing the whole /usr/sfw/bin from the PATH might be to string, because e.g. you'll need gmake form that path. Or: you switch over to the gcc (/usr/sfw/) toolchain completely, which would mean starting with building Apache httpd with this toolchain (or find some re
Re: mod_jk gmake recursion error on solaris 10 x86
Rainer Jung wrote: Hi Chris, ChrisS schrieb: I am trying to compile mod_jk current on Solaris 10 x86 (intel). After spending a huge amount of time, I finally get it to compile and this is the output I receive. bash-3.00#./configure --with-apxs=/usr/apache/bin/apxs checking build system type... i386-pc-solaris2.10 checking host system type... i386-pc-solaris2.10 checking target system type... i386-pc-solaris2.10 ... building connector for "apache-1.3" checking for gcc... /usr/sfw/bin/gcc Yu have gcc installed, and configure finds it as the first compiler it is looking for. It will use gcc to detect, how the build system should optimise itself to your environment. checking for C compiler default output file name... a.out checking whether the C compiler works... yes ... configure: WARNING: Using CC from environment: configure: WARNING: CC="/usr/sfw/bin/gcc" configure: WARNING: instead of CC from apxs: configure: WARNING: CC="cc" configure: WARNING: If "make" throws an error of the form configure: WARNING: "libtool: compile: unable to infer tagged configuration"configure: WARNING: "libtool: compile: specify a tag with `--tag'" configure: WARNING: try running configure without setting CC, configure: WARNING: or at least CC should start with "cc" bash-3.00# The apxs installed with your httpd tells us, that you httpd has been compiled with a different toolchain. it wasn't produced with a gcc based toolchain, but instead with Sun tools. I guess, the whole httpd is the one coming with Solaris. I have not been able to figure out the warnings on this as of yet and I have tried setting various enviroment variables to combat it, all to no avail. This is the output from my gmake attempt: bash-3.00#gmake Making all in common ... gmake[1]: Entering directory `/www/connectors/jk/native/apache-1.3' /bin/sh ../libtool --mode=link /usr/sfw/bin/gcc -o mod_jk.la -module -rpath /usr/apache/libexec mod_jk.lo ../common/jk_ajp12_worker.lo ../common/jk_connect.lo ../common/jk_msg_buff.lo ../common/jk_util.lo ../common/jk_ajp13.lo ../common/jk_pool.lo ../common/jk_worker.lo ../common/jk_ajp13_worker.lo ../common/jk_lb_worker.lo ../common/jk_sockbuf.lo ../common/jk_map.lo ../common/jk_uri_worker_map.lo ../common/jk_ajp14.lo ../common/jk_ajp14_worker.lo ../common/jk_md5.lo ../common/jk_shm.lo ../common/jk_ajp_common.lo ../common/jk_context.lo ../common/jk_url.lo ../common/jk_status.lo /usr/sfw/bin/gcc -shared -Wl,-h -Wl,mod_jk.so.0 -o .libs/mod_jk.so.0.0.0 .libs/mod_jk.o ../common/.libs/jk_ajp12_worker.o ../common/.libs/jk_connect.o ../common/.libs/jk_msg_buff.o ../common/.libs/jk_util.o ../common/.libs/jk_ajp13.o ../common/.libs/jk_pool.o ../common/.libs/jk_worker.o ../common/.libs/jk_ajp13_worker.o ../common/.libs/jk_lb_worker.o ../common/.libs/jk_sockbuf.o ../common/.libs/jk_map.o ../common/.libs/jk_uri_worker_map.o ../common/.libs/jk_ajp14.o ../common/.libs/jk_ajp14_worker.o ../common/.libs/jk_md5.o ../common/.libs/jk_shm.o ../common/.libs/jk_ajp_common.o ../common/.libs/jk_context.o ../common/.libs/jk_url.o ../common/.libs/jk_status.o -lc gcc: .libs/mod_jk.o: No such file or directory gcc: ../common/.libs/jk_ajp12_worker.o: No such file or directory gcc: ../common/.libs/jk_connect.o: No such file or directory ... gmake[1]: *** [mod_jk.la] Error 1 gmake[1]: Leaving directory `/www/connectors/jk/native/apache-1.3' gmake: *** [all-recursive] Error 1 bash-3.00# The module build system for mod_jk is based on the standard module build system for Apache httpd. The philosophy is: the module asks httpd how it got build and tries to use the same commands/flags in order to make the module most likely binary compatible with the web server. The facility to enable such a build system is apxs, which comes with htpd, and which can be asked about the original build flags used for httpd. Our mod_jk configure asks apxs about the right flags, but then you are actually using a totally different toolchain (gcc based), than the one used to build apache httpd (Sun Studio). That's a hard and unstable way to go. You could try to write a gcc wraper named cc which tries to tralsate all used cc flags to gcc ones, but that's more an experiment than building production software. So you should either: get the same toolchain, that was used to build your Apache httpd and use that toolchain to build your module. In your case: install Sun studio and take care, that configure does find /usr/ccs/bin/cc and nor /usr/sfw/bin/gcc. It could well be, that it's not enough to put /usr/ccs/bin in front f /zsr/sfw/bin in the PATH, but that you would furthermore need to temporarily remove/rename gcc, s.t. configure doesn't find it. Removing the whole /usr/sfw/bin from the PATH might be to string, because e.g. you'll need gmake form that path. Or: you switch over to the gcc (/usr/sfw/) toolchain completely, which would mean starting with building Apache httpd with this tool
Re: mod_jk gmake recursion error on solaris 10 x86
Hi Chris, ChrisS schrieb: I installed Sun Studio 11 and included it first in the $PATH env variable. This cleaned up the nasty warnings about CC. Then I built it with: gmake and then gmake clean this was also successful. Libtool was then used to pass the mod_jk.so file to its location in this case: /www/apache/libexec I do however have one problem and it is a biggy. LoadModule along with LoadFile(testing) will not load the module into my 1.3.39 dist. The error message thrown is this: ../bin/apachectl start Syntax error on line 237 of /www/apache/conf/httpd.conf: Cannot load /www/connectors/jk/native/apache-1.3/mod_jk.so into server:ld.so.1: libhttpd.ep: fatal: relocation error: file /www/connectors/jk/native/apache-1.3/mod_jk.so: symbol ap_ctx_get: referenced symbol not found ../bin/apachectl start: httpd could not be started The symbol ap_ctx_get, which is missing here is not included in a standard httpd 1.3. It comes with the extended API (EAPI) bundled with mod_ssl. mod_ssl for Apache httpd 1.3 mainly consists of the ssl module and a set of aditional patches for httpd 1.3, which extend the module API, s.t. the more complex ssl functionality fits into the httpd module API. In the following I'll not make a distinction between EAPI and mod_ssl. Maybe the mod_jk.so you are trying to load here is the one on our project download page? Because that one explicitely states in the README, that it has been build against an EAPI enabled httpd. Or you build your mod_jk against an ssl enabled httpd and afterwards try to ue it inside one, which is a plain one. Although mod_jk soesn't really have a dependency on ssl, there is one symbol, ap_default_port, that the patches for mod_ssl redefine (you can imagine, that the default port with ssl depends on the fact, if one uses ssl (443) or not (80)) and thus when mod_jk gets build against an ssl enabled httpd, the resulting mod_jk.so has a single additional dependency, namely ap_ctx_get(). Before trying to fix this reconsider your choice of httpd first. Version 1.3 is now very outdated. The httpd project already officially announced, that they put a very high bar on patches they are going to apply to 1.3. Mainly they'll only fix critical security issues. If I would start with something new today, I would really choose httpd 2.2.x. This will provide you a much more future proof environment. It comed with builtin ssl support, ldap support, a much better reverse proxy, less 64 Bit problems (likely even no 64 Bit problems) and much more. Please could you help me, I have tried compiling the Apache Dist with: ./configure --prefix=/www/apache --enable-module=most --enable-shared=max --enable-rule=SHARED_CORE $ make $ make install Don't know about enable-rule, but it doesn't look wrong. Believing that this would resolve my symbol issue. Symbols are in the table this was shown with: nm /www/apache/bin/httpd but none for ap_ctx_get Yes, because it's a non mod_ssl httpd 1.3. But: nm on mod_jk.so should also show, that mod_jk does *not* want that symbol. Kindest Regards ps Thanks for all the help so far guys!! Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk gmake recursion error on solaris 10 x86
Rainer Jung wrote: Hi Chris, ChrisS schrieb: I installed Sun Studio 11 and included it first in the $PATH env variable. This cleaned up the nasty warnings about CC. Then I built it with: gmake and then gmake clean this was also successful. Libtool was then used to pass the mod_jk.so file to its location in this case: /www/apache/libexec I do however have one problem and it is a biggy. LoadModule along with LoadFile(testing) will not load the module into my 1.3.39 dist. The error message thrown is this: ../bin/apachectl start Syntax error on line 237 of /www/apache/conf/httpd.conf: Cannot load /www/connectors/jk/native/apache-1.3/mod_jk.so into server:ld.so.1: libhttpd.ep: fatal: relocation error: file /www/connectors/jk/native/apache-1.3/mod_jk.so: symbol ap_ctx_get: referenced symbol not found ../bin/apachectl start: httpd could not be started The symbol ap_ctx_get, which is missing here is not included in a standard httpd 1.3. It comes with the extended API (EAPI) bundled with mod_ssl. mod_ssl for Apache httpd 1.3 mainly consists of the ssl module and a set of aditional patches for httpd 1.3, which extend the module API, s.t. the more complex ssl functionality fits into the httpd module API. In the following I'll not make a distinction between EAPI and mod_ssl. Maybe the mod_jk.so you are trying to load here is the one on our project download page? Because that one explicitely states in the README, that it has been build against an EAPI enabled httpd. Or you build your mod_jk against an ssl enabled httpd and afterwards try to ue it inside one, which is a plain one. Although mod_jk soesn't really have a dependency on ssl, there is one symbol, ap_default_port, that the patches for mod_ssl redefine (you can imagine, that the default port with ssl depends on the fact, if one uses ssl (443) or not (80)) and thus when mod_jk gets build against an ssl enabled httpd, the resulting mod_jk.so has a single additional dependency, namely ap_ctx_get(). Before trying to fix this reconsider your choice of httpd first. Version 1.3 is now very outdated. The httpd project already officially announced, that they put a very high bar on patches they are going to apply to 1.3. Mainly they'll only fix critical security issues. If I would start with something new today, I would really choose httpd 2.2.x. This will provide you a much more future proof environment. It comed with builtin ssl support, ldap support, a much better reverse proxy, less 64 Bit problems (likely even no 64 Bit problems) and much more. Please could you help me, I have tried compiling the Apache Dist with: ./configure --prefix=/www/apache --enable-module=most --enable-shared=max --enable-rule=SHARED_CORE $ make $ make install Don't know about enable-rule, but it doesn't look wrong. Believing that this would resolve my symbol issue. Symbols are in the table this was shown with: nm /www/apache/bin/httpd but none for ap_ctx_get Yes, because it's a non mod_ssl httpd 1.3. But: nm on mod_jk.so should also show, that mod_jk does *not* want that symbol. Kindest Regards ps Thanks for all the help so far guys!! Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Ok Rainer that solves that one, I do have a built in Apache Solaris 10 dist this is: bash-3.00# /usr/apache2/bin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c bash-3.00# /usr/apache2/bin/httpd -v Server version: Apache/2.0.63 Server built: Feb 5 2008 11:13:45 bash-3.00# Please recommend! almost forgot thanks helluvalot. Would this config suffice mate!!! ps I really wanted to get this sorted for a mate in work, we have a clustered setup not clustering between Tomcat nodes on a 1.3.39 setup, there are also session sharing issues with deployed apps, the idea was to lab the problem and try to find a resolve. I would need to check the SSL status exactly but this is running/serving SSL requests on a Sparc SunBlaze server. Would the binary dist of mod_jk (current) work with this environment ? this being a great deal saner than this one I am using - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk gmake recursion error on solaris 10 x86
Unfortunately I have some difficulties to understand, what you want to tell me: Ok Rainer that solves that one, I do have a built in Apache Solaris 10 What solves what? dist this is: bash-3.00# /usr/apache2/bin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c bash-3.00# /usr/apache2/bin/httpd -v Server version: Apache/2.0.63 Server built: Feb 5 2008 11:13:45 bash-3.00# Please recommend! almost forgot thanks helluvalot. Not sure, what you mean by recommend? I was suggesting 2.2.x, you have a 2.0.x. That's not exactly the same :) Quite possible, that it's more important for you to use a Solaris bundled httpd instead of a self build one. If that is a wise decision depends on the importance Apache httpd has for you. If it is really important, I would not necessarily rely on the OS delivering company to provide needed updates in time. Would this config suffice mate!!! I don't get this, it's a question with exclamation marks, hm ps I really wanted to get this sorted for a mate in work, we have a clustered setup not clustering between Tomcat nodes on a 1.3.39 setup, there are also session sharing issues with deployed apps, the idea was to lab the problem and try to find a resolve. Aha, so then it makes sense to use the same versions, you also have in production. I would need to check the SSL status exactly but this is running/serving SSL requests on a Sparc SunBlaze server. Would the binary dist of mod_jk (current) work with this environment ? this being a great deal saner than this one I am using Which binary dist? The one from the ASF download page? Yes, that one will need an EAPI httpd, i.e. one build with ssl support. Will this be saner? Not sure. Our binary dist is build with gcc and the httpd we are talking about might be build with Sun Studio (not sure, if we are talking about yet another httpd). Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk gmake recursion error on solaris 10 x86
Rainer Jung wrote: Unfortunately I have some difficulties to understand, what you want to tell me: Ok Rainer that solves that one, I do have a built in Apache Solaris 10 What solves what? dist this is: bash-3.00# /usr/apache2/bin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c bash-3.00# /usr/apache2/bin/httpd -v Server version: Apache/2.0.63 Server built: Feb 5 2008 11:13:45 bash-3.00# Please recommend! almost forgot thanks helluvalot. Not sure, what you mean by recommend? I was suggesting 2.2.x, you have a 2.0.x. That's not exactly the same :) Quite possible, that it's more important for you to use a Solaris bundled httpd instead of a self build one. If that is a wise decision depends on the importance Apache httpd has for you. If it is really important, I would not necessarily rely on the OS delivering company to provide needed updates in time. Would this config suffice mate!!! I don't get this, it's a question with exclamation marks, hm ps I really wanted to get this sorted for a mate in work, we have a clustered setup not clustering between Tomcat nodes on a 1.3.39 setup, there are also session sharing issues with deployed apps, the idea was to lab the problem and try to find a resolve. Aha, so then it makes sense to use the same versions, you also have in production. I would need to check the SSL status exactly but this is running/serving SSL requests on a Sparc SunBlaze server. Would the binary dist of mod_jk (current) work with this environment ? this being a great deal saner than this one I am using Which binary dist? The one from the ASF download page? Yes, that one will need an EAPI httpd, i.e. one build with ssl support. Will this be saner? Not sure. Our binary dist is build with gcc and the httpd we are talking about might be build with Sun Studio (not sure, if we are talking about yet another httpd). Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The binary distribution referred to is mod_jk, I remember seeing one in the mirrors for a Sparc installation only! isn't there one for x86 or is that something going on between the Org and Sun Microsystems? Some typos in my response apologies only human still! Would or could you recommend that the version I have: apache 2.0.63 be able to work with the jk_mod current connector module? I provide the output of 2.0.63 so that you may be able to see whether or not, compiling the mod_jk source against it would work. Or do I have to do something else like for example download another huge package to compile it with. This is an Org and I recognise that so I keep in the frame of mind that if someone helps me then the favor is returned further down the line (I call this ethics and nice manners) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk gmake recursion error on solaris 10 x86
ChrisS wrote: Rainer Jung wrote: Unfortunately I have some difficulties to understand, what you want to tell me: Ok Rainer that solves that one, I do have a built in Apache Solaris 10 What solves what? dist this is: bash-3.00# /usr/apache2/bin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c bash-3.00# /usr/apache2/bin/httpd -v Server version: Apache/2.0.63 Server built: Feb 5 2008 11:13:45 bash-3.00# Please recommend! almost forgot thanks helluvalot. Not sure, what you mean by recommend? I was suggesting 2.2.x, you have a 2.0.x. That's not exactly the same :) Quite possible, that it's more important for you to use a Solaris bundled httpd instead of a self build one. If that is a wise decision depends on the importance Apache httpd has for you. If it is really important, I would not necessarily rely on the OS delivering company to provide needed updates in time. Would this config suffice mate!!! I don't get this, it's a question with exclamation marks, hm ps I really wanted to get this sorted for a mate in work, we have a clustered setup not clustering between Tomcat nodes on a 1.3.39 setup, there are also session sharing issues with deployed apps, the idea was to lab the problem and try to find a resolve. Aha, so then it makes sense to use the same versions, you also have in production. I would need to check the SSL status exactly but this is running/serving SSL requests on a Sparc SunBlaze server. Would the binary dist of mod_jk (current) work with this environment ? this being a great deal saner than this one I am using Which binary dist? The one from the ASF download page? Yes, that one will need an EAPI httpd, i.e. one build with ssl support. Will this be saner? Not sure. Our binary dist is build with gcc and the httpd we are talking about might be build with Sun Studio (not sure, if we are talking about yet another httpd). Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The binary distribution referred to is mod_jk, I remember seeing one in the mirrors for a Sparc installation only! isn't there one for x86 or is that something going on between the Org and Sun Microsystems? Some typos in my response apologies only human still! Would or could you recommend that the version I have: apache 2.0.63 be able to work with the jk_mod current connector module? I provide the output of 2.0.63 so that you may be able to see whether or not, compiling the mod_jk source against it would work. Or do I have to do something else like for example download another huge package to compile it with. This is an Org and I recognise that so I keep in the frame of mind that if someone helps me then the favor is returned further down the line (I call this ethics and nice manners) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache 2.0.63 Solaris 10 x86 works! Steps taken: 0. Got loads of help from the guys at users@tomcat.apache.org (thanks guys!) 1. Download Sun Studio 11for x86 and install as su - root. (Refer to www.sun.com for this) 2. Include /opt/SUNWspro/bin in the PATH environment variable (PATH=/opt/SUNWspro:$PATH) 3. Download Tomcat from http://tomcat.apache.org/ i am using 5.5.20.0 as of this writing. Install Tomcat (see http://tomcat.apache.org for this) 4. svn checkout tomcatconnectors JK 1.2.26 refer to (google, http://tomcat.apache.org, etc ... for this) Subversion(svn) can be downloaded from http://www.sunfreeware.com. Apparently this release of mod_jk fixes some session sharing issues amongst other important issues between TomcatNodes(well thats how I read it anyway). Apache ant is required to build this so download that also(and follow instructions for using it). In order to use buildconf.sh you will require. autoconf, automake, autoheader, aclocal, libtoolize these can all be found at www.sunfreeware.com perl is also required. Make sure the fresh installs are referenced from the PATH variable. On my system these live in /usr/local/bin. Also make sure that /usr/sfw/bin isn't referenced in the PATH along with CC= not being set, don't forget to export ;). 5. When everything is set run buildconf.sh check the top_builddir variable in common and apache-2.0 subdirectories this should be: top_builddir = .. (note the spaces I think under common this was: top_builddir=.. this threw an error and took a while to track down) 6. Once step was completed I ran configure against apxs in the desired apache directory e.g. ./configure --with-apxs=/usr/apache2/bin/apxs This worked! I did try this against apache-1.3.39 dist but to no avail apparently symbol ref
Re: mod_jk gmake recursion error on solaris 10 x86
dont send me tomcat hereafter!! - Original Message - From: "Rainer Jung" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, March 06, 2008 5:56 AM Subject: Re: mod_jk gmake recursion error on solaris 10 x86 Hi Chris, ChrisS schrieb: I installed Sun Studio 11 and included it first in the $PATH env variable. This cleaned up the nasty warnings about CC. Then I built it with: gmake and then gmake clean this was also successful. Libtool was then used to pass the mod_jk.so file to its location in this case: /www/apache/libexec I do however have one problem and it is a biggy. LoadModule along with LoadFile(testing) will not load the module into my 1.3.39 dist. The error message thrown is this: ../bin/apachectl start Syntax error on line 237 of /www/apache/conf/httpd.conf: Cannot load /www/connectors/jk/native/apache-1.3/mod_jk.so into server:ld.so.1: libhttpd.ep: fatal: relocation error: file /www/connectors/jk/native/apache-1.3/mod_jk.so: symbol ap_ctx_get: referenced symbol not found ../bin/apachectl start: httpd could not be started The symbol ap_ctx_get, which is missing here is not included in a standard httpd 1.3. It comes with the extended API (EAPI) bundled with mod_ssl. mod_ssl for Apache httpd 1.3 mainly consists of the ssl module and a set of aditional patches for httpd 1.3, which extend the module API, s.t. the more complex ssl functionality fits into the httpd module API. In the following I'll not make a distinction between EAPI and mod_ssl. Maybe the mod_jk.so you are trying to load here is the one on our project download page? Because that one explicitely states in the README, that it has been build against an EAPI enabled httpd. Or you build your mod_jk against an ssl enabled httpd and afterwards try to ue it inside one, which is a plain one. Although mod_jk soesn't really have a dependency on ssl, there is one symbol, ap_default_port, that the patches for mod_ssl redefine (you can imagine, that the default port with ssl depends on the fact, if one uses ssl (443) or not (80)) and thus when mod_jk gets build against an ssl enabled httpd, the resulting mod_jk.so has a single additional dependency, namely ap_ctx_get(). Before trying to fix this reconsider your choice of httpd first. Version 1.3 is now very outdated. The httpd project already officially announced, that they put a very high bar on patches they are going to apply to 1.3. Mainly they'll only fix critical security issues. If I would start with something new today, I would really choose httpd 2.2.x. This will provide you a much more future proof environment. It comed with builtin ssl support, ldap support, a much better reverse proxy, less 64 Bit problems (likely even no 64 Bit problems) and much more. Please could you help me, I have tried compiling the Apache Dist with: ./configure --prefix=/www/apache --enable-module=most --enable-shared=max --enable-rule=SHARED_CORE $ make $ make install Don't know about enable-rule, but it doesn't look wrong. Believing that this would resolve my symbol issue. Symbols are in the table this was shown with: nm /www/apache/bin/httpd but none for ap_ctx_get Yes, because it's a non mod_ssl httpd 1.3. But: nm on mod_jk.so should also show, that mod_jk does *not* want that symbol. Kindest Regards ps Thanks for all the help so far guys!! Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk gmake recursion error on solaris 10 x86
dont send me tomcat hereafter!! - Original Message - From: "ChrisS" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, March 06, 2008 6:57 AM Subject: Re: mod_jk gmake recursion error on solaris 10 x86 Rainer Jung wrote: Unfortunately I have some difficulties to understand, what you want to tell me: Ok Rainer that solves that one, I do have a built in Apache Solaris 10 What solves what? dist this is: bash-3.00# /usr/apache2/bin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c bash-3.00# /usr/apache2/bin/httpd -v Server version: Apache/2.0.63 Server built: Feb 5 2008 11:13:45 bash-3.00# Please recommend! almost forgot thanks helluvalot. Not sure, what you mean by recommend? I was suggesting 2.2.x, you have a 2.0.x. That's not exactly the same :) Quite possible, that it's more important for you to use a Solaris bundled httpd instead of a self build one. If that is a wise decision depends on the importance Apache httpd has for you. If it is really important, I would not necessarily rely on the OS delivering company to provide needed updates in time. Would this config suffice mate!!! I don't get this, it's a question with exclamation marks, hm ps I really wanted to get this sorted for a mate in work, we have a clustered setup not clustering between Tomcat nodes on a 1.3.39 setup, there are also session sharing issues with deployed apps, the idea was to lab the problem and try to find a resolve. Aha, so then it makes sense to use the same versions, you also have in production. I would need to check the SSL status exactly but this is running/serving SSL requests on a Sparc SunBlaze server. Would the binary dist of mod_jk (current) work with this environment ? this being a great deal saner than this one I am using Which binary dist? The one from the ASF download page? Yes, that one will need an EAPI httpd, i.e. one build with ssl support. Will this be saner? Not sure. Our binary dist is build with gcc and the httpd we are talking about might be build with Sun Studio (not sure, if we are talking about yet another httpd). Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The binary distribution referred to is mod_jk, I remember seeing one in the mirrors for a Sparc installation only! isn't there one for x86 or is that something going on between the Org and Sun Microsystems? Some typos in my response apologies only human still! Would or could you recommend that the version I have: apache 2.0.63 be able to work with the jk_mod current connector module? I provide the output of 2.0.63 so that you may be able to see whether or not, compiling the mod_jk source against it would work. Or do I have to do something else like for example download another huge package to compile it with. This is an Org and I recognise that so I keep in the frame of mind that if someone helps me then the favor is returned further down the line (I call this ethics and nice manners) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
Re: mod_jk gmake recursion error on solaris 10 x86
dont send me tomcat hereafter!! im not a member of t!!!. - Original Message - From: "ChrisS" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Thursday, March 06, 2008 7:57 AM Subject: Re: mod_jk gmake recursion error on solaris 10 x86 ChrisS wrote: Rainer Jung wrote: Unfortunately I have some difficulties to understand, what you want to tell me: Ok Rainer that solves that one, I do have a built in Apache Solaris 10 What solves what? dist this is: bash-3.00# /usr/apache2/bin/httpd -l Compiled in modules: core.c prefork.c http_core.c mod_so.c bash-3.00# /usr/apache2/bin/httpd -v Server version: Apache/2.0.63 Server built: Feb 5 2008 11:13:45 bash-3.00# Please recommend! almost forgot thanks helluvalot. Not sure, what you mean by recommend? I was suggesting 2.2.x, you have a 2.0.x. That's not exactly the same :) Quite possible, that it's more important for you to use a Solaris bundled httpd instead of a self build one. If that is a wise decision depends on the importance Apache httpd has for you. If it is really important, I would not necessarily rely on the OS delivering company to provide needed updates in time. Would this config suffice mate!!! I don't get this, it's a question with exclamation marks, hm ps I really wanted to get this sorted for a mate in work, we have a clustered setup not clustering between Tomcat nodes on a 1.3.39 setup, there are also session sharing issues with deployed apps, the idea was to lab the problem and try to find a resolve. Aha, so then it makes sense to use the same versions, you also have in production. I would need to check the SSL status exactly but this is running/serving SSL requests on a Sparc SunBlaze server. Would the binary dist of mod_jk (current) work with this environment ? this being a great deal saner than this one I am using Which binary dist? The one from the ASF download page? Yes, that one will need an EAPI httpd, i.e. one build with ssl support. Will this be saner? Not sure. Our binary dist is build with gcc and the httpd we are talking about might be build with Sun Studio (not sure, if we are talking about yet another httpd). Regards, Rainer - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] The binary distribution referred to is mod_jk, I remember seeing one in the mirrors for a Sparc installation only! isn't there one for x86 or is that something going on between the Org and Sun Microsystems? Some typos in my response apologies only human still! Would or could you recommend that the version I have: apache 2.0.63 be able to work with the jk_mod current connector module? I provide the output of 2.0.63 so that you may be able to see whether or not, compiling the mod_jk source against it would work. Or do I have to do something else like for example download another huge package to compile it with. This is an Org and I recognise that so I keep in the frame of mind that if someone helps me then the favor is returned further down the line (I call this ethics and nice manners) - To start a new topic, e-mail: users@tomcat.apache.org To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED] Apache 2.0.63 Solaris 10 x86 works! Steps taken: 0. Got loads of help from the guys at users@tomcat.apache.org (thanks guys!) 1. Download Sun Studio 11for x86 and install as su - root. (Refer to www.sun.com for this) 2. Include /opt/SUNWspro/bin in the PATH environment variable (PATH=/opt/SUNWspro:$PATH) 3. Download Tomcat from http://tomcat.apache.org/ i am using 5.5.20.0 as of this writing. Install Tomcat (see http://tomcat.apache.org for this) 4. svn checkout tomcatconnectors JK 1.2.26 refer to (google, http://tomcat.apache.org, etc ... for this) Subversion(svn) can be downloaded from http://www.sunfreeware.com. Apparently this release of mod_jk fixes some session sharing issues amongst other important issues between TomcatNodes(well thats how I read it anyway). Apache ant is required to build this so download that also(and follow instructions for using it). In order to use buildconf.sh you will require. autoconf, automake, autoheader, aclocal, libtoolize these can all be found at www.sunfreeware.com perl is also required. Make sure the fresh installs are referenced from the PATH variable. On my system these live in /usr/local/bin. Also make sure that /usr/sfw/bin isn't referenced in the PATH along with CC= not being set, don't forget to export ;). 5. When everything is set run buildconf.sh check the top_builddir variable in common and apache-2.0 subdirectories this should be: top_builddir = .. (note the spaces I think under c
Re: mod_jk gmake recursion error on solaris 10 x86
favor is returned? I guess there's a first time for everything.. ap_ctx_get is a mod_ssl function which can be downloaded at http://www.modssl.org #install as LoadModule in $APACHE_HOME/conf/httpd.conf e.g. #Also make sure you have the correct mod_ssl.so for your Operating System! LoadModule ssl_module modules/mod_ssl.so # addional configurations can be configured via /conf/ssl.conf # Bring in additional module-specific configurations # Include conf/ssl.conf #check out this ssl.conf sample from Matt Raible http://www.raibledesigns.com/tomcat/ssl.conf Martin- - Original Message - From: "ChrisS" <[EMAIL PROTECTED]> To: "Tomcat Users List" Sent: Wednesday, March 05, 2008 9:27 PM Subject: Re: mod_jk gmake recursion error on solaris 10 x86 > ChrisS wrote: > > Rainer Jung wrote: > >> Unfortunately I have some difficulties to understand, what you want > >> to tell me: > >> > >>> Ok Rainer that solves that one, I do have a built in Apache Solaris 10 > >> > >> What solves what? > >> > >>> dist this is: > >>> > >>> bash-3.00# /usr/apache2/bin/httpd -l > >>> Compiled in modules: > >>> core.c > >>> prefork.c > >>> http_core.c > >>> mod_so.c > >>> bash-3.00# /usr/apache2/bin/httpd -v > >>> Server version: Apache/2.0.63 > >>> Server built: Feb 5 2008 11:13:45 > >>> bash-3.00# > >>> > >>> Please recommend! almost forgot thanks helluvalot. > >> > >> Not sure, what you mean by recommend? I was suggesting 2.2.x, you > >> have a 2.0.x. That's not exactly the same :) Quite possible, that > >> it's more important for you to use a Solaris bundled httpd instead of > >> a self build one. If that is a wise decision depends on the > >> importance Apache httpd has for you. If it is really important, I > >> would not necessarily rely on the OS delivering company to provide > >> needed updates in time. > >> > >>> Would this config suffice mate!!! > >> > >> I don't get this, it's a question with exclamation marks, hm > >> > >>> ps I really wanted to get this sorted for a mate in work, we have a > >>> clustered setup not clustering between Tomcat nodes on a 1.3.39 > >>> setup, there are also session sharing issues with deployed apps, the > >>> idea was to lab the problem and try to find a resolve. > >> > >> Aha, so then it makes sense to use the same versions, you also have > >> in production. > >> > >>> I would need to check the SSL status exactly but this is > >>> running/serving SSL requests on a Sparc SunBlaze server. Would the > >>> binary dist of mod_jk (current) work with this environment ? this > >>> being a great deal saner than this one I am using > >> > >> Which binary dist? The one from the ASF download page? Yes, that one > >> will need an EAPI httpd, i.e. one build with ssl support. > >> > >> Will this be saner? Not sure. Our binary dist is build with gcc and > >> the httpd we are talking about might be build with Sun Studio (not > >> sure, if we are talking about yet another httpd). > >> > >> Regards, > >> > >> Rainer > >> > >> - > >> To start a new topic, e-mail: users@tomcat.apache.org > >> To unsubscribe, e-mail: [EMAIL PROTECTED] > >> For additional commands, e-mail: [EMAIL PROTECTED] > >> > >> > > The binary distribution referred to is mod_jk, I remember seeing one > > in the mirrors for a Sparc installation only! isn't there one for x86 > > or is that something going on between the Org and Sun Microsystems? > > Some typos in my response apologies only human still! > > > > Would or could you recommend that the version I have: apache 2.0.63 be > > able to work with the jk_mod current connector module? I provide the > > output of 2.0.63 so that you may be able to see whether or not, > > compiling the mod_jk source against it would work. Or do I have to do > > something else like for example download another huge package to > > compile it with. > > > > This is an Org and I recognise that so I keep in the frame of mind > > that if someone helps me then the favor is returned further down the > > line (I call this ethics and nice manners) > > > > - >
