# Opaque type in plugin **URL:** \ **Category:** Development\ **Tags:** development\ **Created:** [April 28, 2016, 6:18pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128 "2016-04-28T18:18:52Z")\ **Posts on this page:** 8\ **Page:** 1
**Author:** ![Jan](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@Jan](https://community.zeek.org/u/Jan)\ **Post date:** [April 28, 2016, 6:18pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/1 "2016-04-28T18:18:52Z")
Hi, just a quick question: Is it possible to create a new opaque type for Bro using a dynamic plugin without touching Bro sources? Best regards, Jan ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [April 28, 2016, 6:49pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/2 "2016-04-28T18:49:05Z")
Yes, it should. I believe if you implement the logic in your plugin's InitPreScript() method, it should work. Robin ---
**Author:** ![Jan](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@Jan](https://community.zeek.org/u/Jan)\ **Post date:** [May 2, 2016, 1:39pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/3 "2016-05-02T13:39:35Z")
> > Is it possible to create a new opaque type for Bro using a dynamic > > plugin without touching Bro sources? > > Yes, it should. I believe if you implement the logic in your plugin's > InitPreScript() method, it should work. Meanwhile I gave it a try: I implemented a class inheriting from OpaqueVal and declared a global OpaqueType variable as extern. I initialized the type variable inside InitPreScript(). That compiled just fine but executing Bro failed due to dynamic linking issues ([c++ - What happens to global and static variables in a shared library when it is dynamically linked? - Stack Overflow](http://stackoverflow.com/questions/19373061) seems to explain that). I circumvented this issue by using a static variable (= limited scope) that I initialized in place. This went well and the new opaque value seems to behave as expected. However, I wonder if I am missing anything that might cause problems? One thing I am aware of is that I did not declare the value type as serializable. I think that is not needed for my use case. Besides it would require to define a corresponding identifier (see SerialTypes.h), whose uniqueness cannot be guaranteed for a plugin, right? Best regards Jan ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [May 2, 2016, 2:51pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/4 "2016-05-02T14:51:18Z")
> that I initialized in place. This went well and the new opaque value > seems to behave as expected. However, I wonder if I am missing anything > that might cause problems? Mind sharing your code (both before/after the change, and also the error message you got)? > One thing I am aware of is that I did not declare the value type as > serializable. Yeah, fine as long as you don't try to send it around or store on disk. > Besides it would require to define a corresponding identifier (see > SerialTypes.h), whose uniqueness cannot be guaranteed for a plugin, > right? Yeah, good point, there's no mechanism for that. Robin ---
**Author:** ![Jan](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@Jan](https://community.zeek.org/u/Jan)\ **Post date:** [May 2, 2016, 5:01pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/5 "2016-05-02T17:01:34Z")
> > that I initialized in place. This went well and the new opaque value > > seems to behave as expected. However, I wonder if I am missing anything > > that might cause problems? > > Mind sharing your code (both before/after the change, and also the > error message you got)? Sure. The code is available at [https://github.com/J-Gras/bro-plugins/tree/topic/jgras/liblognorm/liblognorm](https://github.com/J-Gras/bro-plugins/tree/topic/jgras/liblognorm/liblognorm). Unfortunately I don't have commits for both versions but the changes are minimal. The relevant files are src/LogNormalizer\*. Currently LogNormalizer.cc:11 declares the type using static. That seems to work (as it is local). If I remove "static" and use the "extern" declaration commented in LogNormalizer.h:78 (like its done in Bro), loading the plugin fails with: fatal error in /home/jgras/devel/bro/scripts/base/init-bare.bro, line 1: cannot load plugin library /home/jgras/devel/bro/aux/plugins/liblognorm/build//lib/Bro-Lognorm.linux-x86\_64.so: /home/jgras/devel/bro/aux/plugins/liblognorm/build//lib/Bro-Lognorm.linux-x86\_64.so: undefined symbol: \_ZN6plugin11Bro\_Lognorm18lognormalizer\_typeE > From what I understand this is expected as a dynamically linked global variable would need special treatment. But as I am not used to C++ and my understanding of Bro's type system is limited, I am not sure I missed important details in my solution. Best regards, Jan ---
**Author:** ![robin](https://yyz1.discourse-cdn.com/flex011/user_avatar/community.zeek.org/robin/32/599_2.png) [@robin](https://community.zeek.org/u/robin)\ **Post date:** [May 6, 2016, 3:30pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/6 "2016-05-06T15:30:22Z")
Took me a bit to look at this, but I've tried it now. My guess is that it was a namespace issue. Look at the attached patch, that version works for me. That said, your version using "static" is completely fine. Indeed, it's even the better one for the plugin case: defining it globally non-static is useful only if other object files need to access it. Inside your plugin, that's not the case; and outside the plugin nobody can (because nobody can rely on the plugin being present). So I think your solution is just fine. Good to see you got the type working from a plugin. Would be even nicer if Bro actually showed the new type in the output of "-NN" but we don't have the support in place yet for a plugin to register it accordingly. Robin [jan](https://community.zeek.org/uploads/short-url/pWnk2wjHCLvMiazo6f8KCCzChTl) (859 Bytes) ---
**Author:** ![Jan](https://avatars.discourse-cdn.com/v4/letter/j/ce7236/32.png) [@Jan](https://community.zeek.org/u/Jan)\ **Post date:** [May 6, 2016, 10:39pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/7 "2016-05-06T22:39:54Z")
> Took me a bit to look at this, but I've tried it now. My guess is that > it was a namespace issue. Look at the attached patch, that version > works for me. Thanks a lot for taking a look! I missed that "using" does not do the trick for a definition. I guess its time to read a C++ book 🙂 > That said, your version using "static" is completely fine. Indeed, > it's even the better one for the plugin case: defining it globally > non-static is useful only if other object files need to access it. > Inside your plugin, that's not the case; and outside the plugin nobody > can (because nobody can rely on the plugin being present). So I think > your solution is just fine. I am happy to hear that this is a proper solution. My fear was that I was missing a mechanism, which announces the type to Bro. My thought was that in this case the limited visibility might become an issue. Big thanks for your support! Jan ---
**Author:** ![system](https://canada1.discourse-cdn.com/flex011/uploads/zeek/original/1X/f09d732bc2cc7c7cc7e35db67cf4e1d5233ce7a7.png) [@system](https://community.zeek.org/u/system)\ **Post date:** [May 6, 2022, 3:43pm UTC](https://community.zeek.org/t/opaque-type-in-plugin/4128/8 "2022-05-06T15:43:38Z")