Bug 8620

Hey, 

I did a search through the mega-manual for the term "sdknative" and, as expected, there are a number of hits.  I don't understand the term fully (also as expected).

Scott

native packages are built to run on the build host. They link to some host libraries, assume the presence of certain utilities and include paths into TMPDIR (most notably RPATHS in the binaries).

nativesdk recipes are built to run on SDKMACHINE, SDKMACHINE may differ from the host OS architecture (build 32-bit SDKMACHINE on a 64-bit host, or vice versa) and, importantly, the binaries output by nativesdk are relocatable.

You should be able to run the output of a 64-bit nativesdk build on any 64-bit Linux host, whereas the output of a 64-bit native build could fail on a different host distro, on the same host in a different build directory, etc.

Hi, 

I am going through the YP docs and trying to clarify some of the instances where "native" and "nativesdk" appear. Please look these changes over and let me know if they resolve this issue.  I added Paul Eggleton to the CC list because he is an expert in everything:

 * http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-pre-built-binaries-and-qemu

 * http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#additional-implementation-details

* http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#wic-requirements

* http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#building-images-for-more-than-one-machine

* Fourth bullet item in the list at http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#getting-your-package-ready

* Second bullet item in the list at http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#post-installation-scripts

* Item #2 in the list at http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#downloading-a-pre-built-buildtools-tarball

* Item #4 in the list at http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#building-your-own-buildtools-tarball

* 2nd paragraph of http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#checksums

* http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.3-sstate-mirrors

* http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.3-nativesdk

* http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#ref-classes-chrpath

(In reply to comment #3)
> Hi, 
> 
> I am going through the YP docs and trying to clarify some of the instances
> where "native" and "nativesdk" appear. Please look these changes over and
> let me know if they resolve this issue.  I added Paul Eggleton to the CC
> list because he is an expert in everything:
> 
>  *
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-pre-
> built-binaries-and-qemu

Seems OK.

>  *
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#additional-
> implementation-details

I don't think this change makes sense.

> *
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#wic-
> requirements

Fine.

> *
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#building-
> images-for-more-than-one-machine

Seem to be missing a closing paren:

"When you use the same TMPDIR for multiple machine builds, the OpenEmbedded build system can reuse the existing native (i.e. host system) and often cross-recipes (i.e. nativesdk for multiple machines. Thus, build time decreases."

However I wonder whether using nativesdk as an example of a cross recipes has potential to be confusing — I'd be inclined to leave that as is in the 2.0 docs:

"When you use the same TMPDIR for multiple machine builds, the OpenEmbedded build system can reuse the existing native (i.e. host system) and often cross-recipes for multiple machines. Thus, build time decreases."

> * Fourth bullet item in the list at
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#getting-your-
> package-ready

This one has potential for confusion again. The 'native make check that runs on the host system builds and runs on the same computer' it refers to isn't (strictly) a version we build — it's more likely to be the make from the host OS (as we depend on that being present). I'd change this to:

"Many packages based on Automake compile and run the test suite by using a single command such as make check. However, the host make check builds and runs on the same computer, while cross-compiling requires that the package is built on the host but executed for the target architecture (though often, as in the case for ptest, the execution occurs on the host)."

> * Second bullet item in the list at
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#post-
> installation-scripts

Fine.

> * Item #2 in the list at
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#downloading-
> a-pre-built-buildtools-tarball
>
> * Item #4 in the list at
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#building-
> your-own-buildtools-tarball

I'm not sure these two are necessary. 
 
> * 2nd paragraph of
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#checksums

"native (build host) or cross packages (target hardware) relocatable."

cross packages run on the build host but generate output for the target architecture (rather than the host architecture). You don't say otherwise here but it's ambiguous enough to be confusing I feel.

See:
* http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#cross-development-toolchain
* https://en.wikipedia.org/wiki/Cross_compiler

> *
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.
> 3-sstate-mirrors

Good.

> *
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.
> 3-nativesdk

That's not right. nativesdk packages are relocatable packages for the native architecture as specified in SDK_ARCH. 

Whilst a native package is strictly for the host architecture & OS configuration, including the specific paths it's originally installed into, a nativesdk package is relocatable and can be installed on a different host with the same architecture without requiring the same OS or installation path.

> *
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#ref-classes-
> chrpath

I'd be inclined to leave this as it was. We don't really need to explain what nativesdk and cross and cross-canadian packages are at this juncture, only what benefit making them relocatable provides. As it stands the clarification only applies to cross and cross-canadian (not nativesdk).

(In reply to comment #4)
> (In reply to comment #3)
> > Hi, 
> > 
> > I am going through the YP docs and trying to clarify some of the instances
> > where "native" and "nativesdk" appear. Please look these changes over and
> > let me know if they resolve this issue.  I added Paul Eggleton to the CC
> > list because he is an expert in everything:
> > 
> >  *
> > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#using-pre-
> > built-binaries-and-qemu
> 
> Seems OK.
> 
> >  *
> > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#additional-
> > implementation-details
> 
> I don't think this change makes sense.

Ok - I set this back to how it was.

> 
> > *
> > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#wic-
> > requirements
> 
> Fine.
> 
> > *
> > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#building-
> > images-for-more-than-one-machine
> 
> Seem to be missing a closing paren:
> 
> "When you use the same TMPDIR for multiple machine builds, the OpenEmbedded
> build system can reuse the existing native (i.e. host system) and often
> cross-recipes (i.e. nativesdk for multiple machines. Thus, build time
> decreases."
> 
> However I wonder whether using nativesdk as an example of a cross recipes
> has potential to be confusing — I'd be inclined to leave that as is in the
> 2.0 docs:

ok - I changed that one back.

> 
> "When you use the same TMPDIR for multiple machine builds, the OpenEmbedded
> build system can reuse the existing native (i.e. host system) and often
> cross-recipes for multiple machines. Thus, build time decreases."
> 
> > * Fourth bullet item in the list at
> > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#getting-your-
> > package-ready
> 
> This one has potential for confusion again. The 'native make check that runs
> on the host system builds and runs on the same computer' it refers to isn't
> (strictly) a version we build — it's more likely to be the make from the
> host OS (as we depend on that being present). I'd change this to:
> 
> "Many packages based on Automake compile and run the test suite by using a
> single command such as make check. However, the host make check builds and
> runs on the same computer, while cross-compiling requires that the package
> is built on the host but executed for the target architecture (though often,
> as in the case for ptest, the execution occurs on the host)."

Sounds good... I made that change.

> 
> > * Second bullet item in the list at
> > http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#post-
> > installation-scripts
> 
> Fine.
> 
> > * Item #2 in the list at
> > http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#downloading-
> > a-pre-built-buildtools-tarball

Reverted to the 2.0 version.

> >
> > * Item #4 in the list at
> > http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#building-
> > your-own-buildtools-tarball

Reverted to the 2.0 version.

> 
> I'm not sure these two are necessary. 
>  
> > * 2nd paragraph of
> > http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#checksums
> 
> "native (build host) or cross packages (target hardware) relocatable."
> 
> cross packages run on the build host but generate output for the target
> architecture (rather than the host architecture). You don't say otherwise
> here but it's ambiguous enough to be confusing I feel.

I added a note there - see if that works.

> 
> See:
> *
> http://www.yoctoproject.org/docs/2.1/dev-manual/dev-manual.html#cross-
> development-toolchain
> * https://en.wikipedia.org/wiki/Cross_compiler
> 
> > *
> > http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.
> > 3-sstate-mirrors
> 
> Good.
> 
> > *
> > http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.
> > 3-nativesdk
> 
> That's not right. nativesdk packages are relocatable packages for the native
> architecture as specified in SDK_ARCH. 
> 
> Whilst a native package is strictly for the host architecture & OS
> configuration, including the specific paths it's originally installed into,
> a nativesdk package is relocatable and can be installed on a different host
> with the same architecture without requiring the same OS or installation
> path.

I re-wrote that with your wording in there for the clause.

> 
> > *
> > http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#ref-classes-
> > chrpath
> 
> I'd be inclined to leave this as it was. We don't really need to explain
> what nativesdk and cross and cross-canadian packages are at this juncture,
> only what benefit making them relocatable provides. As it stands the
> clarification only applies to cross and cross-canadian (not nativesdk).

ok - turned that back into how it was.

Thanks for the changes so far!

Here's two additional suggested changes against the reference manual:

 * In 4.2. Cross-Development Toolchain Generation, after "...and other nativesdk-* tools you need to cross-compile and test your software.", I'd add the following:

    ("nativesdk" is to be read as "native to the SDK", i.e., native to SDK_ARCH.)

 * In 5.2.2.3. nativesdk, I'd change "...which are relocatable packages for the native architecture as specified in SDK_ARCH" to just "...which are relocatable packages that are native to SDK_ARCH". I think that might be less confusing.

(In reply to comment #6)
> Thanks for the changes so far!
> 
> Here's two additional suggested changes against the reference manual:
> 
>  * In 4.2. Cross-Development Toolchain Generation, after "...and other
> nativesdk-* tools you need to cross-compile and test your software.", I'd
> add the following:
> 
>     ("nativesdk" is to be read as "native to the SDK", i.e., native to
> SDK_ARCH.)

See http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#cross-development-toolchain-generation

> 
>  * In 5.2.2.3. nativesdk, I'd change "...which are relocatable packages for
> the native architecture as specified in SDK_ARCH" to just "...which are
> relocatable packages that are native to SDK_ARCH". I think that might be
> less confusing.

Sounds good - see http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.3-nativesdk

(In reply to comment #7)
> (In reply to comment #6)
> > Thanks for the changes so far!
> > 
> > Here's two additional suggested changes against the reference manual:
> > 
> >  * In 4.2. Cross-Development Toolchain Generation, after "...and other
> > nativesdk-* tools you need to cross-compile and test your software.", I'd
> > add the following:
> > 
> >     ("nativesdk" is to be read as "native to the SDK", i.e., native to
> > SDK_ARCH.)
> 
> See
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#cross-
> development-toolchain-generation
> 
> > 
> >  * In 5.2.2.3. nativesdk, I'd change "...which are relocatable packages for
> > the native architecture as specified in SDK_ARCH" to just "...which are
> > relocatable packages that are native to SDK_ARCH". I think that might be
> > less confusing.
> 
> Sounds good - see
> http://www.yoctoproject.org/docs/2.1/ref-manual/ref-manual.html#migration-1.
> 3-nativesdk

Looks good. Thanks.

Hi, 

Moving status to RESOLVED and setting the doc flag to "done."

Scott