Build failure for armhf/armmp, linux 3.11-rc4

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Build failure for armhf/armmp, linux 3.11-rc4

Ben Hutchings-3
The build of linux 3.11~rc4-1~exp1
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armhf&ver=3.11~rc4-1~exp1&stamp=1376523445
ended with errors from modpost:

ERROR: "imx_pcm_fiq_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_fiq_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!

These functions are defined in sound/soc/fsl/imx-pcm-{dma,fiq}.c which
are compiled into this kernel image.  And the functions are exported.
Any ideas why this is failing?

Ben.

--
Ben Hutchings
I haven't lost my mind; it's backed up on tape somewhere.


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/1376605237.11042.16.camel@...

Reply | Threaded
Open this post in threaded view
|

Re: Build failure for armhf/armmp, linux 3.11-rc4

Robert Nelson-4
On Thu, Aug 15, 2013 at 5:20 PM, Ben Hutchings <[hidden email]> wrote:

> The build of linux 3.11~rc4-1~exp1
> https://buildd.debian.org/status/fetch.php?pkg=linux&arch=armhf&ver=3.11~rc4-1~exp1&stamp=1376523445
> ended with errors from modpost:
>
> ERROR: "imx_pcm_fiq_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
> ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
> ERROR: "imx_pcm_fiq_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
> ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-imx-ssi.ko] undefined!
> ERROR: "imx_pcm_dma_init" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
> ERROR: "imx_pcm_dma_exit" [sound/soc/fsl/snd-soc-fsl-ssi.ko] undefined!
>
> These functions are defined in sound/soc/fsl/imx-pcm-{dma,fiq}.c which
> are compiled into this kernel image.  And the functions are exported.
> Any ideas why this is failing?

Ben,

This is fixed in the sound next branch:

https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=for-next&id=3f1a91aa25579ba5e7268a47a73d2a83e4802c62

for v3.11-rc5 i just have them both built-in..

CONFIG_SND_SOC_IMX_SSI=y
CONFIG_SND_SOC_IMX_PCM_DMA=y

But after a quick search i couldn't find your v3.11-rc5 config to do a
full config diff..

Regards,

--
Robert Nelson
http://www.rcn-ee.com/


--
To UNSUBSCRIBE, email to [hidden email]
with a subject of "unsubscribe". Trouble? Contact [hidden email]
Archive: http://lists.debian.org/CAOCHtYiPKQ-pD8ZMFRKx6io5i+UbGCN37c-Tir3ZDtYtidOLLA@...

Reply | Threaded
Open this post in threaded view
|

Re: Build failure for armhf/armmp, linux 3.11-rc4

Mark Brown-2
On 16 August 2013 09:42, Ben Hutchings <[hidden email]> wrote:

Please use the advertised e-mail addresses for maintainers.

On Thu, 2013-08-15 at 19:16 -0500, Robert Nelson wrote:
> This is fixed in the sound next branch:
>
> https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=for-next&id=3f1a91aa25579ba5e7268a47a73d2a83e4802c62

The explanation doesn't make sense to me.

And if these files are built and then loaded as modules, they will taint
the kernel as they have no MODULE_LICENSE.

I doubt many people are actually building them as modules except for compile testing or with another reason for the kernel to be tainted.

CONFIG_SND_SOC_IMX_AUDMUX=m
CONFIG_SND_SOC_EUKREA_TLV320=m
# CONFIG_SND_SOC_IMX_WM8962 is not set

There seem to be a reasonable number of boards out there using that driver. 

Reply | Threaded
Open this post in threaded view
|

Re: Build failure for armhf/armmp, linux 3.11-rc4

Ben Hutchings-3
On Fri, 2013-08-16 at 11:34 +0100, Mark Brown wrote:
> On 16 August 2013 09:42, Ben Hutchings <[hidden email]> wrote:
>
>
> Please use the advertised e-mail addresses for maintainers.

Expand, please?  I took your address from the commit that Robert pointed
out.

>         On Thu, 2013-08-15 at 19:16 -0500, Robert Nelson wrote:
>         > This is fixed in the sound next branch:
>         >
>         >
>         https://git.kernel.org/cgit/linux/kernel/git/broonie/sound.git/commit/?h=for-next&id=3f1a91aa25579ba5e7268a47a73d2a83e4802c62
>        
>         The explanation doesn't make sense to me.
>        
>         And if these files are built and then loaded as modules, they
>         will taint
>         the kernel as they have no MODULE_LICENSE.
>
>
> I doubt many people are actually building them as modules except for
> compile testing or with another reason for the kernel to be tainted.
In a multi-platform config I think this will now be the *normal* state,
as the dependent drivers should be modules.

I'm still failing to see *how* that fix works, anyway.  Seems like a
workaround for some other problem.

Ben.

>         CONFIG_SND_SOC_IMX_AUDMUX=m
>         CONFIG_SND_SOC_EUKREA_TLV320=m
>         # CONFIG_SND_SOC_IMX_WM8962 is not set
>
>
> There seem to be a reasonable number of boards out there using that
> driver.
>
>

--
Ben Hutchings
Teamwork is essential - it allows you to blame someone else.

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build failure for armhf/armmp, linux 3.11-rc4

Mark Brown
On Sat, Aug 17, 2013 at 06:25:44PM +0200, Ben Hutchings wrote:
> On Fri, 2013-08-16 at 11:34 +0100, Mark Brown wrote:

> > Please use the advertised e-mail addresses for maintainers.

> Expand, please?  I took your address from the commit that Robert pointed
> out.

You're better off with MAINTAINERS - several people advertise and use
non-work e-mail addresses but sign off with a work one.

> > I doubt many people are actually building them as modules except for
> > compile testing or with another reason for the kernel to be tainted.

> In a multi-platform config I think this will now be the *normal* state,
> as the dependent drivers should be modules.

The point is that I rather doubt anyone working on the drivers cares so
long as they build in modular configurations.

> I'm still failing to see *how* that fix works, anyway.  Seems like a
> workaround for some other problem.

Could you be more specific as to what you believe the problem that
exists is?  You mentioned that the kernel would be tainted but that
doesn't seem like a not working thing...

signature.asc (853 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build failure for armhf/armmp, linux 3.11-rc4

Ben Hutchings-3
On Mon, 2013-08-19 at 11:41 +0100, Mark Brown wrote:

> On Sat, Aug 17, 2013 at 06:25:44PM +0200, Ben Hutchings wrote:
> > On Fri, 2013-08-16 at 11:34 +0100, Mark Brown wrote:
>
> > > Please use the advertised e-mail addresses for maintainers.
>
> > Expand, please?  I took your address from the commit that Robert pointed
> > out.
>
> You're better off with MAINTAINERS - several people advertise and use
> non-work e-mail addresses but sign off with a work one.
>
> > > I doubt many people are actually building them as modules except for
> > > compile testing or with another reason for the kernel to be tainted.
>
> > In a multi-platform config I think this will now be the *normal* state,
> > as the dependent drivers should be modules.
>
> The point is that I rather doubt anyone working on the drivers cares so
> long as they build in modular configurations.
>
> > I'm still failing to see *how* that fix works, anyway.  Seems like a
> > workaround for some other problem.
>
> Could you be more specific as to what you believe the problem that
> exists is?  You mentioned that the kernel would be tainted but that
> doesn't seem like a not working thing...
The problem explained in the commit message for commit
3f1a91aa25579ba5e7268a47a73d2a83e4802c62.

imx-pcm-{dma,fiq}.o are exporting various symbols used by
snd-soc-{fsl,imx}-ssi.o.  Obviously, a module can use symbols exported
from both built-in and modular code.  And yet for some reason this
didn't work when the exports were built-in and did work when they were
built as modules.

Ben.

--
Ben Hutchings
The obvious mathematical breakthrough [to break modern encryption] would be
development of an easy way to factor large prime numbers. - Bill Gates

signature.asc (845 bytes) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: Build failure for armhf/armmp, linux 3.11-rc4

Mark brown-22
On Tue, Aug 20, 2013 at 01:39:40AM +0200, Ben Hutchings wrote:
> On Mon, 2013-08-19 at 11:41 +0100, Mark Brown wrote:

> > Could you be more specific as to what you believe the problem that
> > exists is?  You mentioned that the kernel would be tainted but that
> > doesn't seem like a not working thing...

> The problem explained in the commit message for commit
> 3f1a91aa25579ba5e7268a47a73d2a83e4802c62.

That's "ASoC: fsl: Fix module build".

> imx-pcm-{dma,fiq}.o are exporting various symbols used by
> snd-soc-{fsl,imx}-ssi.o.  Obviously, a module can use symbols exported
> from both built-in and modular code.  And yet for some reason this
> didn't work when the exports were built-in and did work when they were
> built as modules.

I'm afraid I still lack the context to understand what the issue you're
trying to report here is, possibly because I've forgotten some of the
context from earlier on in the thread.  That commit is fixing the fact
that the relevant functions were ifdefed with CONFIG_FOO but not
CONFIG_FOO_MODULE but it seems to fix that fairly directly?

signature.asc (853 bytes) Download Attachment