[yocto] Trying to create OpenDDS recipe
I hope this is the correct place to post this. If not, please let me
know.
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
}
This works right up until there is a compile error in ACE+TAO. Of
course, I build the entire DDS package, including ACE+TAO, with no
hiccups in Ubuntu, so I understand that this is a
cross-compile/environment issue.
The compile error is that it cannot find features.h, which is clearly in
${STAGING_LIBDIR}/${MACHINE}/usr/include. The compile command which is
being executed is as follows (this is going to be ugly, let me know if
there's a better way to include this, such as a pastebin somewhere):
| make[1]: Entering directory
`/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
_wrappers/TAO/TAO_IDL'
|
| GNUmakefile:
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/TAO/TAO_IDL/GNUmakefile.TAO_IDL_EXE MAKEFLAGS=w
|
| i586-poky-linux-g++ -march=i586
--sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86
-fvisibility=hidden -fvisibility-inlines-hidden -W -Wall -Wpointer-arith
-ggdb -pipe -D_REENTRANT -DACE_HAS_AIO_CALLS -D_GNU_SOURCE
-I/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/AC
E_wrappers -DACE_HAS_EXCEPTIONS -DACE_NO_INLINE -I../.. -Iinclude
-Ibe_include -Ife -I.. -DTAO_IDL_PREPROCESSOR=\"i586-poky-linux-g++
-march=i586 --sysroot=/opt/yocto/poky-5.0.1-build/tmp/sysroots/qemux86\"
-c -o .obj/driver/drv_preproc.o driver/drv_preproc.cpp
| :0:22: warning: missing terminating " character
| In file included from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-linux-common.h:30:0,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-linux.h:14,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config.h:1,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-macros.h:24,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-lite.h:24,
| from
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/os_include/os_limits.h:21,
| from include/idl_defines.h:70,
| from driver/drv_preproc.cpp:70:
|
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE_
wrappers/ace/config-posix.h:7:20: fatal error: unistd.h: No such file or
directory
| compilation terminated.
| make[1]: *** [.obj/driver/drv_preproc.o] Error 1
| make[1]: Leaving directory
`/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/ACE
_wrappers/TAO/TAO_IDL'
| make: *** [TAO_IDL_EXE] Error 2
| ERROR: Function 'do_compile' failed (see
/opt/yocto/poky-5.0.1-build/tmp/work/i586-poky-linux/opendds-2.3-r0/temp
/log.do_compile.17412 for further information)
NOTE: package opendds-2.3-r0: task do_compile: Failed
ERROR: Task 5
(/opt/yocto/poky-bernard-5.0.1/meta/recipes-middleware/opendds/opendds_2
.3.bb, do_compile) failed with exit code '1'
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 should be good. I have checked, and features.h is
in the /usr/include subdirectory there.
Does anyone have a clue they could lend me?
Thanks,
Paul E. Ourada
Sr. Principal Software Engineer
Covidien, Energy-based Devices
5920 Longbow Drive
Boulder, CO 80301
paul.our...@covidien.com
www.covidien.com
Main: 303-530-2300
Ofc: 303-581-6940
Fax: 303-581-6741
___
yocto mailing list
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Trying to create OpenDDS recipe
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.our...@covidien.com
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 > 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
yocto@yoctoproject.org
https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] prebuilt pacakages
I'm no expert, but would the use of something like Puppet make this job a lot easier? A consultant is suggesting that we consider that tool for this purpose. Define a particular set of packages in Puppet, and you can play around in your sandbox to your heart's content. When you want to get back to a particular configuration, let Puppet do that for you. It may be a little heavyweight for some projects, but I'd think that any project which needs stricter control could use this. http://www.puppetlabs.com Paul E. Ourada Sr. Principal Software Engineer Covidien, Energy-based Devices 5920 Longbow Drive Boulder, CO 80301 paul.our...@covidien.com www.covidien.com Main: 303-530-2300 Ofc: 303-581-6940 Fax: 303-581-6741 -Original Message- From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] On Behalf Of Richard Purdie Sent: Friday, August 05, 2011 2:13 AM To: Todd Cooper Cc: "yocto@yoctoproject.org" Subject: Re: [yocto] prebuilt pacakages On Thu, 2011-08-04 at 18:37 -0700, Todd Cooper wrote: > Can I suggest that Yocto put it on the futures list, but with a lower > priority? You can add it to the list on the wiki. Which known set of prebuilt packages are you thinking we should be able to build against? Cheers, Richard ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
Re: [yocto] Yocto usability questions
I apologize in advance for the top-post. Like Mark, I'm a 20+ year veteran of "ordinary" embedded development, and so cross compilation is old hat for me as well. The usual commercial cross compilers, linkers, RTOSes, debuggers, and other libraries are usually fairly well integrated. Those types of environments tolerate their host environments fairly well, because it's pretty easy to keep everything separated. I am much newer to Linux and embedded Linux development. I haven't used the SDK for Yocto yet, but I have used the Timesys SDK a little. For writing new code/apps, it's fairly straightforward - set up some environment variables, write a makefile and use cross_make, cross_configure, etc. I set up the embedded target to PXE boot, which keeps all executables and RFS on the host workstation. So for development one merely needs to drop the compiled app and any required configuration onto the RFS on the workstation. For writing kernel-level stuff, such as kernel mode drivers, one pretty much has to use the TimeSys factory (an extension to the kernel make environment from what I can tell). If one wants to use the TimeSys factory so that proprietary apps are built and loaded/installed into the RFS automagically, or build packages which are not on the TimeSys server, then one writes what is essentially the equivalent of the bitbake recipe, only in makefile format. It has all the same sorts of process steps: fetch, unpack, patch, auto/configure, compile, install. Of course PXE boot can be set up for Yocto projects - I've already done it for the Kontron Atom board we're going to use in our next product. I hacked out the bzImage and root file system from the cpio image and plopped them into the tftpboot and exported rfs directory, and bingo - PXE booting! Frankly, as a medical device software developer, I find the "recipe/makefile" paradigm much more familiar and preferable to the "app" developer paradigm. We have to be able to recreate bit-accurate images for our devices. A relatively consistent paradigm for accomplishing this is much better than cobbling together a bunch of ad hoc scripts. At any rate, it seems to me that writing recipes is writing recipes, just like once you've used 3 or 4 editors or word processors, then you pretty much know what the score is when you go to pick up the 5th. Bitbake recipes aren't all that different from makefiles, except for the syntax,and learning the various meanings of different "build variables" -- oh, and using bitbake/python as glueinstead of jam, or make. I think that this has been the biggest source of frustration for me wrt to Yocto: Trying to map what I already know onto a new paradigm. I know - after 20 years, the mud gets a little thick and hard. ;) But I understand the need to make things easier for the less experienced developer. And I get that cross compiling an embedded Linux OS is more intertwined with the host workstation OS than other RTOSes, even when they are compiled on a *nix workstation. One way that I'm addressing this for my development team (which has several never-done-Linux-no-way-no-how types) is finding links to relevant tutorials and sprinkling them in places they're likely to need the info. Although there is a ton of documentation out there, it's not always in easy to find places. As a relative newcomer to Yocto and OE and bitbake, I can't agree with Mark more regarding examples and documentation. I'd suggest that you make a part of your process finding an inexperienced someone to run through your documentation and try to implement the various different features, or demonstrate knowledge of key concepts. The questions such a person might ask are likely pointers to holes in your documentation or process. This could be a good Google Summer of Code type exercise. Not as sexy as some, but definitely a big payoff for Yocto. Mark mentioned the need for adding packages which are not already in the recipe base, but perhaps already exist in a desktop form. Making it easy to contribute seems like a common FOSS practice. For the difficulty aspect, someone mentioned in the Qt/OpenSSL thread recently that RPMs have a lot of the dependency information built into them, and I suspect also configuration files for install, or recipes for creating them. I also read in one of the Yocto blogs that someone on the Kernel side created a script to keep Kconfig fragments synched across BSPs. Might it be possible to write a script to mine a desktop RPM (or any other usable package format), and their associated makefile(s) to create as much of the bones of a bitbake recipe as can be gleaned from the desktop package? It might be as complex a task as the automake process itself. :) Hope there was some useful information in there somewhere. :) Paul Ourada Sr Principal Software Engineer Covidien, Surgical Solutions, Energy-based Devices From: yocto-boun...@yoctopro
Re: [yocto] Yocto usability questions
Jack said: >From: yocto-boun...@yoctoproject.org [mailto:yocto-boun...@yoctoproject.org] >On Behalf Of Jack Mitchell >Sent: Friday, November 18, 2011 2:40 AM >To: yocto@yoctoproject.org >Subject: Re: [yocto] Yocto usability questions > >On 17/11/2011 21:38, Chris Tapp wrote: >On 16 Nov 2011, at 22:07, Jeff Osier-Mixon wrote: > > >Mark & everyone else listening: > > >It is very frustrating when you come to an issue that isn't documented, >however I have found the IRC an invaluable >resource as well as this mailing >list. If documentation was to become more extensive I feel the categories >should be >defined further and split into more documents. I would just add that for some corporate/enterprise customers (such as myself), while IRC is great, it isn't as great an option because corporate IS locks down IRC protocols. To use IRC, I would have to do so from a non-work computer and likely outside of normal work hours, of which I already put in way more than my wife would prefer. :) I really like Jack's list, though. I would like to pile on (again :)) that documentation, examples and explanation of terms are very important. Paul Paul E. Ourada Sr. Principal Software Engineer Covidien, Energy-based Devices 5920 Longbow Drive Boulder, CO 80301 paul.our...@covidien.com www.covidien.com Main: 303-530-2300 Ofc: 303-581-6940 Fax: 303-581-6741 ___ yocto mailing list yocto@yoctoproject.org https://lists.yoctoproject.org/listinfo/yocto
