audiofile: does not build with static-only
PATCH 1/1 audiofile: does not build with static-only
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/
--- package/audiofile/Config.in | 5 +++-- package/mpd/Config.in | 4 ++++ 2 files changed, 7 insertions(+), 2 deletions(-)
package/audiofile/Config.in +3 -2
@@ -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
package/mpd/Config.in +4 -0
@@ -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
Signature · 1 line
1.8.3.2
PATCH 1/1 audiofile: does not build with static-only
Dear Luca Ceresoli,
Quoted 8 lines · 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 <[email protected]>
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 audiofile: does not build with static-only
Quoted 8 lines · Thomas Petazzoni
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.
PATCH 1/1 audiofile: does not build with static-only
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
Quoted 1 line
"Gustavo" == Gustavo Zacarias <[email protected]> writes:
Hi,
Quoted 2 lines
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]
Quoted 4 lines
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!
Signature · 1 line
Bye, Peter Korsgaard
PATCH 1/1 audiofile: does not build with static-only
In reply to Gustavo ZacariasHi Gustavo, Thomas,
Quoted 6 lines · Gustavo Zacarias
Quoted 4 lines · Thomas Petazzoni
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.
Quoted 8 lines
Quoted 4 lines
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.
Signature · 1 line
Luca
PATCH 1/1 audiofile: does not build with static-only
Quoted 15 lines · Luca Ceresoli
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?
Quoted 6 lines
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.
PATCH 1/1 audiofile: does not build with static-only
In reply to Luca Ceresoli[I hope my FIFO reading is not going to cause me to make more duplicate comments..]
Quoted 14 lines · Luca Ceresoli
Hi Gustavo, Thomas,
Quoted 11 lines · Gustavo Zacarias
Quoted 8 lines · Thomas Petazzoni
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.
Quoted 7 lines
Quoted 3 lines
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 :-)
Quoted 11 lines
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
Quoted 8 lines
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.
Signature · 6 lines
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
PATCH 1/1 audiofile: does not build with static-only
Dear Arnout Vandecappelle,
Quoted 5 lines · Arnout Vandecappelle
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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com
PATCH 1/1 audiofile: does not build with static-only
In reply to Gustavo ZacariasDear Gustavo Zacarias,
Quoted 9 lines · Gustavo Zacarias
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 ?
Quoted 5 lines
3)
BR2_PREFER_STATIC_LIBshould 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.
Quoted 4 lines
7) toolchain-external seems to be copying .so files to staging and causing confusion for a mpd w/audiofile project:
/usr/bin/mpdresults 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
Signature · 3 lines
Thomas Petazzoni, CTO, Free Electrons Embedded Linux, Kernel and Android engineering http://free-electrons.com