Message ID | 1414515902-3153-1-git-send-email-Vincent.Riera@imgtec.com |
---|---|
State | Superseded |
Headers | show |
On 10/28/2014 02:05 PM, Vicente Olivert Riera wrote: > Building lame with debug symbols needs the following macros to be > defined: _FPU_MASK_IM, _FPU_MASK_ZM, _FPU_MASK_OM. > If BR2_ENABLE_DEBUG is selected, then we have to disable lame for > Aarch64 and MIPS because these architectures don't have those macros > defined. > > Fixes: > http://autobuild.buildroot.net/results/721/721dff299b204b1d3ccc0846009eb17faa2d29eb/ > > Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> > --- > package/lame/Config.in | 7 +++++++ > 1 files changed, 7 insertions(+), 0 deletions(-) What happens when another package that uses lame selects it? (like mpd, gst-plugins-ugly, gst1-plugins-ugly). Regards.
On 10/28/2014 05:15 PM, Gustavo Zacarias wrote: > On 10/28/2014 02:05 PM, Vicente Olivert Riera wrote: > >> Building lame with debug symbols needs the following macros to be >> defined: _FPU_MASK_IM, _FPU_MASK_ZM, _FPU_MASK_OM. >> If BR2_ENABLE_DEBUG is selected, then we have to disable lame for >> Aarch64 and MIPS because these architectures don't have those macros >> defined. >> >> Fixes: >> http://autobuild.buildroot.net/results/721/721dff299b204b1d3ccc0846009eb17faa2d29eb/ >> >> Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> >> --- >> package/lame/Config.in | 7 +++++++ >> 1 files changed, 7 insertions(+), 0 deletions(-) > > What happens when another package that uses lame selects it? (like mpd, > gst-plugins-ugly, gst1-plugins-ugly). > Regards. > You are right, the dependences should be propagated to those packages. I will respin a new version. My apologies for that.
On 10/28/2014 02:17 PM, Vicente Olivert Riera wrote: > You are right, the dependences should be propagated to those packages. I > will respin a new version. > > My apologies for that. It's more of an open question, i don't think we want to go dependency hell on this. We could probably just disable debugging for the particular package on the particular conditions i think. Regards.
Dear all, On 10/28/2014 05:18 PM, Gustavo Zacarias wrote: > On 10/28/2014 02:17 PM, Vicente Olivert Riera wrote: > >> You are right, the dependences should be propagated to those packages. I >> will respin a new version. >> >> My apologies for that. > > It's more of an open question, i don't think we want to go dependency > hell on this. > We could probably just disable debugging for the particular package on > the particular conditions i think. > Regards. Uhm..., yeah, to be honest that was my first thought when I found what was the problem. I'm fine with that. Let's wait until some other developers say their opinion as well. Best regards,
On 28/10/14 18:23, Vicente Olivert Riera wrote: > Dear all, > > On 10/28/2014 05:18 PM, Gustavo Zacarias wrote: > > On 10/28/2014 02:17 PM, Vicente Olivert Riera wrote: > > > >> You are right, the dependences should be propagated to those packages. I > >> will respin a new version. > >> > >> My apologies for that. > > > > It's more of an open question, i don't think we want to go dependency > > hell on this. > > We could probably just disable debugging for the particular package on > > the particular conditions i think. > > Regards. > > Uhm..., yeah, to be honest that was my first thought when I found what was the > problem. > > I'm fine with that. Let's wait until some other developers say their opinion as > well. I agree that that is the way to go: disable debug on the architectures that have a problem with it. Regards, Arnout > > Best regards,
Dear all, On 10/28/2014 10:04 PM, Arnout Vandecappelle wrote: > On 28/10/14 18:23, Vicente Olivert Riera wrote: >> Dear all, >> >> On 10/28/2014 05:18 PM, Gustavo Zacarias wrote: >>> On 10/28/2014 02:17 PM, Vicente Olivert Riera wrote: >>> >>>> You are right, the dependences should be propagated to those packages. I >>>> will respin a new version. >>>> >>>> My apologies for that. >>> >>> It's more of an open question, i don't think we want to go dependency >>> hell on this. >>> We could probably just disable debugging for the particular package on >>> the particular conditions i think. >>> Regards. >> >> Uhm..., yeah, to be honest that was my first thought when I found what was the >> problem. >> >> I'm fine with that. Let's wait until some other developers say their opinion as >> well. > > I agree that that is the way to go: disable debug on the architectures that > have a problem with it. > > > Regards, > Arnout > >> >> Best regards, Thanks for your opinion Arnout. Patch v2 sent: http://patchwork.ozlabs.org/patch/404494/ Best regards,
diff --git a/package/lame/Config.in b/package/lame/Config.in index 2b144a0..c2cf979 100644 --- a/package/lame/Config.in +++ b/package/lame/Config.in @@ -1,5 +1,12 @@ config BR2_PACKAGE_LAME bool "lame" + # Building lame with debug symbols needs the following macros to be + # defined: _FPU_MASK_IM, _FPU_MASK_ZM, _FPU_MASK_OM. + # If BR2_ENABLE_DEBUG is selected, then we have to disable lame for + # Aarch64 and MIPS because these architectures don't have those + # macros defined. + depends on !(BR2_ENABLE_DEBUG && (BR2_aarch64 || BR2_mips || \ + BR2_mipsel || BR2_mips64 || BR2_mips64el)) help LAME is a high quality MPEG Audio Layer III (MP3) encoder.
Building lame with debug symbols needs the following macros to be defined: _FPU_MASK_IM, _FPU_MASK_ZM, _FPU_MASK_OM. If BR2_ENABLE_DEBUG is selected, then we have to disable lame for Aarch64 and MIPS because these architectures don't have those macros defined. Fixes: http://autobuild.buildroot.net/results/721/721dff299b204b1d3ccc0846009eb17faa2d29eb/ Signed-off-by: Vicente Olivert Riera <Vincent.Riera@imgtec.com> --- package/lame/Config.in | 7 +++++++ 1 files changed, 7 insertions(+), 0 deletions(-)