compilation errors

compilation errors

[Jean-Francois Moine]

Hi all,

There should be something I missed in the linuxtv documents.

When I do a simple 'make', in v4l, it generates almost all the .ko files
of the modules of the first level. But I cannot find, for example, any
v4l2-common.ko, nor tuner-simple.ko.

Then, I linked by hand the tree to my kernel (2.6.26-rc8). I thought
some links only were needed, so I linked:
	drivers/media
	include/media
	include/linux/videodev2.h
A 'make' in the kernel tree stops with many warnings and errors, mainly:
	warning: "LINUX_VERSION_CODE" is not defined

Any hint? Thank you.

-- 
Ken ar c'hentañ |             ** Breizh ha Linux atav! **
Jef             |               http://moinejf.free.fr/


--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list

Compilation errors

[Fabio M. De Francesco]

Hello everybody,

I've made hundreds of Linux builds and never had problems, but since 
few days I'm not anymore able to compile the kernel with GCC or Clang.

I get many errors like the following and the build crashes:

# CC=gcc-11 make -j12
[...]
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function ‘bnx2x_check_blocks_with_parity3’:
drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:4917:4: error: case label does not reduce to an integer constant
    case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY:
[...]
make[5]: *** [scripts/Makefile.build:289: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.o] Error 1
make[4]: *** [scripts/Makefile.build:551: drivers/net/ethernet/broadcom/bnx2x] Error 2
make[4]: *** Waiting for unfinished jobs....

One more example...

# make mrproper
# CC=clang make -j12
[...]
drivers/usb/typec/tcpm/tcpm.c:4724:3: error: case label does not reduce to an integer constant
   case BDO_MODE_TESTDATA:
   ^~~~
make[4]: *** [scripts/Makefile.build:288: drivers/usb/typec/tcpm/tcpm.o] Error 1
make[3]: *** [scripts/Makefile.build:550: drivers/usb/typec/tcpm] Error 2
make[2]: *** [scripts/Makefile.build:550: drivers/usb/typec] Error 2
make[2]: *** Waiting for unfinished jobs....

Can someone help me to understand what is happening and how to fix this issue?
Could it depend on a configuration option that, unintentionally enabled, make 
the build fail whenever "case label does not reduce to an integer constant" is 
hit? If so, which option?

Thanks,

Fabio M. De Francesco

Re: Compilation errors

[Stefano Brivio]

Hi Fabio,

On Fri, 01 Apr 2022 11:35:13 +0200
"Fabio M. De Francesco" <fmdefrancesco@gmail.com> wrote:

> Hello everybody,
> 
> I've made hundreds of Linux builds and never had problems, but since 
> few days I'm not anymore able to compile the kernel with GCC or Clang.
> 
> I get many errors like the following and the build crashes:
> 
> # CC=gcc-11 make -j12
> [...]
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c: In function ‘bnx2x_check_blocks_with_parity3’:
> drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.c:4917:4: error: case label does not reduce to an integer constant
>     case AEU_INPUTS_ATTN_BITS_MCP_LATCHED_SCPAD_PARITY:
> [...]
> make[5]: *** [scripts/Makefile.build:289: drivers/net/ethernet/broadcom/bnx2x/bnx2x_main.o] Error 1
> make[4]: *** [scripts/Makefile.build:551: drivers/net/ethernet/broadcom/bnx2x] Error 2
> make[4]: *** Waiting for unfinished jobs....
> 
> One more example...
> 
> # make mrproper
> # CC=clang make -j12
> [...]
> drivers/usb/typec/tcpm/tcpm.c:4724:3: error: case label does not reduce to an integer constant
>    case BDO_MODE_TESTDATA:
>    ^~~~
> make[4]: *** [scripts/Makefile.build:288: drivers/usb/typec/tcpm/tcpm.o] Error 1
> make[3]: *** [scripts/Makefile.build:550: drivers/usb/typec/tcpm] Error 2
> make[2]: *** [scripts/Makefile.build:550: drivers/usb/typec] Error 2
> make[2]: *** Waiting for unfinished jobs....
> 
> Can someone help me to understand what is happening and how to fix this issue?
> Could it depend on a configuration option that, unintentionally enabled, make 
> the build fail whenever "case label does not reduce to an integer constant" is 
> hit? If so, which option?

Those would be warnings, but kernel builds switched to -Werror by
default a while ago, see commit 3fe617ccafd6 ("Enable '-Werror' by
default for all kernel builds") -- meaning that all warnings are
treated as errors. You can disable CONFIG_WERROR:

	scripts/config -d WERROR

to double check. But I guess you just found a source of very useful,
relatively trivial patches. :) Of course, chances are that some of
those are already fixed in some other tree.

As to why it started happening for you recently: maybe you just
switched to gcc 11 and a newer version of clang? Can you try with
gcc 10 if you have it still installed?

-- 
Stefano

Re: Compilation errors

[Fabio M. De Francesco]

On venerdì 1 aprile 2022 12:13:57 CEST Stefano Brivio wrote:
> Hi Fabio,
> 
> On Fri, 01 Apr 2022 11:35:13 +0200
> "Fabio M. De Francesco" <fmdefrancesco@gmail.com> wrote:
> >
> > [...]
> > 
> > Can someone help me to understand what is happening and how to fix this issue?
> > Could it depend on a configuration option that, unintentionally enabled, make 
> > the build fail whenever "case label does not reduce to an integer constant" is 
> > hit? If so, which option?
> 
> Those would be warnings, but kernel builds switched to -Werror by
> default a while ago, see commit 3fe617ccafd6 ("Enable '-Werror' by
> default for all kernel builds") -- meaning that all warnings are
> treated as errors. You can disable CONFIG_WERROR:
> 
> 	scripts/config -d WERROR
> 
> to double check. 

Hi Stefano,

Thanks for your prompt reply!

I know that the kernel has switched to -Werror by default. I use a largely 
customized .config and I can confirm you that CONFIG_WERROR is _not_ enabled:

xp4ns3@leap> grep CONFIG_WERROR .config
# CONFIG_WERROR is not set

>
> [...]
>
> As to why it started happening for you recently: maybe you just
> switched to gcc 11 and a newer version of clang? Can you try with
> gcc 10 if you have it still installed?

I had it not anymore installed, so I had to re-install gcc v10. With it
I ran "make clean && CC=gcc-10 make -j12" but it still triggers the same 
errors and the build still fails.

The last output line, just before exit, is:

make: *** [Makefile:1838: drivers] Error 2

Furthermore, I want to make you notice that I have no errors when I 
build Torvald's tree with gcc v11. In fact, I rebuilt it now again and 
got no failures.

Why is this issue showing only with staging-testing? I cannot yet see 
any reasonable explanation.

Any other ideas? If I'm not able to figure out what's happening, I won't
be able to contribute to staging anymore. Greg (reasonably) requires that
all the changes get built before sending patches, therefore, this issue
is a blocker. I'm losing the chance to be selected for the Outreachy
internship.

Since I have more or less 100 patches already in Torvald's tree, can I
be exempted from working on those 10 required patches for staging? 
Otherwise I could simply send 10 clean-up patches that I can confidently
send without trying to compile them. Or I can send patches for Torvald's
tree. I really don't know what to do.

As said above: any more ideas? 

Regards,

Fabio
 
> 
> -- 
> Stefano
> 

Re: Compilation errors

[Stefano Brivio]

On Fri, 01 Apr 2022 14:01:03 +0200
"Fabio M. De Francesco" <fmdefrancesco@gmail.com> wrote:

> On venerdì 1 aprile 2022 12:13:57 CEST Stefano Brivio wrote:
> > Hi Fabio,
> > 
> > On Fri, 01 Apr 2022 11:35:13 +0200
> > "Fabio M. De Francesco" <fmdefrancesco@gmail.com> wrote:  
> > >
> > > [...]
> > > 
> > > Can someone help me to understand what is happening and how to fix this issue?
> > > Could it depend on a configuration option that, unintentionally enabled, make 
> > > the build fail whenever "case label does not reduce to an integer constant" is 
> > > hit? If so, which option?  
> > 
> > Those would be warnings, but kernel builds switched to -Werror by
> > default a while ago, see commit 3fe617ccafd6 ("Enable '-Werror' by
> > default for all kernel builds") -- meaning that all warnings are
> > treated as errors. You can disable CONFIG_WERROR:
> > 
> > 	scripts/config -d WERROR
> > 
> > to double check.   
> 
> Hi Stefano,
> 
> Thanks for your prompt reply!
> 
> I know that the kernel has switched to -Werror by default. I use a largely 
> customized .config and I can confirm you that CONFIG_WERROR is _not_ enabled:
> 
> xp4ns3@leap> grep CONFIG_WERROR .config  
> # CONFIG_WERROR is not set
> 
> >
> > [...]
> >
> > As to why it started happening for you recently: maybe you just
> > switched to gcc 11 and a newer version of clang? Can you try with
> > gcc 10 if you have it still installed?  
> 
> I had it not anymore installed, so I had to re-install gcc v10. With it
> I ran "make clean && CC=gcc-10 make -j12" but it still triggers the same 
> errors and the build still fails.

Okay, then that's really an error.

> The last output line, just before exit, is:
> 
> make: *** [Makefile:1838: drivers] Error 2
> 
> Furthermore, I want to make you notice that I have no errors when I 
> build Torvald's tree with gcc v11. In fact, I rebuilt it now again and 
> got no failures.
> 
> Why is this issue showing only with staging-testing? I cannot yet see 
> any reasonable explanation.

It might simply be that the you're building some drivers on your
staging tree that you're not building on the mainline tree.

> Any other ideas? If I'm not able to figure out what's happening, I won't
> be able to contribute to staging anymore. Greg (reasonably) requires that
> all the changes get built before sending patches, therefore, this issue
> is a blocker. I'm losing the chance to be selected for the Outreachy
> internship.

You reported this issue three hours ago and, as far as I can tell,
there are 672 hours in four weeks...

> Since I have more or less 100 patches already in Torvald's tree, can I
> be exempted from working on those 10 required patches for staging? 
> Otherwise I could simply send 10 clean-up patches that I can confidently
> send without trying to compile them. Or I can send patches for Torvald's
> tree. I really don't know what to do.

...well, then you could also try to debug this build issue I guess? On
which drivers it happens? You reported two. If you disable those two,
will it still happen? On how many? And what about fixing those cases?

-- 
Stefano

Re: Compilation errors

[Fabio M. De Francesco]

On venerdì 1 aprile 2022 14:57:14 CEST Stefano Brivio wrote:
> 
> Okay, then that's really an error.
> 
> It might simply be that the you're building some drivers on your
> staging tree that you're not building on the mainline tree.

Yes, this is why I've decided to use the .config that I have in Torvald's 
tree. They should only differ for the drivers/staging part and the suffix 
for vmlinuz.

Now it builds correctly with gcc11 :)

I must look carefully at the diff between the two files and figure out
what doesn't work.

However what really counts is that now I can go back to work with "staging".

Thanks for your time,

Fabio 

Re: Compilation errors

[Alison Schofield]

On Fri, Apr 01, 2022 at 03:07:24PM +0200, Fabio M. De Francesco wrote:
> On venerdì 1 aprile 2022 14:57:14 CEST Stefano Brivio wrote:
> > 
> > Okay, then that's really an error.
> > 
> > It might simply be that the you're building some drivers on your
> > staging tree that you're not building on the mainline tree.
> 
> Yes, this is why I've decided to use the .config that I have in Torvald's 
> tree. They should only differ for the drivers/staging part and the suffix 
> for vmlinuz.
> 
> Now it builds correctly with gcc11 :)
> 
> I must look carefully at the diff between the two files and figure out
> what doesn't work.
> 
> However what really counts is that now I can go back to work with "staging".
> 
> Thanks for your time,
> 
> Fabio 

Sounds like you all got things moving along wrt the compile issue.
I do want to follow up on a couple of things buried in this thread.

It's good that compile issue is getting fixed because you can't get
too far without hitting requirements to build w ALLYESCONFIG or
ALLMODCONFIG, or the like, while doing kernel development.

The thought of not compiling before sending is blasphemy ;)
We see patches come through this list on occasion that don't compile
and usually it's a cockpit error, not an intentional error. ie. The
applicant did compile the module, loaded/unloaded it, but then some
process thing went wrong and they created the patch from a different
branch. There are all sorts of ways to mangle a patch, but intentionally
not compiling it is just plain bad. That's another reason to create patches,
send them to yourself, apply to a clean tree, in the beginning to build
confidence in your processes.

wrt the 10 patch cleanup requirement. We often have applicants work
multiple contribution periods for a multitude of reasons. For applicants
who already have patches accepted in drivers/staging, we ask that they
submit a few, to show they are current (if needed). Again, if your 'old'
patches were from last month, no need to prove currency.

So, Fabio, this means for you personally, go ahead and link to prior
patches when you record your contribution in the Outreachy application.

Anyone else in this situation, please ask. 

Thanks,
Alison


> 
> 
> 

Re: Compilation errors

[Fabio M. De Francesco]

On venerdì 1 aprile 2022 18:09:01 CEST Alison Schofield wrote:
> On Fri, Apr 01, 2022 at 03:07:24PM +0200, Fabio M. De Francesco wrote:
> > On venerdì 1 aprile 2022 14:57:14 CEST Stefano Brivio wrote:
> > > 
> > > Okay, then that's really an error.
> > > 
> > > It might simply be that the you're building some drivers on your
> > > staging tree that you're not building on the mainline tree.
> > 
> > Yes, this is why I've decided to use the .config that I have in Torvald's 
> > tree. They should only differ for the drivers/staging part and the suffix 
> > for vmlinuz.
> > 
> > Now it builds correctly with gcc11 :)
> > 
> > I must look carefully at the diff between the two files and figure out
> > what doesn't work.
> > 
> > However what really counts is that now I can go back to work with "staging".
> > 
> > Thanks for your time,
> > 
> > Fabio 
> 
> Sounds like you all got things moving along wrt the compile issue.

Yes, thank you. The problem was due to UBSan enabled.

> I do want to follow up on a couple of things buried in this thread.
> 
> It's good that compile issue is getting fixed because you can't get
> too far without hitting requirements to build w ALLYESCONFIG or
> ALLMODCONFIG, or the like, while doing kernel development.
> 
> The thought of not compiling before sending is blasphemy ;)

I agree in full. It was just the desperation talking :-)

> wrt the 10 patch cleanup requirement. We often have applicants work
> multiple contribution periods for a multitude of reasons. For applicants
> who already have patches accepted in drivers/staging, we ask that they
> submit a few, to show they are current (if needed). Again, if your 'old'
> patches were from last month, no need to prove currency.

Most of my patches (a bit less than 100) are a bit older. The large part of 
them are since March 2021 to October 2021. In 2022 I have submitted only 
7 patches to net/smc, usb/core, staging. 

But I usually don't do clean-ups. For instance, two recent patches were to
fix bugs reported by Syzbot in "net" and in "usb". A couple of recent 
"staging" patches are about converting kmap() to kmap_local_page().

> So, Fabio, this means for you personally, go ahead and link to prior
> patches when you record your contribution in the Outreachy application.

Therefore, since the number of recent patches is low, can you please confirm
whether or not I can register also some of those of 2021 "to prove currency"?
Please notice that only 4 or 5 are from the last month.

Thanks,

Fabio
 
> Anyone else in this situation, please ask. 
> 
> Thanks,
> Alison

Re: Compilation errors

[Fabio M. De Francesco]

On venerdì 1 aprile 2022 14:57:14 CEST Stefano Brivio wrote:
> You reported this issue three hours ago and, as far as I can tell,
> there are 672 hours in four weeks...

Nice calculation. Helpful to use to start countdown to April 22nd...
I'm just kidding :)

However, despite I reported this issue just few hours ago, it's since two
or three days that I have been struggling with this issue.
 
Finally I found the "culprit": the "Undefined Sanity Checker" (UBSan).

I had enabled it some days ago and forgot about it. When I set it, I 
(wrongly) thought that, since I have CONFIG_WERROR set to off, it wouldn't 
have failed the builds. I was just expecting error messages, my fault :(

What led me to figure out this explanation are the messages I got. If you 
noticed, they were all about "case label does not reduce to an integer 
constant".

Well, now I have some more stuff to fix in mainline for my spare time :)

Thanks again,

Fabio

Compilation errors

[Peter Teoh]

I pulled the git from linux-mm today, and compiled with the following errors:

  CC      arch/x86/kernel/apm_32.o
arch/x86/kernel/apm_32.c: In function 'suspend':
arch/x86/kernel/apm_32.c:1192: warning: 'pm_send_all' is deprecated
(declared at include/linux/pm_legacy.h:16)
arch/x86/kernel/apm_32.c:1227: warning: 'pm_send_all' is deprecated
(declared at include/linux/pm_legacy.h:16)
arch/x86/kernel/apm_32.c: In function 'check_events':
arch/x86/kernel/apm_32.c:1340: warning: 'pm_send_all' is deprecated
(declared at include/linux/pm_legacy.h:16)
  LD      arch/x86/kernel/apm.o
  CC      arch/x86/kernel/smp_32.o

And the following errors:

  CC      arch/x86/mm/ioremap.o
arch/x86/mm/ioremap.c: In function '__ioremap':
arch/x86/mm/ioremap.c:106: error: expected expression before '<<' token
arch/x86/mm/ioremap.c:108: error: expected expression before '==' token
arch/x86/mm/ioremap.c:109:9: error: invalid suffix
"d45b22c079946332bf3825afefe5a981a97b6" on integer constant
arch/x86/mm/ioremap.c:128: error: expected expression before '<<' token
arch/x86/mm/ioremap.c:133:9: error: invalid suffix
"d45b22c079946332bf3825afefe5a981a97b6" on integer constant
arch/x86/mm/ioremap.c:140: error: 'prot' undeclared (first use in this function)
arch/x86/mm/ioremap.c:140: error: (Each undeclared identifier is
reported only once
arch/x86/mm/ioremap.c:140: error: for each function it appears in.)
make[1]: *** [arch/x86/mm/ioremap.o] Error 1

And issuing another "git pull" I got: the following message:

You are in the middle of a conflicted merge.


Please enlighten me here...thanks.

--
To unsubscribe, send a message with 'unsubscribe linux-mm' in
the body to majordomo@kvack.org.  For more info on Linux MM,
see: http://www.linux-mm.org/ .
Don't email: <a href=mailto:"dont@kvack.org"> email@kvack.org </a>

Compilation errors

[Richard Hartensveld]

Hi all,

I'm trying to build the latest cvs tree (first kernel i'm trying to
compile locally on this challenge S)

Does anyone know what's going wrong? the same kernel compiles flawlessly
on my linux/x86 system with a crosscompiler.

Down here is the error.


[root@tux linux]# make zImage
gcc -D__KERNEL__ -I/usr/src/linux/include -Wall -Wstrict-prototypes -O2
-fomit-frame-pointer -G 0 -mno-abicalls -fno-pic -mcpu=r8000 -mips2
-pipe  -c -o init/main.o init/main.c
/usr/src/linux/include/linux/sched.h: In function `on_sig_stack':
In file included from /usr/src/linux/include/linux/mm.h:4,
                 from /usr/src/linux/include/linux/slab.h:14,
                 from /usr/src/linux/include/linux/malloc.h:4,
                 from /usr/src/linux/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/usr/src/linux/include/linux/sched.h:528: `current' undeclared (first
use this function)
/usr/src/linux/include/linux/sched.h:528: (Each undeclared identifier is
reported only once
/usr/src/linux/include/linux/sched.h:528: for each function it appears
in.)
/usr/src/linux/include/linux/sched.h:530: warning: control reaches end
of non-void function
/usr/src/linux/include/linux/sched.h: In function `sas_ss_flags':
/usr/src/linux/include/linux/sched.h:534: `current' undeclared (first
use this function)
/usr/src/linux/include/linux/sched.h:536: warning: control reaches end
of non-void function
/usr/src/linux/include/linux/sched.h: In function `suser':
/usr/src/linux/include/linux/sched.h:561: `current' undeclared (first
use this function)
/usr/src/linux/include/linux/sched.h: In function `fsuser':
/usr/src/linux/include/linux/sched.h:570: `current' undeclared (first
use this function)
/usr/src/linux/include/linux/sched.h: In function `capable':
/usr/src/linux/include/linux/sched.h:586: `current' undeclared (first
use this function)
/usr/src/linux/include/linux/mm.h: In function `expand_stack':
In file included from /usr/src/linux/include/linux/slab.h:14,
                 from /usr/src/linux/include/linux/malloc.h:4,
                 from /usr/src/linux/include/linux/proc_fs.h:5,
                 from init/main.c:15:
/usr/src/linux/include/linux/mm.h:349: `current' undeclared (first use
this function)
init/main.c: In function `do_basic_setup':
init/main.c:1242: `current' undeclared (first use this function)
make: *** [init/main.o] Error 1


Cheers,

Richard

Re: Compilation errors

[Alex deVries]

On Wed, 3 Feb 1999, Richard Hartensveld wrote:

>                  from init/main.c:15:
> /usr/src/linux/include/linux/sched.h:528: `current' undeclared (first
> use this function)
> /usr/src/linux/include/linux/sched.h:528: (Each undeclared identifier is
> reported only once
> /usr/src/linux/include/linux/sched.h:528: for each function it appears

Use egcs and you will have no problems.  You'll be a better person, too.

- Alex

Re: Compilation errors

[Ulf Carlsson]

On Wed, Feb 03, 1999 at 12:12:47PM -0500, Alex deVries wrote:
> On Wed, 3 Feb 1999, Richard Hartensveld wrote:
> 
> >                  from init/main.c:15:
> > /usr/src/linux/include/linux/sched.h:528: `current' undeclared (first
> > use this function)
> > /usr/src/linux/include/linux/sched.h:528: (Each undeclared identifier is
> > reported only once
> > /usr/src/linux/include/linux/sched.h:528: for each function it appears
> 
> Use egcs and you will have no problems.  You'll be a better person, too.

You may update the specs file instead if you want, and gcc will work. Ask me and
I'll send you the updated specs file.

- Ulf