Hi,

Thanks for the reply.

I am using windows version of libsmi.

I downloaded the latest libsmi(windows version) from the below location and replaced with the old one with new libsmi-0.4.5.zip but the problem still exists.

ftp://ftp.ibr.cs.tu-bs.de/pub/local/libsmi/WIN32/libsmi-0.4.5.zip

Please see the attached two mibs with this email, These two mibs are imported an Unsigned64 object from CISCO-TC MIB.

Thanks, Raghavendra.

-----Original Message----- From: Frank Strauß [mailto:strauss@ibr.cs.tu-bs.de] Sent: Friday, February 02, 2007 9:16 PM To: rakrista@cisco.com Cc: libsmi@ibr.cs.tu-bs.de Subject: Re: [libsmi] Need some help regarding with smidiff.

RAGHAVENDRA KRISTAM wrote:

Hi Libsmi Team,

If any MIB imported an Unsigned64 object from CISCO-TC MIB, no differences are getting even though differences exists when I use smidiff

for two mibs .

In remaining cases smidiff is working fine.

Please let me know how to solve this problem.

Ok, please get a fresh SVN update and try again.

Previously, SMIv2 modules that imported types that match a SPPI base type name have lead to severe errors and parsing has stopped. I've introduced a new level 5 warning for this case, and parsing continues, so that you should see subsequent output of parsers and smidiff results.

If the problem still exists, please send me a pair of files so that I can get a better understanding of the problem.

-frank

PS: Thanks also to Torsten, who investigated this error first and gave some hints regarding the SPPI/SMI conflict.

Frank Strauß wrote:

RAGHAVENDRA KRISTAM wrote:

...

Hi,

Thanks for the reply.

I am using windows version of libsmi.

I downloaded the latest libsmi(windows version) from the below location and replaced with the old one with new libsmi-0.4.5.zip but the problem still exists.

What do you mean by "new libsmi-0.4.5.zip"? Did you build this based from a fresh SVN checkout?

Recent changes are usually only available from the SVN repository. Note also, that I do not support Windows versions. In the past, Juergen has been so kind to prepare Windows packages from time to time, but it's definetely safer and more up to date to use the Subversion repository.

Some parts of SVN will not build with MSVC2005. I can try and "svn diff" but I have some unrelated changes that would make that difficult.

tools/rea.[ch] rename DEBUG to something else like DEBUG_REA

tools/dstring.c needs to include config.h and define va_copy e.g.

-#if !defined va_copy && defined __va_copy -#define va_copy __va_copy /* C99 draft proposal */ +#if !defined va_copy +# if defined __va_copy +# define va_copy __va_copy /* C99 draft proposal */ +# else +# define va_copy(lhs,rhs) (lhs) = (rhs) +# endif

and

tools/dstring.[ch]

you don't seem to be able to do inline functions so thing like this in dstring.h:

+#ifdef HAVE_WIN_H +char* +dstring_str(dstring_t *ds); +#else inline char* dstring_str(dstring_t *ds) { return ds ? ds->str : NULL; } +#endif

and in win/makefile:

-DEFINES = $(DEBUG) +DEFINES = $(DEBUG) /D_CRT_SECURE_NO_DEPRECATE=1

SMIXLATEOBJS = \ - $(TMPDIR)\smixlate.obj + $(TMPDIR)\smixlate.obj \ + $(TMPDIR)\dstring.obj

+smixlate.exe: $(SMIXLATEOBJS) $(SMILIB) + $(cc32) $(DEFINES) \ + /osmixlate.exe $(SMIXLATEOBJS) $(SMILIB) +

Juergen Schoenwaelder wrote:

On Tue, Feb 06, 2007 at 09:51:24PM +1100, Andrew Hood wrote:

...

Some parts of SVN will not build with MSVC2005. I can try and "svn diff" but I have some unrelated changes that would make that difficult.

[...]

I tried to convert your message into a diff which I have checked into the SVN. Let us know if more changes are needed to make a build using MSVC2005 work.

Sorry Juergen, I wasn't thinking you'd take me literally. It was intended as an outline of the process. I'll pull a clean SVN tree (without my custom code) and give you a proper diff.

On Thu, Feb 08, 2007 at 07:29:25AM +1100, Andrew Hood wrote:

The attached diff lets SVN compile with MSVC2005. It might break builds with other tool chains.

Thanks. I have applied the patches to the .c and .h files (although I changed some of them - please check that things still work for you).

I did not update the makefile itself since most changes seem to reflect local preferences. But since I never use the makefile nor the README, I am happy to checkin whatever people who build on Windows using native tools agree on. (So far, I only cross-compiled binaries using the GNU tool chain.)

/js

On Sun, Feb 11, 2007 at 11:45:29PM +1100, Andrew Hood wrote:

New patch against 6570. There seems to be no reason to have the duplicate function definitions which upset the compiler. I got the inline to work and dropped those two functions from dstring.c since there should be no excuse for not inlining such simple functions.

Indeed they could probably be made macros.

#define dstring_str(ds) (ds ? ds->str : NULL) #define dstring_len(ds) (ds ? ds->len : 0)

Since the introduction of inline in C99, I tend to dislike macros (even though I agree that this is perhaps simple enough to qualify).

...

I did not update the makefile itself since most changes seem to reflect local preferences. But since I never use the makefile nor the README, I am happy to checkin whatever people who build on Windows using native tools agree on. (So far, I only cross-compiled binaries using the GNU tool chain.)

Which is why you aren't running into the MSVC "peculiarities".

Yes. I believe there is much more to be done to make things run nicer on Windows, such as reading MIB repository locations from the registry and such things. But I am simply not qualified to so any of this - so the only thing I could manage was to cross compile to help some friends who needed a version running on Win32. I happily accept patches...

/js

RAGHAVENDRA KRISTAM wrote:

Hi LIBSMI Team,

Thank you very much for your support so far.

Could you please let me know incase of any recent updates regarding this.

[If any MIB imported an Unsigned64 object from CISCO-TC MIB, no differences are getting even though differences are exists when I do smidiff for two mibs ]

The problem has been fixed three weeks ago when you sent your first mail regarding this bug. Again, thanks for that hint!

Your inputs are highly appreciated as this is very critical to us at this point.

Dicide yourself, how critical this is to you, and decide whether it's worth the time to spend for using simply a Linux system along with the "supported" libsmi code base. You'll never know, how long it will take from a fix in the code base until the next Windows package gets bundled (or whether it will happen at all).