[AGENT++] Getting agent++ to build under Mac OS X

[Xochitl Lunde]

> Hello,
> 
> > testing with this change in Agent++.  I had some trouble with it at 
first 
> > until I realized AGENTPP_DECL_TEMPL_OIDLSIT_MIBTABLEROW was a typo in 
> > code, not just in email. mib.h line 1220, 'LSIT' instead of 'LIST'. 
I'll 
> > fix that in my initial Agent++ patch once I test with this a little 
more. 
> 
> I just did a 'grep -h "define .*_DECL" *.h' on the headers to get the
> defines and missed the typo. It will be corrected in the next release.
> 
> > Did you get my initial patch files?
> 
> Yes, I will check them soon.
> 
> > I'll probably build and try out one or two of the Agent++ examples and 

> > also try to build AgentX++ next.  As far as I can tell, these are the 
last 
> > two pieces which our in-house product software build needs to produce 
an 
> > executable. Here's hoping!
> 
> Please keep us informed about problems and/or success.

An update for you on this effort:

Not a major issue, but the snapshot which I was directed to (
http://oosnmp.com/~katz/snapshot/) as of my download day appeared to be 
based off of v3.2 Snmp++ whereas the downloads page on the website is 
v3.2.23, according to the file comment headers.  My diffs showed other 
differences between the two as well, which is logical.  I did encounter 
some linking problem because of this, but I was able to resolve it by 
applying my patch to the v.3.2.23 from www.agentpp.org instead.  (I will 
probably generate a new patch however, as there were still a couple things 
which I had to change manually.)  The main problem was in 'uxsnmp.h', 
EventListHolder * eventListHolder was protected in the snapshot version, 
but apparently our application needed the public version.  I don't know 
which way is correct and whether our application should change or if the 
SNMP++ v.3.2.23 with public eventListHolder is correct.

I expect to have to take a break from working on this for a little while, 
as I have some new additional things to do and I still have linker errors 
in Agent++ when trying to link the application.  I'm planning to go back 
and try to build all of the Agent++ examples and see if any of those fail 
to build - which would show me that there is still a problem in the way 
I'm building the library.

Having patched the latest Agent++ suite from www.agentpp.org, I still see 
unresolved symbols when building with SNMPV3 enabled (using Xcode to build 
the application):

Undefined symbols:
  "getEngineAddress()", referenced from:
      RemoteSnmpServer::Initialize(char const*, char const*, int, int)in 
libcommsnmp.a(remotesnmpserver.o)
      RemoteSnmpServer::Initialize(char const*, char const*, int, int, 
int)in libcommsnmp.a(remotesnmpserver.o)
  "SnmpRequestV3::send(UTarget&, Pdux&)", referenced from:
      NotificationOriginator::send_notify(ListCursor<MibTableRow>&, 
NotificationOriginator::NotificationOriginatorParams&, int)in 
libagent++.a(notification_originator.o)
      NotificationOriginator::send_notify(ListCursor<MibTableRow>&, 
NotificationOriginator::NotificationOriginatorParams&, int)in 
libagent++.a(notification_originator.o)
  "GetMacAddress(char const*, char*, int)", referenced from:
      GetMacAddress(unsigned long, char*, int)in pald-getmacaddress.o
  "SnmpRequestV3::SnmpRequestV3()", referenced from:
      ProxyForwarder::initialize()       in 
libagent++.a(proxy_forwarder.o)
  "SnmpRequestV3::~SnmpRequestV3()", referenced from:
      ProxyForwarder::~ProxyForwarder()in libagent++.a(proxy_forwarder.o)
  "SnmpRequestV3::send_request(UTarget&, Pdux&)", referenced from:
      ProxyForwarder::process_single(Pdux&, Request*)      in 
libagent++.a(proxy_forwarder.o)
      ProxyForwarder::process_multiple(Pdux&, Request*)      in 
libagent++.a(proxy_forwarder.o)
ld: symbol(s) not found
collect2: ld returned 1 exit status
make: *** [pald] Error 1

I am not sure if I have missed another definition or such.  Clearly some 
of the missing symbols are in our appplication and not in the library. 
When I build without SNMPV3, I get even more errors, apparently the 
application has it in mind to use the SNMPV3 classes.  I wouldn't worry 
too much about this right now unless you see something obvious.  I will 
run it by the other programmers in house and see if the errors look 
familiar to anyone who has built our in-house application before.

Thanks,
Xochitl