Hi Robert:
Thanks for the reply. The source of this problem was found. It's the
environment set up in my site.
This incidence tells me how important it is to be careful in setting up
the environment variables - especially the critical tools. The program/system
itself may not cause the problem but a conflicted environment setup could cost
some one hours and hours in debugging.
**************** Here is the reason **************
In my project I had source some environment setting created by another
engineer.
One of the environment variables was set as:
AR=/usr/bin/ar -crv
In the net-snmp/configure file it has the following test cases:
test -z "$AR" && AR=ar
test -z "$AR_FLAGS" && AR_FLAGS=cru
Since my environment has the AR variable but no AR_FLAGS so the compiler took
"/usr/bin/ar -crv cru" to build the archive. So the archive file was build but
erased (? I guessed by the dual options "-crv cru"). I was surprised to know
the "ar" actually implemented the options set up as above. To correct it, the
environment variables were changed to
AR=/usr/bin/ar
AR_FLAGS=-crv
The problem went away.
Interesting thing is another engineer in my group also encountered the similar
problem while he installed one C++ library. He learned from me the problem so
he reviewed the environment set up. Pretty soon he found out by commenting out
the AR_FLAGS=-crv. The problem went away. It looks like the different package
has slight different way of use the AR or AR_FLAGS variables which may impact
the real usage in building library archive in individual package. So a
standard way of using some of the critical tools could save time in debugging
problem caused by the conflicted environmental set up.
Thanks,
Jim
The following is the log of the error.
/usr/bin/ar -crv cru .libs/libnetsnmp.a snmp_client.o mib.o parse.o snmp_api.o
snmp.o snmp_auth.o asn1.o md5.o snmp_parse_args.o system.o vacm.o int64.o
read_config.o snmp_debug.o tools.o snmp_logging.o snmpv3.o lcd_time.o
keytools.o scapi.o callback.o default_store.o snmp_alarm.o data_list.o
oid_stash.o mt_support.o snmp_enum.o snmp-tc.o snprintf.o strlcpy.o strtol.o
strtoul.o snmp_transport.o snmpUDPDomain.o snmpTCPDomain.o snmpUnixDomain.o
snmpCallbackDomain.o snmp_secmod.o snmpusm.o snmp_version.o check_varbind.o
container.o container_binary_array.o container_null.o container_list_ssll.o
container_iterator.o cmu_compat.o ucd_compat.o
/usr/bin/ar: .libs/libnetsnmp.a: No such file or directory
make[1]: *** [libnetsnmp.la] Error 1
***********************************
-----Original Message-----
From: Robert Story [mailto:[EMAIL PROTECTED]
Sent: Saturday, April 02, 2005 2:45 AM
To: Jim Su
Cc: Net-Snmp-Users
Subject: Re: weired compilation error
On Wed, 23 Mar 2005 14:56:37 +0800 Jim wrote:
JS> I have encountered some weired compiling problem in building net-snmp.
JS> I checked out the code of my agent (5.0.6) under a brand new path. The
JS> build is successful on one machine but failed on another machine. Both
JS> have the same OS. The error message I got is -
JS> ********************
JS> Entering directory ...... net_snmp/snmplib
JS> ..........
JS> ucd_compat.o /usr/bin/ar: .libs/libnetsnmp.a: No such file or directory
Does 'make clean' from the top level help?
How about 'make distclean' followed by a reconfigure and make?
--
NOTE: messages sent directly to me, instead of the lists, will be deleted
unless they are requests for paid consulting services.
Robert Story; NET-SNMP Junkie
Support: <http://www.net-snmp.org/> <irc://irc.freenode.net/#net-snmp>
Archive: <http://sourceforge.net/mailarchive/forum.php?forum=net-snmp-users>
You are lost in a twisty maze of little standards, all different.
HWj)bh+yNLv-yv'z\jwbv,xnv !3ۜjj[z('! lXzm^*^J֫v)!lgri؝
