Patchwork libtool: Put all libltdl headers in the correct libltdl-dev package

On Tue, 2012-01-17 at 11:37 -0800, Saul Wold wrote:

> > https://github.com/cgwalters/poky/commit/0255ac2e95bb5230f7fdf1b861be0b97b01f2ecf
> >
> Yes, this will work better in the future, let me know the github branch 
> that contains your patch against oe-core or poky master (which ever you 
> prefer).

I've uploaded all of my current patches to the "edison" branch here:
https://github.com/cgwalters/poky

There's a new one there for bash:

https://github.com/cgwalters/poky/commit/84549cb9435fe1bec38a18e1fe6daf350351cd5a

From 84549cb9435fe1bec38a18e1fe6daf350351cd5a Mon Sep 17 00:00:00 2001
From: Colin Walters <walters@verbum.org>
Date: Wed, 18 Jan 2012 14:45:21 -0500
Subject: [PATCH] bash: Ensure we use glibc getcwd(), not builtin copy

My build system runs in a chroot, and then creates bind mounts
that point outside of the chroot.  The bash implementation of getcwd()
breaks badly on this.

glibc has a perfectly working version which on modern Linux simply
invokes the getcwd() system call.  However, when cross compiling,
bash's configure script gives up, and so defers to its built in
version.

I'm not sure whether dietlibc/uclibc will malloc as bash wants, so
this patch may not be applicable everywhere.  Probably a better fix
would be for bash to detect glibc's get_current_dir_name() and use it.
---
 meta/recipes-extended/bash/bash.inc |    6 +++++-
 1 files changed, 5 insertions(+), 1 deletions(-)

On 01/18/2012 11:58 AM, Colin Walters wrote:
> On Tue, 2012-01-17 at 11:37 -0800, Saul Wold wrote:
>
>>> https://github.com/cgwalters/poky/commit/0255ac2e95bb5230f7fdf1b861be0b97b01f2ecf
>>>
>> Yes, this will work better in the future, let me know the github branch
>> that contains your patch against oe-core or poky master (which ever you
>> prefer).
>
> I've uploaded all of my current patches to the "edison" branch here:
> https://github.com/cgwalters/poky
>
Colin,

So are you asking that we pull all these changes into oe-core or this is 
the change set you have made for your system?  I guess I am alittle unclear.

Also, if you want items into OE-Core, you should ensure they are based 
against oe-core master.

Thanks

Sau!

> There's a new one there for bash:
>
> https://github.com/cgwalters/poky/commit/84549cb9435fe1bec38a18e1fe6daf350351cd5a
>
>> From 84549cb9435fe1bec38a18e1fe6daf350351cd5a Mon Sep 17 00:00:00 2001
> From: Colin Walters<walters@verbum.org>
> Date: Wed, 18 Jan 2012 14:45:21 -0500
> Subject: [PATCH] bash: Ensure we use glibc getcwd(), not builtin copy
>
> My build system runs in a chroot, and then creates bind mounts
> that point outside of the chroot.  The bash implementation of getcwd()
> breaks badly on this.
>
> glibc has a perfectly working version which on modern Linux simply
> invokes the getcwd() system call.  However, when cross compiling,
> bash's configure script gives up, and so defers to its built in
> version.
>
> I'm not sure whether dietlibc/uclibc will malloc as bash wants, so
> this patch may not be applicable everywhere.  Probably a better fix
> would be for bash to detect glibc's get_current_dir_name() and use it.
> ---
>   meta/recipes-extended/bash/bash.inc |    6 +++++-
>   1 files changed, 5 insertions(+), 1 deletions(-)
>
> diff --git a/meta/recipes-extended/bash/bash.inc
> b/meta/recipes-extended/bash/bash.inc
> index 876be1e..f5a480a 100644
> --- a/meta/recipes-extended/bash/bash.inc
> +++ b/meta/recipes-extended/bash/bash.inc
> @@ -14,7 +14,11 @@ PARALLEL_MAKE = ""
>   bindir = "/bin"
>   sbindir = "/sbin"
>
> -EXTRA_OECONF = "--enable-job-control"
> +# Override getcwd_malloc because the copy of getcwd()
> +# in bash blows up when run inside a chroot and a bind
> +# mount pointing outside.  This assumes we're using eglibc.
> +EXTRA_OECONF = "--enable-job-control bash_cv_getcwd_malloc=yes "
> +
>   export CC_FOR_BUILD = "${BUILD_CC}"
>
>   ALTERNATIVE_NAME = "sh"

On Wed, 2012-01-18 at 12:32 -0800, Saul Wold wrote:

> So are you asking that we pull all these changes into oe-core or this is 
> the change set you have made for your system?  I guess I am alittle unclear.

Not all of them; I have the hack-around to remove -dev dependency chain
in there for example.  I've been sending here the ones that are pure
bugfixes.

> Also, if you want items into OE-Core, you should ensure they are based 
> against oe-core master.

Ok.  It'll take me a bit to set up a build/test environment for it.