I took Magnus' advice and saved the intermediate C files, comparing the one
generated for the C version vs the one for C++. As it turns out, for
whatever reason, the C++ version was missing the call to init_<my_OID>()
SO I added the call where it should be and produced .o's for the
intermediate and cpp, then used g++ to link them. The resulting sub-agent
would run and get into its handle_xxx()/MODE_GET until a C++ library method
threw an exception and the entire thing crashed. It did not even make it
to its defined handler or the catch(...) which leads me to thing that that
is due to mixed mode linkages (nothing relating to net-snmp). Long story
short: this most probably can be resolved but I can't waste any more time
on getting the net-snmp sub-agents to work in a C++ environment. If
someone has a very quick solution I could put some time aside to try it,
but otherwise I'll just restrict my work to C only (ick).
tack själv! Magnus!
On Thu, Oct 3, 2013 at 9:57 PM, Magnus Fromreide <ma...@lysator.liu.se>wrote:
> On Thu, 2013-10-03 at 14:42 -0400, Frozen Puck wrote:
> >
> >
> > I have the most basic, simple starter sub-agent which simply outputs a
> > hard-coded string (for now), which works fine when compiled as a C
> > module:
> > # net-snmp-config --compile-subagent Ctest sinIDENT.c
> >
> > (compiles cleanly)
> > # ./Ctest
> > # snmpget -v 1 -c public localhost sinIDENT.0
> > # SIN-TOP-LEVEL-0::sinIDENT.0 = STRING: ZQXA
> > (all's well)
> > (kill Ctest)
> >
> >
> > HOWEVER, if I rename that same module to sinIDENT.cpp and compile:
> > # net-snmp-config --compile-subagent CppTest --cflags -lstdc++
> > sinIDENT.cpp
> > (compiles cleanly)
> > # ./CppTest
> > # snmpget -v 1 -c public localhost sinIDENT.0
> > Error in packet
> > Reason: (noSuchName) There is no such variable name in this MIB.
> > Failed object: NAVCAN-CNS-SIN-TOP-LEVEL-0::sinIDENT.0
> >
> >
> > My first thought was that there was fname mangling going on so I made
> > sure that the header prevents that:
> >
> >
> > #ifndef SINIDENT_H
> > #define SINIDENT_H*/
> > #ifdef __cplusplus
> > extern "C" {
> > #endif
> > /* function declarations */
> > void init_sinIDENT(void);
> > Netsnmp_Node_Handler handle_sinIDENT;
> > #ifdef __cplusplus
> > }
> > #endif
> > #endif /* SINIDENT_H */
> >
> >
> > And double checked the names:
> > # nm Ctest | grep sin
> > 08049770 T handle_sinIDENT
> > 080497c0 T init_sinIDENT
> > #
> > # nm CppTest |grep sin (showing mangled non-C-calling-convention)
> > 08049b80 t _GLOBAL__I_init_sinIDENT
> > 0804b080 r _ZZ13init_sinIDENTE5C.161
> > 0804b060 r _ZZ13init_sinIDENTE8__func__
> > 08049c60 T handle_sinIDENT
> > 08049bb0 T init_sinIDENT
> >
> >
> > I have NO IDEA why the C++ version returns a failure. Please Help, I
> > don't want to be restricted to 20 year old C!
> >
> The problem is that the generator expects to work with C code.
>
> If you run the generator for both cases with the --norm flag that makes
> it leave the temporary file it generates you will see that the actual
> difference is that the C version calls init_sinIDENT (and includes the
> sinIDENT.h header).
>
> If you try the version that calls the init routine I expect it to work,
> does it?
>
> One could imagine an additional flag to --compile-subagent that lists
> init_/shutdown_ routines it should look for in addition to the
> automatically generated... but I am unsure about that being enough.
>
> /MF
>
>
>
------------------------------------------------------------------------------
October Webinars: Code for Performance
Free Intel webinars can help you accelerate application performance.
Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from
the latest Intel processors and coprocessors. See abstracts and register >
http://pubads.g.doubleclick.net/gampad/clk?id=60134791&iu=/4140/ostg.clktrk
_______________________________________________
Net-snmp-coders mailing list
Net-snmp-coders@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/net-snmp-coders
