2008/3/19, Bill Meier <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.
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
>
> 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. 0.4.6 and 0.4.7 however contain includes of Unix-specific header files. I thought I should address this with the swedes that maintain libsmi but have not got around to it yet.
Summary:
For the 1.0 release, I believe that we should not apply the proposed patch since it will cause memory leakage on all platforms that the official Wireshark binaries are released for.
As a long term solution I would like to see that it is possible to build the source code for libsmi (and ADNS) as well as the other libraries using any of the supported tool-chains.
Comments?
/ Regards, Peter
