Hi, I’m working on a solution, basically moving the plugin.c rule in an intermediate Makefile.am.inc in plugins/epan, plugins/wiretap, plugins/codecs. When it works I’ll push it as a separate change.
Thanks, Jaap > On 19 Jan 2018, at 12:10, João Valverde <[email protected]> > wrote: > > Right, well done on the analysis. The make-plugin-reg.py script wants to be > passed "plugin_wtap" for wiretap. > > On 19-01-2018 08:02, Jaap Keuter wrote: >> On 19-01-18 04:46, João Valverde wrote: >>> If the plugin is loaded I don't see how the build system could have any >>> influence either. >> Hi João, >> That was what puzzled met too... >> I started to dig down further and found that indeed the plugin was loaded >> (obviously) and they are called to register their registration function, as >> provided by the generated plugin.c. >> #1 is the plugin.c file generated in the autotools build, and >> #2 is the plugin.c file generated in the cmake build >> Looking at #1 versus #2 shows that #1 has an empty plugin_register() >> function, >> while #2 has the correct wtap_register_plugin() call. >> plugin.c generation is controlled by the build system, so that is the cause >> of >> the difference between the two. Generation of #1 comes from a generic >> Makefile.am.inc, which is geared to generating 'plugin' (being dissector >> plugin!), while the CMakeLists.txt file calls for generating a 'plugin_wtap'. >> So, the generation of #1 for the other kinds of plugin (!dissector) has to be >> reconsidered. >> Thanks, >> Jaap ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <[email protected]> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:[email protected]?subject=unsubscribe
