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 [email protected] 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 _______________________________________________ yocto mailing list [email protected] https://lists.yoctoproject.org/listinfo/yocto
