libunwind: new pacakge

Signed-off-by:  Andy Kennedy <andy.kennedy@adtran.com>
---

Dear ANDY KENNEDY,

On Tue, 25 Jun 2013 21:41:44 +0000, ANDY KENNEDY wrote:

> +config BR2_PACKAGE_LIBUNWIND
> +	bool "libunwind"
> +	help
> +	  C API to determine the call-chain of a program.
> +
> +	  Project home:  <http://www.nongnu.org/libunwind/index.html>

No need to indicate "Project home:", just:

	  http://www.nongnu.org/libunwind/index.html

Also:

 1) Did you check that it builds fine with uClibc? This kind of library
 tend to use some funky C library features, sometimes not available in
 uClibc.

 2) The libunwind code seems to contain some architecture-specific
 code. While aarch64, arm, mips, ppc, sh, x86 and x86-64 are supported,
 some other architectures that Buildroot supports are not supported. So
 maybe this package should have a "depends on BR2_aarch64 || BR2_arm ||
 BR2_armeb || ..."

Best regards,

Thomas

> > +	  Project home:  <http://www.nongnu.org/libunwind/index.html>
> 
> No need to indicate "Project home:", just:

Okay, I can fix that.

> 
> 	  http://www.nongnu.org/libunwind/index.html
> 
> Also:
> 
>  1) Did you check that it builds fine with uClibc? This kind of library
>  tend to use some funky C library features, sometimes not available in
>  uClibc.

Nope, I didn't.

> 
>  2) The libunwind code seems to contain some architecture-specific
>  code. While aarch64, arm, mips, ppc, sh, x86 and x86-64 are supported,
>  some other architectures that Buildroot supports are not supported. So
>  maybe this package should have a "depends on BR2_aarch64 || BR2_arm ||
>  BR2_armeb || ..."

That is possible as well.  I'm really not devoted to owning this
package that much.  I was merely attempting to push it back as I
added it to our usage of BuildRoot.  To that end, shall I abandon
the process (as I clearly am not willing to do it justice)?

It is no skin off my nose whether it gets put into BuildRoot, I was
only pushing it back as I didn't know it was there until someone else
I work with pointed out that this *seems* to be the basic library GDB
is based off of, thus could be useful in our embedded system.

Anybody willing to carry this flag for me?  I'm just not that committed
to it.

Andy

Andy, All,

On 2013-06-25 21:41 +0000, ANDY KENNEDY spake thusly:
> Signed-off-by:  Andy Kennedy <andy.kennedy@adtran.com>
> ---
> diff -Naur a/package/Config.in b/package/Config.in
> --- a/package/Config.in 2013-06-20 10:32:07.000000000 -0500
> +++ b/package/Config.in 2013-06-21 17:00:21.000000000 -0500
> @@ -612,6 +612,7 @@
>  source "package/libtasn1/Config.in"
>  source "package/libtpl/Config.in"
>  source "package/libseccomp/Config.in"
> +source "package/libunwind/Config.in"
>  source "package/liburcu/Config.in"
>  source "package/linux-pam/Config.in"
>  source "package/log4cxx/Config.in"
> diff -Naur a/package/libunwind/Config.in b/package/libunwind/Config.in
> --- a/package/libunwind/Config.in       1969-12-31 18:00:00.000000000 -0600
> +++ b/package/libunwind/Config.in       2013-06-21 17:23:46.000000000 -0500
> @@ -0,0 +1,6 @@
> +config BR2_PACKAGE_LIBUNWIND
> +	bool "libunwind"
> +	help
> +	  C API to determine the call-chain of a program.
> +
> +	  Project home:  <http://www.nongnu.org/libunwind/index.html>

In addition to other comments, could you please add a changelog to your
patch, and a version number in the subject? Such as:

    [PATCH v3] libunwind: new pacakge

    sob: you

    ---
    Changes v2->v3:
      - blabla
    Changes v1->v2:
      - blabla
      - blabla

This is a least version 3 (or 4?) of this patch, and its hard to tell
what changed between revisions, and to check if suggestions were
applied.

Regards,
Yann E. MORIN.

Dear ANDY KENNEDY,

On Tue, 25 Jun 2013 21:57:14 +0000, ANDY KENNEDY wrote:

> >  1) Did you check that it builds fine with uClibc? This kind of library
> >  tend to use some funky C library features, sometimes not available in
> >  uClibc.
> 
> Nope, I didn't.

Then just do a build with a uClibc toolchain. If you don't want to wait
for the toolchain to build, you can use
http://autobuild.buildroot.org/toolchains/tarballs/br-arm-basic-2013.05-1.tar.bz2
as an external toolchain. It's a basic ARM uClibc toolchain (with no
option enabled: no WCHAR, no largefile, no IPv6, no RPC, no locales).

> >  2) The libunwind code seems to contain some architecture-specific
> >  code. While aarch64, arm, mips, ppc, sh, x86 and x86-64 are supported,
> >  some other architectures that Buildroot supports are not supported. So
> >  maybe this package should have a "depends on BR2_aarch64 || BR2_arm ||
> >  BR2_armeb || ..."
> 
> That is possible as well.  I'm really not devoted to owning this
> package that much.  I was merely attempting to push it back as I
> added it to our usage of BuildRoot.  To that end, shall I abandon
> the process (as I clearly am not willing to do it justice)?

No, you shouldn't abandon the process. Your contributions are very
welcome! I think you're very close to have something that can be
merged, just keep sending new revisions of your patch that takes into
account the comments from contributors.

> It is no skin off my nose whether it gets put into BuildRoot, I was
> only pushing it back as I didn't know it was there until someone else
> I work with pointed out that this *seems* to be the basic library GDB
> is based off of, thus could be useful in our embedded system.

Yes, it would certainly be useful.

Best regards,

Thomas

> > >  1) Did you check that it builds fine with uClibc? This kind of library
> > >  tend to use some funky C library features, sometimes not available in
> > >  uClibc.
> >
> > Nope, I didn't.
> 
> Then just do a build with a uClibc toolchain. If you don't want to wait
> for the toolchain to build, you can use
> http://autobuild.buildroot.org/toolchains/tarballs/br-arm-basic-2013.05-1.tar.bz2
> as an external toolchain. It's a basic ARM uClibc toolchain (with no
> option enabled: no WCHAR, no largefile, no IPv6, no RPC, no locales).

Had some time to fool around with this.  A couple of things to note:

execinfo.h STILL doesn't end up in the toolchain when building uClibc.
Copying that file over to the toolchain gets past that, however, there
are a other errors:

../src/.libs/libunwind.so: undefined reference to `sigreturn'
../src/.libs/libunwind.so: undefined reference to `setcontext'
collect2: error: ld returned 1 exit status
../src/.libs/libunwind-x86.so: undefined reference to `sigreturn'
../src/.libs/libunwind-x86.so: undefined reference to `setcontext'
collect2: error: ld returned 1 exit status
../src/.libs/libunwind-x86.so: undefined reference to `sigreturn'
../src/.libs/libunwind-x86.so: undefined reference to `setcontext'
collect2: error: ld returned 1 exit status

I'm wondering whether these are configuration issues with uClibc, or if
these various symbols are never available in uClibc.  Anyone know?

Pending the outcome of that question, I'll put in the config a
dependency of !BR2_TOOLCHAIN_*_<uclibc>.

Andy

Dear ANDY KENNEDY,

On Tue, 25 Jun 2013 21:41:44 +0000, ANDY KENNEDY wrote:
> Signed-off-by:  Andy Kennedy <andy.kennedy@adtran.com>

Thanks, applied with a few additional fixes.

Thomas