> "w" == wqs <[EMAIL PROTECTED]> writes:
w> net-snmp-5.4.1.tar.gz
w> centos4.3
w> When I unpacked the package,"./configure" ,"make" and I got an error below:
w> /usr/bin/ld: cannot find -lelf
w> collect2: ld returned 1 exit status
w> make[1]: *** [snmpd] Error 1
w> make[1]: Leaving directory
net-snmp-5.4.1.tar.gz
centos4.3
When I unpacked the package,"./configure" ,"make" and I got an error below:
/usr/bin/ld: cannot find -lelf
collect2: ld returned 1 exit status
make[1]: *** [snmpd] Error 1
make[1]: Leaving directory `/home/software/net-snmp-5.4.1/agent'
make: *** [subdirs] Erro
> "skk" == shwth k kk writes:
skk> we are storing in a global variable array that is indexed by the
skk> transaction Id.So, the array is not getting overwritten. Also were
skk> setting requests->delegated = 0;
skk> before calling snmp_set_var_typed_value function.
Well... Then I'm not sure
On Mon, 15 Oct 2007 14:42:40 -0600 Bill wrote:
BF> For years, I've crawled over Internet-Drafts and RFCs to find things
BF> that look like MIB modules, to construct my set of pages at
BF> http://www.icir.org/fenner/mibs/ .
And I've had your site bookmarked for years. Thanks!
BF> - Would it be use
On Mon, 15 Oct 2007 22:19:45 +0200 Magnus wrote:
MF> > First of all, the code you provided suffers from exactly the same
problem. A
MF> > failure in later inserts still (potentially) leaves the item in previous
MF> > containers.
MF>
MF> Could you please educate me as to how?
Sorry, you are right
Dave Shield wrote:
> We've agreed to not fix a bug, because of a concern that the fix is likely
> to have greater impact than the bug itself.
>That's a judgement call, and may turn out to be the wrong decision.
> But it's not an unreasonable position to take.
Exactly. (And I still feel confide
On 16/10/2007, Wes Hardaker <[EMAIL PROTECTED]> wrote:
> But do realize we've just voted to not fix a bug in previous releases.
> It's not a new feature. It fixes the usability of a library.
We've agreed to not fix a bug, because of a concern that the fix is likely
to have greater impact than the
Wes Hardaker wrote:
> I did add a note saying this is only true if using the standard engineID
> generator.
I'd prefer to say "default" rather than "standard" because in fact it's
a net-snmp "proprietary" mechanism. :-)
SCNR,
+Thomas
--
Thomas Anders (thomas.anders at blue-cable.de)
-
