Re: Trying to create OpenDDS recipe


Paul Ourada
 

Hi Darren -

Thanks for getting back to me. I have been able to get a lot further with the recipe. It turns out that the problem is in the makefiles for OpenDDS. I'll detail further below.

Paul E. Ourada
Sr. Principal Software Engineer
Covidien, Energy-based Devices
5920 Longbow Drive
Boulder, CO 80301
paul.ourada@...
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741


Hi Paul,
On 07/19/2011 07:41 AM, Ourada, Paul wrote:
I hope this is the correct place to post this. If not, please let me
know.
This is the right place. In the future please don't reply to an existing
post as your message then gets threaded with the one you replied to
(likely why you didn't receive a response so far - that I see anyway).
I guess I thought that changing the subject would have fixed that. Guess the
mail list s/w is smarter than that. :)


I'm trying to create a recipe for OpenDDS. The recipe works so far as
fetching, unpacking, and configuration. Or it seems to. :) Part of the
configuration piece is that it also pulls down ACE+TAO real-time CORBA.
This part works fine as well.

I set S as follows to match the unpacking directories enforced by the
tar file:

S = ${WORKINGDIR}/DDS

The package comes with a configuration script pre-built, and it expects
to be told where glibc is. So, I write do_configure as follows:

EXTRA_OECONF = "-glibc=${STAGING_DIR}/${MACHINE}/usr"

do_configure() {
${S}/configure ${EXTRA_OECONF}
}

The problem that I run into is during compilation. I write the following
for do_compile()

do_compile() {
oenote ${STAGING_DIR}
cd ${S} && make
}
Is there a reason you are overriding configure and compile? These appear
to be autoconf projects, which should just work for recipes using
autotools.bbclass.
I had tried that initially. The configuration file is already supplied, so running autotools to create the configure script is not necessary, but running ./configure is. Is there a better way to do that?

:
:
<< most of the compiler command line gobblety-gook snipped>>

-DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++
-march=i586 --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"

The thing that is puzzling me is that --sysroot seems to be pointing in
the general direction of ${STAGING_DIR} and so the include directive,
#include <features.h>> should be good. I have checked, and features.h is
in the /usr/include subdirectory there.
I see unistd.h missing, not features.h.
You're right, it was complaining about unistd.h, but it turns out that the real culprit was the TAO_IDL_PREPROCESSOR macro above. When I compared it to what was being emitted in the Ubuntu compile, I saw that the long, nasty, compound, double-quoted thing should have just been "i586-poky-linux-g++." TAO_ID_PREPROCESSOR was being assigned the value of ${CXX}.

It appears that instead of pre-pending the ${CPPFLAGS} variable, yocto/poky recipes were appending the cross-compile build variables to ${CXX}. I patched the OpenDDS makefile(s) to look for the first word in the ${CXX} macro, and substituted that in the assignment of TAO_IDL_PREPROCESSOR. Dunno if that's the "right" way to do it, or if there's a bug in ${CXX} assignment?

Anyway, I think that I'm getting there w/the recipe. I'm sure that there are some things I'm doing wrong. For instance, I'm no longer cd'ing to ${S}, as OE already takes me there. I'm also using oe_runmake in do_compile().

I expect that I'll be running some version of "make install" at some point.

I'm sure I'll have more questions as I go along.

Thanks for helping an OE/Yocto N00b!

Paul

Join {yocto@lists.yoctoproject.org to automatically receive all group messages.