audiofile: needs dynamic library

From: Simon Dawson <spdawson@gmail.com>

Fixes build failures such as the following.

  http://autobuild.buildroot.net/results/c00/c002711ef82fb29f1765df251bd0006caeccc508/

Signed-off-by: Simon Dawson <spdawson@gmail.com>
---
 package/audiofile/Config.in | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

>>>>> "spdawson" == spdawson  <spdawson@gmail.com> writes:

> From: Simon Dawson <spdawson@gmail.com>
> Fixes build failures such as the following.

>   http://autobuild.buildroot.net/results/c00/c002711ef82fb29f1765df251bd0006caeccc508/

> Signed-off-by: Simon Dawson <spdawson@gmail.com>
> ---
>  package/audiofile/Config.in | 5 +++--
>  1 file changed, 3 insertions(+), 2 deletions(-)

> diff --git a/package/audiofile/Config.in b/package/audiofile/Config.in
> index 4aa8d69..9752648 100644
> --- a/package/audiofile/Config.in
> +++ b/package/audiofile/Config.in
> @@ -1,11 +1,12 @@
>  config BR2_PACKAGE_AUDIOFILE
>  	bool "audiofile"
>  	depends on BR2_INSTALL_LIBSTDCPP
> +	depends on !BR2_PREFER_STATIC_LIB
>  	help
>  	  The Audio File Library handles reading and writing audio files
>  	  in many common formats.
 
>  	  http://www.68k.org/~michael/audiofile/
 
> -comment "audiofile needs a toolchain w/ C++"
> -	depends on !BR2_INSTALL_LIBSTDCPP
> +comment "audiofile needs a toolchain w/ C++, dynamic library"
> +	depends on !BR2_INSTALL_LIBSTDCPP || BR2_PREFER_STATIC_LIB

Thanks, but you forgot the reverse dependencies:

git grep -l 'select BR2_PACKAGE_AUDIOFILE'
package/mpd/Config.in

Looking at the build log, the only reason why it fails is that libtool
is acting up. It wants to link with libstdc++.so instead of libstdc++.a.

A quick test shows that you can fix it by passing -static instead of
--static in LDFLAGS, but that effectively reverts 0a4bd19f4a136930c:

http://git.buildroot.net/buildroot/commit/?id=0a4bd19f4a136930c

Does anybody know what the right solution is?

On 11/12/2013 08:42 AM, Peter Korsgaard wrote:
> Looking at the build log, the only reason why it fails is that libtool
> is acting up. It wants to link with libstdc++.so instead of libstdc++.a.
> 
> A quick test shows that you can fix it by passing -static instead of
> --static in LDFLAGS, but that effectively reverts 0a4bd19f4a136930c:
> 
> http://git.buildroot.net/buildroot/commit/?id=0a4bd19f4a136930c
> 
> Does anybody know what the right solution is?

I think this is related to the nettle failure i've mentioned, after the
gcc conversion host-gcc-final isn't installing libstdc++.a, and after an
extra look it isn't even building it because of --disable-static in the
default CONFIGURE_CMDS.
So it'll never find a libstdc++.a for the internal toolchain in staging.
Regards.

Dear Gustavo Zacarias,

On Tue, 12 Nov 2013 08:56:20 -0300, Gustavo Zacarias wrote:
> On 11/12/2013 08:42 AM, Peter Korsgaard wrote:
> > Looking at the build log, the only reason why it fails is that
> > libtool is acting up. It wants to link with libstdc++.so instead of
> > libstdc++.a.
> > 
> > A quick test shows that you can fix it by passing -static instead of
> > --static in LDFLAGS, but that effectively reverts 0a4bd19f4a136930c:
> > 
> > http://git.buildroot.net/buildroot/commit/?id=0a4bd19f4a136930c
> > 
> > Does anybody know what the right solution is?
> 
> I think this is related to the nettle failure i've mentioned, after
> the gcc conversion host-gcc-final isn't installing libstdc++.a, and
> after an extra look it isn't even building it because of
> --disable-static in the default CONFIGURE_CMDS.
> So it'll never find a libstdc++.a for the internal toolchain in
> staging. Regards.

I'll try to have a look at this issue tonight.

Thomas

>>>>> "Gustavo" == Gustavo Zacarias <gustavo@zacarias.com.ar> writes:

> I think this is related to the nettle failure i've mentioned, after the
> gcc conversion host-gcc-final isn't installing libstdc++.a, and after an
> extra look it isn't even building it because of --disable-static in the
> default CONFIGURE_CMDS.
> So it'll never find a libstdc++.a for the internal toolchain in staging.
> Regards.

Yes, but I've just tested with an external toolchain where libstdc++.a
IS copied to staging, and same problem.

On 11/12/2013 09:23 AM, Peter Korsgaard wrote:

> Yes, but I've just tested with an external toolchain where libstdc++.a
> IS copied to staging, and same problem.

Yes, fixing libstdc++.a on the internal toolchain solves the nettle
issue, but it doesn't solve audiofile (tested here with a quick hack).
Regards.