[Buildroot] [PATCH] audiofile: does not build with static-only

[Buildroot] [PATCH] audiofile: does not build with static-only

[Luca Ceresoli]

Also propagate to its reverse dependency (audiofile module for mpd).

Fixes:
  http://autobuild.buildroot.net/results/327/327c18db4e5d0ddc2c72a4684e103c19a1405e50/
  http://autobuild.buildroot.org/results/c8b/c8b64588eebf0bd8d879881b65e9d8efde00397d/
  http://autobuild.buildroot.org/results/028/028a3b97d56674560b8aa90b6e44b2e91858a5cb/

Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>
---
 package/audiofile/Config.in | 5 +++--
 package/mpd/Config.in       | 4 ++++
 2 files changed, 7 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
diff --git a/package/mpd/Config.in b/package/mpd/Config.in
index 1bf7ad1..96a3885 100644
--- a/package/mpd/Config.in
+++ b/package/mpd/Config.in
@@ -40,10 +40,14 @@ config BR2_PACKAGE_MPD_AO
 config BR2_PACKAGE_MPD_AUDIOFILE
 	bool "audiofile"
 	select BR2_PACKAGE_AUDIOFILE
+	depends on !BR2_PREFER_STATIC_LIB # audiofile
 	help
 	  Enable audiofile input/streaming support.
 	  Select this if you want to play back WAV files.
 
+comment "audiofile needs a toolchain w/ dynamic library"
+	depends on BR2_PREFER_STATIC_LIB
+
 config BR2_PACKAGE_MPD_PULSEAUDIO
 	bool "pulseaudio"
 	depends on BR2_TOOLCHAIN_HAS_THREADS # pulseaudio
-- 
1.8.3.2

[Buildroot] [PATCH] audiofile: does not build with static-only

[Thomas Petazzoni]

Dear Luca Ceresoli,

On Sat, 24 May 2014 16:24:54 +0200, Luca Ceresoli wrote:
> Also propagate to its reverse dependency (audiofile module for mpd).
> 
> Fixes:
>   http://autobuild.buildroot.net/results/327/327c18db4e5d0ddc2c72a4684e103c19a1405e50/
>   http://autobuild.buildroot.org/results/c8b/c8b64588eebf0bd8d879881b65e9d8efde00397d/
>   http://autobuild.buildroot.org/results/028/028a3b97d56674560b8aa90b6e44b2e91858a5cb/
> 
> Signed-off-by: Luca Ceresoli <luca@lucaceresoli.net>

No, I disagree. The real problem is the fact that we pass --static
instead of -static when building statically, so libtool turns -lstdc++
into a full path to libstdc++.so instead of libstdc++.a.

The real fix is to understand why we switched from -static to --static
a few years ago: there is a commit from Andy Kennedy making this
change, but the commit log is quite fuzzy about why this is actually
needed.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] audiofile: does not build with static-only

[Gustavo Zacarias]

On 05/24/2014 01:45 PM, Thomas Petazzoni wrote:

> No, I disagree. The real problem is the fact that we pass --static
> instead of -static when building statically, so libtool turns -lstdc++
> into a full path to libstdc++.so instead of libstdc++.a.
> 
> The real fix is to understand why we switched from -static to --static
> a few years ago: there is a commit from Andy Kennedy making this
> change, but the commit log is quite fuzzy about why this is actually
> needed.

Hi.
As we discussed with Thomas on IRC i've been digging and testing a bit
and promised to write about my assorted notes for the static dilemma:

1) --static isn't the documented way to do it, not for libtool, ld or
gcc. Just reverting it makes audiofile happy (patch done).

2) --static (or the correct -static IMHO) is just added to LDFLAGS, that
won't help generic packages that link directly so it should live in
CFLAGS/CXXFLAGS as well (patch done).

3) BR2_PREFER_STATIC_LIB should be renamed and it's description changed
accordingly, we don't prefer, we want.
There's no configuration granularity possible to say "A, B, C dyn and D
static" and we really don't want to walk that path (Thomas mentioned he
has something done about this already).

4) host-gcc-final always builds shared even if we want static, that
seems to cause issues for the internal toolchain but i'm unsure about
the reason (patch done).

5) libiconv tries to build the preloadable version even for static
targets, that's not possible (patch done).

6) The uclibc package tries to install ld* tools even for static builds,
that's no problem yet but it will be once/if we don't build a
shared+static version (patch done).

7) toolchain-external seems to be copying .so files to staging and
causing confusion for a mpd w/audiofile project: /usr/bin/mpd results in
a static binary, however some accesory binaries are not (example: gdbus,
gettext, others).

It's a WIP patchset, i want to work it out a little bit more before
sending it unless someone has an itch in helping out immediately ;)
Some of the patches i think are pretty clear-cut for -next and i'll be
sending them out.

Regards.

[Buildroot] [PATCH] audiofile: does not build with static-only

[Peter Korsgaard]

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

Hi,

 > As we discussed with Thomas on IRC i've been digging and testing a bit
 > and promised to write about my assorted notes for the static dilemma:

[snip]

 > It's a WIP patchset, i want to work it out a little bit more before
 > sending it unless someone has an itch in helping out immediately ;)
 > Some of the patches i think are pretty clear-cut for -next and i'll be
 > sending them out.

Thanks both for looking into it!

-- 
Bye, Peter Korsgaard

[Buildroot] [PATCH] audiofile: does not build with static-only

[Luca Ceresoli]

Hi Gustavo, Thomas,

Gustavo Zacarias wrote:
> On 05/24/2014 01:45 PM, Thomas Petazzoni wrote:
>
>> No, I disagree. The real problem is the fact that we pass --static
>> instead of -static when building statically, so libtool turns -lstdc++
>> into a full path to libstdc++.so instead of libstdc++.a.
>>
>> The real fix is to understand why we switched from -static to --static
>> a few years ago: there is a commit from Andy Kennedy making this
>> change, but the commit log is quite fuzzy about why this is actually
>> needed.
>
> Hi.
> As we discussed with Thomas on IRC i've been digging and testing a bit
> and promised to write about my assorted notes for the static dilemma:

Ah, I see, I hadn't followed that discussion and was not aware of such
work you're doing. Sorry for the noise and thanks for the detailed
clarification.

I understand the solution won't land in 2014.05.
I wonder what's the best thing to do in cases like this to make users
aware what there's a known bug in a release.

Should audiofile depend on BROKEN if BR2_PREFER_STATIC_LIB? This way it
would disappear from both the user's sight and the autobuilders, but
still visible via menuconfig search.

Or should we just add a comment that depends on audiofile and
BR2_PREFER_STATIC_LIB?

I think the former (o the sum of the two) is preferred. It would stop
polluting the autobuilders with known bugs and track the issue via
`git grep BROKEN`.

Helping in fixing this bug is out of reach for me, but I can at least
send a patch for BROKEN if it's the proper way to go.

-- 
Luca

[Buildroot] [PATCH] audiofile: does not build with static-only

[Gustavo Zacarias]

On 05/25/2014 06:00 PM, Luca Ceresoli wrote:

> Ah, I see, I hadn't followed that discussion and was not aware of such
> work you're doing. Sorry for the noise and thanks for the detailed
> clarification.
> 
> I understand the solution won't land in 2014.05.
> I wonder what's the best thing to do in cases like this to make users
> aware what there's a known bug in a release.
> 
> Should audiofile depend on BROKEN if BR2_PREFER_STATIC_LIB? This way it
> would disappear from both the user's sight and the autobuilders, but
> still visible via menuconfig search.
> 
> Or should we just add a comment that depends on audiofile and
> BR2_PREFER_STATIC_LIB?
> 
> I think the former (o the sum of the two) is preferred. It would stop
> polluting the autobuilders with known bugs and track the issue via
> `git grep BROKEN`.
> 
> Helping in fixing this bug is out of reach for me, but I can at least
> send a patch for BROKEN if it's the proper way to go.

Doing anything for 2014.05 at this point would be band aid, audiofile is
the usual failing package because it sorts nicely at the beginning, but
there are other packages that will show up if it's blacklisted.
Maybe removing static builds from the testing rotation would be nice,
but then we want to find broken stuff :)
Regards.

[Buildroot] [PATCH] audiofile: does not build with static-only

[Thomas Petazzoni]

Dear Gustavo Zacarias,

On Sat, 24 May 2014 20:13:19 -0300, Gustavo Zacarias wrote:

> As we discussed with Thomas on IRC i've been digging and testing a bit
> and promised to write about my assorted notes for the static dilemma:
> 
> 1) --static isn't the documented way to do it, not for libtool, ld or
> gcc. Just reverting it makes audiofile happy (patch done).
> 
> 2) --static (or the correct -static IMHO) is just added to LDFLAGS, that
> won't help generic packages that link directly so it should live in
> CFLAGS/CXXFLAGS as well (patch done).

--static or -static ?

> 3) BR2_PREFER_STATIC_LIB should be renamed and it's description changed
> accordingly, we don't prefer, we want.
> There's no configuration granularity possible to say "A, B, C dyn and D
> static" and we really don't want to walk that path (Thomas mentioned he
> has something done about this already).

Yes. But it needs some testing. I'll post this for 2014.08.

> 7) toolchain-external seems to be copying .so files to staging and
> causing confusion for a mpd w/audiofile project: /usr/bin/mpd results in
> a static binary, however some accesory binaries are not (example: gdbus,
> gettext, others).

Hum, ok, I think I should have a look at this one.

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com

[Buildroot] [PATCH] audiofile: does not build with static-only

[Arnout Vandecappelle]

[I hope my FIFO reading is not going to cause me to make more duplicate comments..]

On 25/05/14 23:00, Luca Ceresoli wrote:
> Hi Gustavo, Thomas,
> 
> Gustavo Zacarias wrote:
>> On 05/24/2014 01:45 PM, Thomas Petazzoni wrote:
>>
>>> No, I disagree. The real problem is the fact that we pass --static
>>> instead of -static when building statically, so libtool turns -lstdc++
>>> into a full path to libstdc++.so instead of libstdc++.a.
>>>
>>> The real fix is to understand why we switched from -static to --static
>>> a few years ago: there is a commit from Andy Kennedy making this
>>> change, but the commit log is quite fuzzy about why this is actually
>>> needed.
>>
>> Hi.
>> As we discussed with Thomas on IRC i've been digging and testing a bit
>> and promised to write about my assorted notes for the static dilemma:
> 
> Ah, I see, I hadn't followed that discussion and was not aware of such
> work you're doing. Sorry for the noise and thanks for the detailed
> clarification.

 Yeah, much better clarification than what I said this morning :-)

> 
> I understand the solution won't land in 2014.05.
> I wonder what's the best thing to do in cases like this to make users
> aware what there's a known bug in a release.
> 
> Should audiofile depend on BROKEN if BR2_PREFER_STATIC_LIB? This way it
> would disappear from both the user's sight and the autobuilders, but
> still visible via menuconfig search.
> 
> Or should we just add a comment that depends on audiofile and
> BR2_PREFER_STATIC_LIB?

 I think it's better if we start having release notes for these kinds of known
issues. This could actually be part of the CHANGES file, but then we should make
a habit of including updates to the CHANGES file when submitting patches. Or it
could be part of the documentation. Or of course a separate ReleaseNotes file.
For sure, it must be something that is easily googlable.

 Deprecated .config symbols (i.e. the legacy stuff) should also be in these
release notes.


 Regards,
 Arnout

> 
> I think the former (o the sum of the two) is preferred. It would stop
> polluting the autobuilders with known bugs and track the issue via
> `git grep BROKEN`.
> 
> Helping in fixing this bug is out of reach for me, but I can at least
> send a patch for BROKEN if it's the proper way to go.
> 


-- 
Arnout Vandecappelle                          arnout at mind be
Senior Embedded Software Architect            +32-16-286500
Essensium/Mind                                http://www.mind.be
G.Geenslaan 9, 3001 Leuven, Belgium           BE 872 984 063 RPR Leuven
LinkedIn profile: http://www.linkedin.com/in/arnoutvandecappelle
GPG fingerprint:  7CB5 E4CC 6C2E EFD4 6E3D A754 F963 ECAB 2450 2F1F

[Buildroot] [PATCH] audiofile: does not build with static-only

[Thomas Petazzoni]

Dear Arnout Vandecappelle,

On Wed, 28 May 2014 18:15:31 +0200, Arnout Vandecappelle wrote:

>  I think it's better if we start having release notes for these kinds of known
> issues. This could actually be part of the CHANGES file, but then we should make
> a habit of including updates to the CHANGES file when submitting patches. Or it
> could be part of the documentation. Or of course a separate ReleaseNotes file.
> For sure, it must be something that is easily googlable.

Like http://buildroot.org/downloads/manual/manual.html#_known_issues ?

Thomas
-- 
Thomas Petazzoni, CTO, Free Electrons
Embedded Linux, Kernel and Android engineering
http://free-electrons.com