2008/3/19, Andrew Hood <ajhood@xxxxxxxxx>:
Peter Johansson wrote:
> 2008/3/19, Bill Meier <wmeier@xxxxxxxxxxx <mailto:wmeier@xxxxxxxxxxx>>:
>
> Guy Harris wrote:
> >
> > If it's not already exported, perhaps the libsmi developers weren't
> > aware of the wonderful "feature" of the Windows development
> > environment wherein a library uses the version of the C runtime
> > library with which it's built rather than the version with which the
> > application using the library was built; that's a rather alien notion
> > to most if not all UN*X developers, and I suspect the libsmi
> > developers started on some UN*X.
They don't really do Windows at all. The Windows version they provide is
compiled with mingw32, and doesn't create a DLL.
> nicely stated !
>
> >
> > If so, yes, we should probably mention that to them, e.g. on the
> > libsmi list.
> >
> > (While we're at it, we should probably also mention to them that:
> >
> > 1) there's an smi_render man page:
> >
> >
> http://www.ibr.cs.tu-bs.de/cgi-bin/dwww?type=man&location=/usr/local/man/man3/smi_render.3
> <http://www.ibr.cs.tu-bs.de/cgi-bin/dwww?type=man&location=/usr/local/man/man3/smi_render.3>
> >
> > but there's no link to it in the sidebar on the libsmi
> home page:
> >
> > http://www.ibr.cs.tu-bs.de/projects/libsmi/
> >
> > 2) that page doesn't indicate that the strings returned by those
> > routines are mallocated.)
>
>
> A quick look at the last several messages on the list indicates that
> there's been recent changes related to compiling on Windows.
>
> I'll read thru the messages tomorrow and
> provide some comments/suggestions as appropriate and as per the above.
>
>
> Is it really a good idea to apply the patch where the free(...) calls
> are disabled on Windows?
> The official Wireshark releases for Windows are compiled and linked
> using the same version of MS VC as libsmi was built with (VC6), right?
> Hence this problem *only* affect developers such as myself that use a
> compiler other than MS VC6 on Windows.
> The official releases however will work fine without the proposed patch.
> Since the current code base works and will continue to work even after
> 1.0 for offical releases we have "all the time in the world" to apply a
> long term solution instead. Even if it gets applied after 1.0 has been
> released.
>
> I would like to see a long term solution where we are able to compile
> every single library using any of the supported tool-chains that is at
> every individual developer's hand. This means that makefiles are
> required (unless anyone sees another solution). I do understand the
> trouble of providing this though. I have tried to compile version 0.4.5,
> 0.4.6 and 0.4.7 of libsmi. Neither compiles "out of the box". 0.4.5 is
> the only candidate that has a chance of compiling on Windows without
> changing the libsmi source code.
There has been some recent discussion of MSVC compiling on the libsmi
mailing list.
libsmi SVN HEAD cross compiles with "LDFLAGS=-lrxspencer" but just about
any other regex libs should work. A later version of mingw32 might not
need this but mine does.
It also compiles with MSVC8 with a small patch.
I will send the attached patch for both of these to Frank and Juergen
for inclusion.
> 0.4.6 and 0.4.7 however contain
> includes of Unix-specific header files.
Are any of them in the lib/ directory or just in tools/ ? Wireshark
doesn't use tools/.
The makefile suggested the other day to create smi.dll does not work for
me with MSVC8.
> I thought I should address this
> with the swedes that maintain libsmi but have not got around to it yet.
Swedes? From the names I would guess Frank Strauss, Juergen
Schoenwaelder and many of the other contributors are German or Austrian.
I'm not Swedish either.
My bad. I found information on a KTH based server (KTH is a university in Sweden) that there were swedes (neither Frank Strauss nor Juergen Schoenwaelder) that handled some of the development and maintenance of libsmi. But you are most certainly correct, guess I will not contact these swedes since the original site is at
http://www.ibr.cs.tu-bs.de/projects/libsmi/ (Germany).
Still, (as I said earlier) I feel that it is not a good idea to go with the patch that has been applied to oids.c since this will make all Windows based versions to leak allocated memory. This should not have to be an issue for users of the officially released binaries (1.0 for instance). It need only affect the Windows based developers that do not have MS VC6 at hand until a long term solution has been applied.
/ Peter
