Wednesday, April 29, 2009
Getting confd.h compile error - but i'm not using confd (!)
Q: Why do I get this compile error when building generic_cluster in Element 2.3.3? It complains about confd, but i'm not even using confd.
A: You - or someone else - probably did compile for a ref_platform that used confd earlier, on the same system. Dump your environment with "env" and see whether CONFD_VERSION is defined. If so, undefine it with "unset CONFD_VERSION" and the make should now proceed.
make[3]: Entering directory `/home/jmir/Element/Releases/2.3.3/element_2.3.3/src/northbound/confd_proxy'
Makefile:42: 27
Makefile:43: -DCONFD_VERSION=27
+++ Compiling confd_proxy.c
confd_proxy.c:79:19: confd.h: No such file or directory
make[3]: *** [obj/linux-x86_64/confd_proxy.o] Error 1
make[3]: Leaving directory `/home/jmir/Element/Releases/2.3.3/element_2.3.3/src/northbound/confd_proxy'
make[2]: *** [libs] Error 1
make[2]: Leaving directory `/home/jmir/Element/Releases/2.3.3/element_2.3.3
make[1]: *** [elemlibs] Error 2
make[1]: Leaving directory `/home/jmir/Element/Releases/2.3.3/element_2.3.3/ref_platforms/generic_cluster'
make: *** [element-tree] Error 1
A: You - or someone else - probably did compile for a ref_platform that used confd earlier, on the same system. Dump your environment with "env" and see whether CONFD_VERSION is defined. If so, undefine it with "unset CONFD_VERSION" and the make should now proceed.
Tuesday, April 14, 2009
Use of ElemAppInit in 3.0
Q: I'm using ElemAppInit in 3.0 - any known issues?
A: Here is a tip from Jim R:
Just an FYI – in Element 3.0 and later there is a problem if a component uses ElemAppInit instead of the ELEM_MAIN macro. The problem is with the long component names in the amf (saAppliction->Service Group->Component->blah blah blah). There are two ways around this: the easy way is to change the “Process Name Format” to comp in the AMF entry for you component – and make your component name match what you pass into ElemAppInit. Then there’s the right way – Dan S. provided this code fragment below that gets around this problem.
char *clientName;
/*
** Read the client name environmet variable. There will always be one if the Element loader
** is starting the application
*/
if (clientName == NULL)
{
/* No environment variable is present start using app name and hope its unique*/
status = ElemAppInit(pEnv->Name);
H_ASSERT_M(status == ELEM_STATUS_OK);
}
else
{
/* Initialize Element messaging interface and clientName is no longer valid*/
status = ElemAppInit(clientName);
H_ASSERT_M(status == ELEM_STATUS_OK);
}
In most cases this won’t be a problem because people will probably use ELEM_MAIN – but keep this in mind if they are using ElemAppInit.
A: Here is a tip from Jim R:
Just an FYI – in Element 3.0 and later there is a problem if a component uses ElemAppInit instead of the ELEM_MAIN macro. The problem is with the long component names in the amf (saAppliction->Service Group->Component->blah blah blah). There are two ways around this: the easy way is to change the “Process Name Format” to comp in the AMF entry for you component – and make your component name match what you pass into ElemAppInit. Then there’s the right way – Dan S. provided this code fragment below that gets around this problem.
char *clientName;
/*
** Read the client name environmet variable. There will always be one if the Element loader
** is starting the application
*/
if (clientName == NULL)
{
/* No environment variable is present start using app name and hope its unique*/
status = ElemAppInit(pEnv->Name);
H_ASSERT_M(status == ELEM_STATUS_OK);
}
else
{
/* Initialize Element messaging interface and clientName is no longer valid*/
status = ElemAppInit(clientName);
H_ASSERT_M(status == ELEM_STATUS_OK);
}
In most cases this won’t be a problem because people will probably use ELEM_MAIN – but keep this in mind if they are using ElemAppInit.
Labels: Element
free invisible web counter
