The build script switches from gcc to cc while making the snmp_common modules, and then fails: "mibs-ietf/nsm-mib.c", line 298: undefined symbol: __FUNCTION__ cc: acomp failed for mibs-ietf/nsm-mib.c apxs:Error: Command failed with rc=65536 . make[1]: *** [libsnmpmonagt.so] Error 1 make[1]: Leaving directory `/tmp/product_connectors/apache-snmp/sources/snmp2.0/src' make: *** [all] Error 2 Examples of the mixed compilers from a failed build log: /var/apache2/build/libtool --silent --mode=compile /opt/SUNWspro/bin/cc <snip>mibs-ietf/nsm-mib.slo /bin/sh ../../libtool --mode=compile gcc <snip> module-cmd-table.lo The common Support answer to this is to unset CC, but would be better if the script could be modified to account for this.
Attaching 2.0_log, from customer case https://enterprise.redhat.com/issue-tracker/284949
Possible something along the lines of: unset CC unset CFLAGS unset LDFLAGS PATH=/usr/ccs/bin:/usr/bin:/bin:/usr/sbin:/sbin:/opt/SUNWspro/bin; export PATH
Ok, I've figured this out (I think) and it's not the build_apache_snmp.sh script. It's the configure script for snmp_common/ucd-snmp. Here it's testing for Solaris machines for cc in the path, so that it can throw an error asking the user to run configure --with-cc=gcc: for ac_dir in $ac_dummy; do test -z "$ac_dir" && ac_dir=. if test -f $ac_dir/$ac_word; then if test "$ac_dir/$ac_word" = "/usr/ucb/cc"; then ac_prog_rejected=yes However, this user has cc in /opt/SUNWspro/bin/ , so the test fails (and then the make) I would think that it would make more sense to do something like checking for cc in the user's path, but we didn't write net-snmp :) Now to figure out how to fix this in our build script. I assume it would be yea simple to just add the --with-cc=gcc to it, like so: cd snmp_common/ucd-snmp ${MAKE} clean >/dev/null 2>&1 CFLAGS=${CFLAGS} \ ./configure --with-cc=gcc...
Also curious why we do a prepare for everything except ucd-snmp: echo "Preparing sdbm..." echo "Preparing smi..." echo "Preparing Apache ${VERSION}. Not sure if that is exactly relevant to this problem, since it's the config evaluation that fails in the first place...
On a fresh, full solaris 10 install, this is failing, not surprising due to Sun's cc lacking some compile features. However, I've created an entire build environment with SFW/GNU packages, in /usr/local, and put /usr/local/bin first in my path. PATH=/usr/local/bin:/bin:/sbin:/usr/bin:/usr/sbin SFW packages: autoconf-2.63-sol10-x86-local.gz automake-1.10.2-sol10-x86-local.gz make-3.81-sol10-x86-local.gz libtool-1.5.24-sol10-x86-local.gz gcc-3.4.6-sol10-x86-local.gz binutils-2.19-sol10-x86-local.gz coreutils-7.1-sol10-x86-local.gz perl-5.8.8-sol10-x86-local.gz m4-1.4.12-sol10-x86-local.gz libsigsegv-2.6-sol10-x86-local.gz zlib-1.2.3-sol10-x86-local.gz gmp-4.2.1-sol10-x86-local.gz guile-1.8.5-sol10-x86-local.gz libiconv-1.11-sol10-x86-local.gz db-4.2.52.NC-sol10-intel-local.gz libintl-3.4.0-sol10-x86-local.gz readline-5.2-sol10-x86-local.gz ncurses-5.6-sol10-x86-local.gz /usr/apache2/bin/httpd -V bash-3.00# /usr/apache2/bin/httpd -V Server version: Apache/2.0.63 Server built: Jan 24 2009 07:36:42 Server's Module Magic Number: 20020903:13 Server loaded: APR 0.9.17, APR-UTIL 0.9.15 Compiled using: APR 0.9.17, APR-UTIL 0.9.15 Architecture: 32-bit Server compiled with.... -D APACHE_MPM_DIR="server/mpm/prefork" -D APR_HAS_MMAP -D APR_HAVE_IPV6 (IPv4-mapped addresses enabled) -D APR_USE_FCNTL_SERIALIZE -D APR_USE_PTHREAD_SERIALIZE -D SINGLE_LISTEN_UNSERIALIZED_ACCEPT -D APR_HAS_OTHER_CHILD -D AP_HAVE_RELIABLE_PIPED_LOGS -D HTTPD_ROOT="/usr/apache2" -D SUEXEC_BIN="/usr/apache2/bin/suexec" -D DEFAULT_PIDLOG="/var/run/apache2/httpd.pid" -D DEFAULT_SCOREBOARD="logs/apache_runtime_status" -D DEFAULT_LOCKFILE="/var/run/apache2/accept.lock" -D DEFAULT_ERRORLOG="logs/error_log" -D AP_TYPES_CONFIG_FILE="/etc/apache2/mime.types" -D SERVER_CONFIG_FILE="/etc/apache2/httpd.conf" Build fails with "./build_apache_snmp.sh 2.0 /usr/apache2/bin/apxs: /var/apache2/build/libtool --silent --mode=compile /opt/SUNWspro/bin/cc -prefer-pic -O -xarch=386 -xchip=pentium -xspace -Xa -xildoff -xO4 -DSSL_EXPERIMENTAL -DSSL_ENGINE -DSOLARIS2=10 -D_POSIX_PTHREAD_SEMANTICS -D_REENTRANT -D_LARGEFILE_SOURCE -D_FILE_OFFSET_BITS=64 -I/usr/apache2/include -I/usr/apache2/include -I/usr/apache2/include -I/usr/sfw/include -shared -I. -I. -I/opt/downloads/jon-agent-2.1.2.SP1/product_connectors/apache-snmp/sources/snmp_common/ucd-snmp -I/opt/downloads/jon-agent-2.1.2.SP1/product_connectors/apache-snmp/sources/snmp_common/ucd-snmp/snmplib -I/opt/downloads/jon-agent-2.1.2.SP1/product_connectors/apache-snmp/sources/snmp_common/ucd-snmp/agent -I/opt/downloads/jon-agent-2.1.2.SP1/product_connectors/apache-snmp/sources/snmp_common/sdbm -I/usr/apache2/include -I/usr/share/src/apache2/srclib/apr/include -DUSING_MIBII_SYSORTABLE_MODULE -c -o snmpcommon/snmpv2-tc.lo snmpcommon/snmpv2-tc.c && touch snmpcommon/snmpv2-tc.slo /var/apache2/build/libtool: line 1279: /opt/SUNWspro/bin/cc: No such file or directory apxs:Error: Command failed with rc=65536 . make[1]: *** [libsnmpcommon.so] Error 1 make[1]: Leaving directory `/opt/downloads/jon-agent-2.1.2.SP1/product_connectors/apache-snmp/sources/snmp2.0/src' make: *** [all] Error 2 *"--mode=compile /opt/SUNWspro/bin/cc"* I cannot for the life of me figure out why it all of the sudden calls cc, when the build up to that point has been using GNU GCC...
Attaching latest build log (2.0_log_20090501)
Making critical to make sure it gets triaged
Customer is also getting the exact same error on Solaris 9, so perhaps this is not just a 5.10 issue. We definitely need to document the correct build environment per OS if we're going to ship this script.
From Mladen: I've used RHATews 1.0.0.GA $CC=cc ./build_apache_snmp.sh 2.2 /opt/redhat/ews/sbin/apxs ... Some aclocal warnings, but that OK Done. building sdbm ... building Apache module Attached is the build .log file Here is my env $uname -a SunOS ss10x64m0 5.10 Generic_138889-08 i86pc i386 i86pc $cc -V cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12 usage: cc [ options] files. Use 'cc -flags' for details $automake --version automake (GNU automake) 1.8.3 $autconf --version autoconf (GNU Autoconf) 2.59 Written by David J. MacKenzie and Akim Demaille. $/opt/redhat/ews/httpd/build/libtool --version Copyright (C) 2003 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. ltmain.sh (GNU libtool) 1.5.22 (1.1220.2.365 2005/12/18 22:14:06) You can download the ews binaries from Hudson http://hudson.qa.jboss.com/hudson/job/RHATews-1-solaris10-x86/95/ Note that you'll need a libtool 1.5.22 and install it inside /opt/redhat/ews/httpd/build
Push to 1.4
Well, I found one concrete bug in the script. Under "building Apache module" Bad option --with-netsnmp, should be "--with-net-snmp" ---------------------- <snip> elif [ ${VERSION} = "2.0" ] || [ ${VERSION} = "2.2" ]; then SRC_VERSION=2.0 # We have to run remake_status before building. If we don't, then the build # will fail, because remake_status may not be able to find perl. We solve # this by doing a `which perl` above. cd snmp${SRC_VERSION} echo "XXX MAKING SNMPCOMMON MODULE" ${MAKE} clean >/dev/null 2>&1 SNMP_LDFLAGS=${SNMP_LDFLAGS} CFLAGS=${CFLAGS} \ ./configure \ --with-dynamic-snmp-agt="${APXS}" \ --with-netsnmp="${CWD}/snmp_common/ucd-snmp" \ <--------------- ***should be "--with-net-snmp"*** <snip> ---------------------------
Just noticed something critical in Mladen's comment: "$cc -V cc: Sun C 5.9 SunOS_i386 Patch 124868-01 2007/07/12 usage: cc [ options] files. Use 'cc -flags' for details " For me, cc -V returns: /usr/ucb/cc: language optional software package not installed Perhaps what I'm missing is the Sun Studio Compiler (/opt/SUNWspro/bin/cc)? If that file is missing the build fails every time with "file not found" error of some sort. Setting CC=gcc gets you further, but one way or another, during the module build the script will error out. If you're using the SUN-supplied libtool in /usr/apache2/build, it wants the SUNWspro compiler, which I don't have. I've been getting around that by trying to swap in gcc, but that makes the SUN/Apache libtool angry. I need to try this with SunStudio installed to see if I can get it to work with a unified SUN compiler environment, but it's late and my VBox/Solaris10 test box just locked up on me, so I'll try this tomorrow.
Mark, I checked in the --with-netsnmp fix - JON r10528.
Success! I was finally able to get this to compile! This was using GNU gcc, I'm testing a build with CC=cc now. Environment: SunOS istaru.sol 5.10 Generic_141415-08 i86pc i386 i86pc gcc version... Reading specs from /usr/sfw/lib/gcc/i386-pc-solaris2.10/3.4.3/specs Configured with: /builds/sfw10-gate/usr/src/cmd/gcc/gcc-3.4.3/configure --prefix=/usr/sfw --with-as=/usr/sfw/bin/gas --with-gnu-as --with-ld=/usr/ccs/bin/ld --without-gnu-ld --enable-languages=c,c++ --enable-shared Thread model: posix gcc version 3.4.3 (csl-sol210-3_4-branch+sol_rpath) Sun Studio 12u1, installed in /opt/sunstudio12.1 with /opt/SUNWspro symlinked to it. PATH=/sbin:/usr/sbin:/bin:/usr/bin:/opt/sunstudio12.1/prod/bin:/opt/sunstudio12.1/bin:/opt/SUNWspro/bin:/opt/SUNWspro/sbin:/opt/sfw/bin:/usr/sfw/bin:/opt/sfw/sbin:/usr/sfw/sbin:/usr/ccs/bin:/usr/openwin/bin:/usr/ucb:/usr/xpg4/bin:/usr/local/bin /usr/ccs/bin/ar Software Generation Utilities (SGU) Solaris-ELF (4.0) /usr/ccs/bin/ld Solaris Link Editors: 5.10-1.493 /opt/sfw/bin/libtool (GNU libtool) 1.5.2 (1.1220.2.60 2004/01/25 12:25:08) /opt/sunstudio12.1/prod/bin/cc Sun C 5.10 SunOS_i386 2009/06/03 /opt/sunstudio12.1/prod/bin/CC Sun C++ 5.10 SunOS_i386 2009/06/03 /usr/sfw/bin/gcc (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) /usr/sfw/bin/g++ (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) /usr/sfw/bin/c++ (GCC) 3.4.3 (csl-sol210-3_4-branch+sol_rpath) /opt/sfw/bin/autoconf autoconf (GNU Autoconf) 2.59 /opt/sfw/bin/automake (GNU automake) 1.8.3 /bin/perl v5.8.4 built for i86pc-solaris-64int /bin/sed /bin/awk /usr/ccs/bin/ranlib /usr/ccs/bin/strip /usr/ccs/bin/make /usr/apache2/bin/httpd -V... Server version: Apache/2.0.63 Server built: Jan 24 2009 07:36:42 Server's Module Magic Number: 20020903:13 Server loaded: APR 0.9.17, APR-UTIL 0.9.15 Compiled using: APR 0.9.17, APR-UTIL 0.9.15 Architecture: 32-bit
I was also able to build using CC=cc with the exact same environment as above.
And it works! (module compiled with CC=cc) [Fri Aug 14 14:35:10 2009] [notice] Digest: generating secret for digest authentication ... [Fri Aug 14 14:35:10 2009] [notice] Digest: done [Fri Aug 14 14:35:11 2009] [notice] SNMP: CovalentSNMP/2.3.0 started (user '0' - SNMP address '1610' - pid '19004') [Fri Aug 14 14:35:11 2009] [notice] Apache/2.0.63 (Unix) DAV/2 CovalentSNMP/2.3.0 configured -- resuming normal operations RT logging also appears to be working, log is being populated.
Attaching SNMP modules, RT module, and 2.0_log from the CC=cc build.
This bug was previously known as http://jira.rhq-project.org/browse/RHQ-1979 Imported an attachment (id=368716) Imported an attachment (id=368717) Imported an attachment (id=368718)
Temporarily adding the keyword "SubBug" so we can be sure we have accounted for all the bugs. keyword: new = Tracking + FutureFeature + SubBug
making sure we're not missing any bugs in rhq_triage
The --with-net-snmp vs --with-netsnmp commit from comment 13 seems to be a critical change, as with --with-netsnmp allows to compile on RHEL 5
r10793 adds a switch for Solaris that defaults to the RHEL behaviour