Cross building question

Cross building question

[Gary Thomas]

I'm asking on this list since this is a pretty general question.
If it's more appropriate for another venue, just let me know.

I'm trying to build a new package for my target which has never
been ported to OpenEmbedded/Yocto/...  (It's the Amanda backup
server if anyone has ever looked at this).  The code is a
giant mass that I'd hoped not to have to delve into very deeply.
Basic configuration (autoolized) went well, but one of the
first things it wants to do is run a [target] program which
has been linked against the [target] libraries that were just
built.  In this case, it's just a utility to interrogate the
libraries and CONFIG.h files and print a user summary.

What's the best way to handle this and how?  I recall in the
dark old days that there were many such things that relied on
running QEMU to actually execute target code.  Is this still
possible (and being done)?  If so, is that a solution and how
might I force it to happen?

It may turn out that this is just a small problem that I can
patch my way through, but I fear there may be other such utilities
that get built and used, so I'd like to understand my way forward.

Thanks for any pointers/ideas

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Cross building question

[Burton, Ross]

On 19 June 2013 15:03, Gary Thomas <gary@mlbassoc.com> wrote:
> What's the best way to handle this and how?  I recall in the
> dark old days that there were many such things that relied on
> running QEMU to actually execute target code.  Is this still
> possible (and being done)?  If so, is that a solution and how
> might I force it to happen?

You can use qemu, for example the fontconfig cache generation is done
at image construction time using qemu running the target binaries.
The alternative solution is to use the host compiler ($BUILD_CC etc)
and build the tool natively - either by patching the build system or
building it manually yourself before invoking make.

Of course, if this binary is just used to print some stuff for the
user, you could just patch it out. :)

Ross

Re: Cross building question

[Gary Thomas]

On 2013-06-19 15:14, Burton, Ross wrote:
> On 19 June 2013 15:03, Gary Thomas <gary@mlbassoc.com> wrote:
>> What's the best way to handle this and how?  I recall in the
>> dark old days that there were many such things that relied on
>> running QEMU to actually execute target code.  Is this still
>> possible (and being done)?  If so, is that a solution and how
>> might I force it to happen?
>
> You can use qemu, for example the fontconfig cache generation is done
> at image construction time using qemu running the target binaries.
> The alternative solution is to use the host compiler ($BUILD_CC etc)
> and build the tool natively - either by patching the build system or
> building it manually yourself before invoking make.
>
> Of course, if this binary is just used to print some stuff for the
> user, you could just patch it out. :)

Probably what I will do!

In the mean time, I faked that one and moved on and got the whole thing
to build :-)  Now I face this packaging issue:
   ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so: amanda path 
'/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'

Any clues how I fix this?

Query: I've built this now using a cross build (normal Yocto style) and
native using a Yocto created SDK.  These _should_ be the same tools, no?
I ask because I had a few gotchas - things that were different between
the two environments.  If I track them down, are they of any interest?

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

Re: Cross building question

[Burton, Ross]

On 19 June 2013 15:39, Gary Thomas <gary@mlbassoc.com> wrote:
> In the mean time, I faked that one and moved on and got the whole thing
> to build :-)  Now I face this packaging issue:
>   ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
> amanda path
> '/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
>
> Any clues how I fix this?

Is libamar actually a module, and not a library? (albeit done badly,
as it's a symlink)  If so, then INSANE_SKIP_${PN} += "dev-so" is the
right way to skip that test.  This may be a bug in amanda which
everyone else has been ignoring.

> Query: I've built this now using a cross build (normal Yocto style) and
> native using a Yocto created SDK.  These _should_ be the same tools, no?
> I ask because I had a few gotchas - things that were different between
> the two environments.  If I track them down, are they of any interest?

I've not actually used the SDK but they should be mostly the same,
yes.  Differences are bound to be of interest so please do report
them.

Ross

Re: Cross building question

[Gary Thomas]

[-- Attachment #1: Type: text/plain, Size: 2921 bytes --]

On 2013-06-19 15:52, Burton, Ross wrote:
> On 19 June 2013 15:39, Gary Thomas <gary@mlbassoc.com> wrote:
>> In the mean time, I faked that one and moved on and got the whole thing
>> to build :-)  Now I face this packaging issue:
>>    ERROR: QA Issue: non -dev/-dbg/-nativesdk package contains symlink .so:
>> amanda path
>> '/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so'
>>
>> Any clues how I fix this?
>
> Is libamar actually a module, and not a library? (albeit done badly,
> as it's a symlink)  If so, then INSANE_SKIP_${PN} += "dev-so" is the
> right way to skip that test.  This may be a bug in amanda which
> everyone else has been ignoring.

Here's what I have:

   [gary@thor synology_poky]$ file tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so
   tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar.so: symbolic link to `libamar-3.3.3.so'
   [gary@thor synology_poky]$ file tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar-3.3.3.so
   tmp/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/libamar-3.3.3.so: ELF 32-bit MSB shared object, PowerPC or cisco 4500, version 1 
(SYSV), dynamically linked, BuildID[sha1]=0xef5c0cd4d0ac1abfb9a29b05ca6189d5a1b745ae, stripped

Following your advice, I added these lines to my recipe:

   FILES_${PN} += "/usr/lib \
                   /usr/local \
   "
   INSANE_SKIP_${PN} += "dev-so"

Now I get errors like these (they might have been there before):
   ERROR: QA Issue: non debug package contains .debug directory: amanda path 
/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/local/share/perl5/auto/Amanda/Xfer/.debug/libXfer.so
   ERROR: QA Issue: non debug package contains .debug directory: amanda path 
/work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/amanda/.debug/chunker

My recipe (still a work in progress) is attached in case I've done something
really stupid...

>
>> Query: I've built this now using a cross build (normal Yocto style) and
>> native using a Yocto created SDK.  These _should_ be the same tools, no?
>> I ask because I had a few gotchas - things that were different between
>> the two environments.  If I track them down, are they of any interest?
>
> I've not actually used the SDK but they should be mostly the same,
> yes.  Differences are bound to be of interest so please do report
> them.

I'll get them all collected and report back.

Thanks

-- 
------------------------------------------------------------
Gary Thomas                 |  Consulting for the
MLB Associates              |    Embedded world
------------------------------------------------------------

[-- Attachment #2: amanda_3.3.3.bb --]
[-- Type: text/plain, Size: 661 bytes --]

DESCRIPTION = " Amanda, The Advanced Maryland Automatic Network Disk Archiver"
HOMEPAGE = "http://www.amanda.org/"
SECTION = "utilities"
PRIORITY = "optional"
DEPENDS = "glib-2.0 perl"
LICENSE = "Amanda"
LIC_FILES_CHKSUM = " \
    file://COPYRIGHT;md5=ea2cb06a4d0ac7da46e2a41eddf7fba2 \
"

SRC_URI = "http://downloads.sourceforge.net/project/amanda/amanda-stable/${PV}/amanda-${PV}.tar.gz \
          "
SRC_URI[md5sum] = "2b9c7fbc030d7c242197cc8367e9a6b8"
SRC_URI[sha256sum] = "c36c9cd61dc62a7824abb7ba74cc4b09527bd82a930d691cf207b60b4bb15b72"

inherit autotools gettext

FILES_${PN} += "/usr/lib \
                /usr/local \
"
INSANE_SKIP_${PN} += "dev-so"

Re: Cross building question

[Burton, Ross]

On 19 June 2013 16:25, Gary Thomas <gary@mlbassoc.com> wrote:
>
>   FILES_${PN} += "/usr/lib \
>                   /usr/local \
>   "
>   INSANE_SKIP_${PN} += "dev-so"
>
> Now I get errors like these (they might have been there before):
>   ERROR: QA Issue: non debug package contains .debug directory: amanda path
> /work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/local/share/perl5/auto/Amanda/Xfer/.debug/libXfer.so
>   ERROR: QA Issue: non debug package contains .debug directory: amanda path
> /work/ppce500v2-amltd-linux-gnuspe/amanda/3.3.3-r0/packages-split/amanda/usr/lib/amanda/amanda/.debug/chunker

You'll want to put those directories into FILES_$PN-dbg, as otherwise
they end up in PN and you rightly get warnings.

Ross