[ net-snmp-Bugs-864560 ] does not build properly in path w/spaces

[SourceForge.net <noreply@so...>]

Bugs item #864560, was opened at 2003-12-22 18:35
Message generated for change (Comment added) made by dts12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=864560&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: configure
Group: None
>Status: Closed
>Resolution: Fixed
Priority: 3
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
Summary: does not build properly in path w/spaces

Initial Comment:
Attempting to compile net-snmp from a home directory
under a default install of the current version of
cygwin fails due to some of the fully qualified paths
containing the 'Documents and Settings' folder, which,
of course, contains spaces. Moving the home directory
to a path not containing spaces makes the build process
proceed normally. I believe that under older versions
of cugwin, this was not an issue, as home directories
were created under /home/accountname, rather than being
placed in the windows default area of '\Documents and
settings\accountname'.

----------------------------------------------------------------------

>Comment By: Dave Shield (dts12)
Date: 2007-02-24 15:00

Message:
Logged In: YES 
user_id=88893
Originator: NO

libtool upgraded for 5.4.x


----------------------------------------------------------------------

Comment By: Michael J. Slifcak (slif)
Date: 2006-01-14 04:42

Message:
Logged In: YES 
user_id=88697

Keep the bug open.  Known limitations are not always
deficiencies.

Actually upgrading would lead to another round of "it no
longer works for me" kinds of bugs.  People who need this
ability will read this report and are welcomed to comment on
how well the new libtool works for them.  Valuable developer 
resources can then be spent on more fruitful enterprise.



----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2006-01-11 15:58

Message:
Logged In: YES 
user_id=848638

Of course, if it's safe to. :-)

----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2006-01-11 15:47

Message:
Logged In: YES 
user_id=88893

The libtool people have now addressed this problem,
and it should be fixed in libtool 1.5.20 and above.

Should we upgrade?

----------------------------------------------------------------------

Comment By: Michael J. Slifcak (slif)
Date: 2004-06-11 00:03

Message:
Logged In: YES 
user_id=88697

Thank you for providing the compile log.

It seems that  "libtool" cannot resolve pathnames with spaces.



----------------------------------------------------------------------

Comment By: John McCash (johnmccash)
Date: 2004-06-10 22:43

Message:
Logged In: YES 
user_id=936317

Mike,
	A quick test shows that it looks like it's still broken.
Here's a snippet from the end of the build:

libtool: link: warning: undefined symbols not allowed in
i686-pc-cygwin shared libraries
rm -fr .libs/libnetsnmptrapd.la .libs/libnetsnmptrapd.*
.libs/libnetsnmptrapd.*
ar cru .libs/libnetsnmptrapd.a  snmptrapd_handlers.o
snmptrapd_log.o notification_log.o
ranlib .libs/libnetsnmptrapd.a
creating libnetsnmptrapd.la
(cd .libs && rm -f libnetsnmptrapd.la && ln -s
../libnetsnmptrapd.la libnetsnmptrapd.la)
: libnetsnmptrapd.la
/bin/sh ../libtool  --mode=compile gcc -I../include
-I../include -I.. -I./.. -I./../snmplib -I./../agent
-I../agent/helpers -I./../agen
t/mibgroup -g -O2 -Dcygwin  -c -o snmpget.lo snmpget.c
rm -f .libs/snmpget.lo
gcc -I../include -I../include -I.. -I./.. -I./../snmplib
-I./../agent -I../agent/helpers -I./../agent/mibgroup -g -O2
-Dcygwin -c snmpg
et.c  -DDLL_EXPORT -DPIC -o .libs/snmpget.lo
gcc -I../include -I../include -I.. -I./.. -I./../snmplib
-I./../agent -I../agent/helpers -I./../agent/mibgroup -g -O2
-Dcygwin -c snmpg
et.c -o snmpget.o >/dev/null 2>&1
mv -f .libs/snmpget.lo snmpget.lo
/bin/sh ../libtool  --mode=link gcc -o snmpget.exe
snmpget.lo -L../snmplib -L../agent -L../agent/helpers 
../snmplib/libnetsnmp.la  -lc
rypto -lm
libtool: link: cannot find the library `'
make[1]: *** [snmpget.exe] Error 1
make[1]: Leaving directory `/cygdrive/c/Documents and
Settings/jmccash.ANDREW/My
Documents/nedt-snmp/net-snmp-5.1.2.pre1/apps'
make: *** [subdirs] Error 1

The build process was conducted in the following directory:
	/cygdrive/c/Documents and Settings/jmccash.ANDREW/My
Documents/nedt-snmp/net-snmp-5.1.2.pre1

I'm leaving for the weekend now, but I'll be back on Monday
if you need additional testing done.
			Ciao
				John McCash



----------------------------------------------------------------------

Comment By: Michael J. Slifcak (slif)
Date: 2004-06-10 22:14

Message:
Logged In: YES 
user_id=88697

Please download the 5.1.2 version, or one of the 5.1.2
pre-releases, and let us know if we've fixed this problem.

When you respond, please note which compiler and environment
you use:  Microsoft Visual C++ 6 or 7, OR minGW OR cygwin

Thank you,
-Mike Slifcak, for the Net-SNMP project team

----------------------------------------------------------------------

Comment By: Michael J. Slifcak (slif)
Date: 2004-02-14 14:58

Message:
Logged In: YES 
user_id=88697

since the submitter had success after the
directory was changed, the priority is lowered.

There are other bugs addressing this, too.
So, please dont be alarmed.

-Mike Slifcak, Net-SNMP project member

----------------------------------------------------------------------

Comment By: John McCash (johnmccash)
Date: 2003-12-22 18:50

Message:
Logged In: YES 
user_id=936317

Oops, meant to mark these as having been submitted by me
John MCash - john.mccash@...

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=864560&group_id=12694

[ net-snmp-Bugs-711465 ] override directive ignored with snmpbulkget

[SourceForge.net <noreply@so...>]

Bugs item #711465, was opened at 2003-03-28 17:46
Message generated for change (Comment added) made by dts12
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=711465&group_id=12694

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: agent
Group: backport-needed
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: John Lash (jkl)
Assigned to: Dave Shield (dts12)
Summary: override directive ignored with snmpbulkget

Initial Comment:
I noticed that when I disable a mib variable using the
override directive in the config file, I can still
retreive the value using getbulk.

for example:

    override sysDescr.0 octet_str "fubar"   


then, I restart snmpd,  then from another system, I run:

    snmpbulkget -On -Cr5 -cpublic -v2c lab15 sysDescr

and I get back:


.1.3.6.1.2.1.1.1.0 = STRING: Linux lab15 2.4.20 #30 SMP
Tue Mar 18 14:12:02 CST 2003 i686
.1.3.6.1.2.1.1.1.0 = STRING: fubar
.1.3.6.1.2.1.1.1.0 = STRING: fubar
.1.3.6.1.2.1.1.1.0 = STRING: fubar
.1.3.6.1.2.1.1.1.0 = STRING: fubar

Found the problem just a few minutes ago and I hven't
had time to look thru the code yet, I'm also leaving
for some vacation later today. If somebody needs to
contact me, I'll be back on April 6.


----------------------------------------------------------------------

>Comment By: Dave Shield (dts12)
Date: 2007-02-24 13:59

Message:
Logged In: YES 
user_id=88893
Originator: NO

Fix applied to 5.2.x and 5.3.x lines.

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2006-08-14 10:07

Message:
Logged In: YES 
user_id=848638

Are there any objections to commit this to 5.2.x and 5.3.x,
then? It looks strange to fix something in 5.1.x and 5.4.dev
only and not in the branches in between.

----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2006-08-14 09:56

Message:
Logged In: YES 
user_id=88893

As far as I can tell:
    Fixed:  5.1.x, 5.4.dev
    Not:    5.0.x, 5.2.x, 5.3.x

----------------------------------------------------------------------

Comment By: Thomas Anders (tanders)
Date: 2006-08-11 22:00

Message:
Logged In: YES 
user_id=848638

So in what branches has this bug been fixed, finally? MAIN
(5.4-to-be) for sure and 5.1.x not (now EOL anyway), but
what about 5.2.x and 5.3.x?

----------------------------------------------------------------------

Comment By: Robert Story (rstory)
Date: 2006-02-11 00:13

Message:
Logged In: YES 
user_id=76148

Note that the override token has been broken in 5.1.x (including 5.1.2 and
5.1.3). However, I just fixed it for 5.1.4.rc1. This issue is now an issue
for 5.1.4, as well. That is supposed to be scheduled for 3 days from now,
which doesn't leave a whole lot of review for this fix. I've attached the
patch backported to 5.1.4 below...

----------------------------------------------------------------------

Comment By: Robert Story (rstory)
Date: 2006-02-10 23:42

Message:
Logged In: YES 
user_id=76148

Ok, this is gonna be a long one, folks.

Dave, did you test your fix? In my cvs, as of today, the replication of
fubar is fixed, but the first varbind still returns the standard sysDescr,
instead of the overriden one.

There are several issues in play here.

1) The reason that the original sysDescr remains is in the bulk_to_next
handler. If an answer is returned, it unconditionally sets for retry and
then advances to the next variable.

Solution: check for end of range in netsnmp_bulk_to_next_fix_requests. 

2) The reason for the repetions is that, as you discovered, inclusive has
been set.

Solution: revert Dave's patch. Instead, when check_getnext_results
discovers that range has been exceeded, set inclusive to 2 instead of 1. In
 netsnmp_bulk_to_next_fix_requests, if inclusive is 2, reset it to 0 after
moving to the next variable in the request. 

(An alternative that I explored was to check the current varbind agains
the tree end when assigning the tree in the cache, and making sure that the
request index + 1 didn't exceed the tree range end, moving on the the next
tree if that test failed. This worked, but I'm not convinced that it would
work for more complex cases (like table indexes that aren't scalars, or
when there are indexes are non-contiguous)).

These 2 fixes fix the problem, and correctly set the overridden value and
the move on to subsequent values. There might be some interactions with
AgentX, the primary consumer of the inclusive value. We'll cross that
bridge when we come to it.

3) On a related note, both Dave's fix and my above fixes caused an endless
loop when the override was for an object in a table (eg hrStorageDescr.0).
In this case, the problem was that the instance helper used for override
was translating no value (ASN_NULL) and the NOSUCH* returns into
ASN_PRIV_RETRY to trigger a retry (see revisions 5.11 and 5.12 of that
file). However, I don't see how that could be right. RETRY will call the
same handler again. For an *instance*, there is no reason to expect that if
it didn't have data the first time, that it will have data on the next
call.

Solution: The correct value should be ANS_NULL, causing the agent to move
on to the next object in the tree.

The checkins for 5.11 and 5.12 didn't mention a test case, so I don't know
if changing to ANS_NULL breaks something else, but the above test case
(scalar override of sysDescr) and the test case for #3 (object in table)
both work with all 3 of these fixes.

That's all for now!  These fixes will also only be commited to cvs MAIN,
and should be backported if nothing else breaks (or nobody finds a broken
test case, or a better solution; solution for #2, in particular, is a
hack).


----------------------------------------------------------------------

Comment By: Dave Shield (dts12)
Date: 2006-01-10 16:58

Message:
Logged In: YES 
user_id=88893

I've *finally* managed to track down what's triggering
this problem.  It turns out to be the "out of range"
processing in the check_getnext_results routine, which
sets the 'inclusive' flag (erroneously in this case).

I think I've got a fix for this, but I'm by no means
certain of the implications of it.  So for the time being,
I've just applied it to the main CVS development code.
As long as that doesn't throw up any significant problems,
I'll look at back-porting it to the earlier branches in
a week or two.   Then hopefully we can finally nail this
bug once and for all.

----------------------------------------------------------------------

Comment By: John Lash (jkl)
Date: 2003-03-28 18:05

Message:
Logged In: YES 
user_id=40186

oops, version info follows:

: root; snmpd --version

NET-SNMP version:  5.0.7
Web:               http://www.net-snmp.org/
Email:             net-snmp-coders@...


: home; snmpbulkget --version
NET-SNMP version: 5.0.7


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=112694&aid=711465&group_id=12694