Wow. I really appreciate you taking time to experiment with this. Your
results are very enlightening. For now, I'm thinking I'll just copy
the support files to the necessary plugin directories manually before
compilation until I or someone else can figure out a fix for this
issue. It's interesting that it builds correctly in Linux and only
fails like this under Windows. You'd think they'd try to make the
compilation process as similar as possible between OS's. But of course
that's difficult since Windows makefiles are very different from Linux
ones. Do you think this should be counted as a bug?
On Tue, Apr 27, 2010 at 17:39, Maynard, Chris
<Christopher.Maynard@xxxxxxxxx> wrote:
> Well, it looks like the problem is that when the plugins/plugin-common/support_file.c file is compiled, the resulting support_file.obj is saved to plugins/plugin_directory/support_file.obj, so when the linker looks for the object file in the same directory as the source file, it can't find it. At least that's what I've found with a little bit of playing around.
>
> So, now all you need to do is figure out how to either get the .obj to be saved in the same directory as the source file or how to have the linker look in the current directory for it. As a quick test, I added the plugin-common directory to the PLUGIN_LIST of plugins/Makefile.nmake and added a minimal plugins/plugin-common/Makefile.nmake. This was able to produce a support_file.obj in plugins/plugin-common/ that the linker could find, but you still have to add the support_file.c to the DISSECTOR_SUPPORT_SRC, which ends up compiling support_file.c again, placing the support_file.obj in the wrong place and linking to the other one. Pretty ugly. There must be a more elegant way to do this.
>
>
> -----Original Message-----
> From: wireshark-dev-bounces@xxxxxxxxxxxxx [mailto:wireshark-dev-bounces@xxxxxxxxxxxxx] On Behalf Of Jeremy O'Brien
> Sent: Tuesday, April 27, 2010 3:09 PM
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] DISSECTOR_SUPPORT_SRC in another directory in Windows
>
> On Tue, Apr 27, 2010 at 11:27, Maynard, Chris
> <Christopher.Maynard@xxxxxxxxx> wrote:
>> What does your directory structure look like? i.e., is common/ under plugins/ or off the root? It looks to me like Windows is looking for common/ path-relative to your plugin directory so you should have "wireshark/plugins/common/support_file.c". If you want to keep the directory structure as "wireshark/common/", then you might be able to get away with modifying your plugin's Makefile.nmake, specifically adding "../../common/support_file.obj" to your list of OBJECTS or DISSECTOR_SUPPORT_OBJECTS. I think this will work, although it seems like a bit of hack. I'm sure there's a better way to do this but it escapes me at the moment.
>
> My structure is plugins/plugin-common and plugins/plugin_directory. I
> tried setting my DISSECTOR_SUPPORT_SRC to
> "plugins/plugin-common/support_file.c", and
> "../plugin-common/support_file.c" but both still complain. And as for
> modifying DISSECTOR_SUPPORT_OBJECTS, doesn't that macro-thing there
> take care of mapping the .c files to .obj files? What's odd is that
> this code works perfectly fine in linux. And if I modify the
> DISSECTOR_SUPPORT_SRC to point to the same file in the plugin's own
> directory, it works fine. But this defeats the purpose as I have
> several dissectors I want to be able to use this shared code.
>
> CONFIDENTIALITY NOTICE: The contents of this email are confidential
> and for the exclusive use of the intended recipient. If you receive this
> email in error, please delete it from your system immediately and
> notify us either by email, telephone or fax. You should not copy,
> forward, or otherwise disclose the content of the email.
>
> ___________________________________________________________________________
> Sent via: Wireshark-dev mailing list <wireshark-dev@xxxxxxxxxxxxx>
> Archives: http://www.wireshark.org/lists/wireshark-dev
> Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
> mailto:wireshark-dev-request@xxxxxxxxxxxxx?subject=unsubscribe
>