In file included from error linux

Ошибки компиляции

Пытаюсь последнюю версию скомпилировать fmio:

#make
cc -O2 -Wall -DNOMIXER -I/usr/src/fmio-2.0.8/src -o access.o -c access.c
In file included from /usr/include/linux/videodev.h:8,
from radio_drv.h:36,
from access.c:38:
/usr/include/linux/videodev2.h:436: error: parse error before ‘*’ token
/usr/include/linux/videodev2.h:438: error: parse error before ‘*’ token
/usr/include/linux/videodev2.h:439: error: parse error before ‘>’ token
/usr/include/linux/videodev2.h:810: error: field `win’ has incomplete type
In file included from radio_drv.h:36,
from access.c:38:
/usr/include/linux/videodev.h:225: error: parse error before ‘*’ token
/usr/include/linux/videodev.h:226: error: conflicting types for `clipcount’
/usr/include/linux/videodev2.h:437: error: previous declaration of `clipcount’
/usr/include/linux/videodev.h:232: error: parse error before ‘>’ token
make: *** [access.o] Error 1

Что с этим делать? Версия ядра 2.6.8

Re: Ошибки компиляции

/usr/include/linux/videodev2.h:436
/usr/include/linux/videodev2.h:438
/usr/include/linux/videodev2.h:439
/usr/include/linux/videodev2.h:810

Re: Ошибки компиляции

у тебя videodev2.h кривой просто

возьми из какого-нить другого пакета, например из XawTV 2.43, или поставь linux-kernel-fix-media как-то так, точно не помню

Источник

fatal error: Eigen/Dense: No such file or directory

I have installed libeigen3-dev in order to compile programs using Eigen 3. when I include a file, such as Eigen/Dense I get this error when I try to run g++ :

Running the following line works fine:

g++ -I /usr/include/eigen3/ src/main.cpp -MMD -std=c++11

shouldn’t that include directory be automatically found by GCC because I installed the Eigen package through aptitude? Why are boost and OpenGL found automatically when I install the libraries but not Eigen? (Note that eigen is a header-only library, but that shouldn’t matter right?)

Running g++ src/main.cpp -MMD -std=c++11 —verbose produces the following output:

7 Answers 7

I had this same problem on my Ubuntu 14 box. Ended up creating symlinks to get around it. With eigen3 installed in /usr/local/include do the following:

You should now be able to include the headers by:

Run your compiler with the —verbose switch:

If your includes are relative to one of the paths shown in this output, you don’t have to use -I . It depends how gcc has been configured, and it depends where that other stuff is installed.

Note that . is typically not in the -I paths.

Later

After exchanging a couple of comments it is clear that /usr/include/eigen3/Eigen/Dense should be include-able by #include , but not by #include . Therefore, the addition of the command line option -I /usr/include/eigen3 is mandatory.

Whether some installation selects to install header files into a directory that in one of the ones compiled into gcc, depends on the default, a decision made by the distributor, or a decision made during installation. I’d say that «frequently used» header files (Boost) are well placed into /usr/local/include while some «elitist» stuff would be better off in a directory of its own.

Источник

Multiple application header files included error in C

I am doing a porting project implemented from INTEGRITY OS to UBUNTU. Facing compiler error as explained below. Even though not compiled in INTEGRITY OS, i think there is no errors there. I got the root cause. I am expecting solution how i can achieve this.

Inside all the files from file1.h to file3.h below is there at the beginning of each file.

Above throws error while compiling

Same error is thrown for all the files for file1.h to file3.h

2 Answers 2

If all three (or however many there are) of those header files use the same symbol INC_HEADER_FILE , then you will only be allowed to include one of them.

That’s because including (for example) file1.h will set that symbol, meaning that including the next header will complain because it’s already defined.

The include guard symbol is usually specific to the header file itself, such as INC_HEADER_1_FILE but it’s my no means necessary — I’ve seen this sort of thing done when you only want one variation of a header file.

An example of that is a system I worked on for LED display devices where each header had different dimensions. These were constructed from 8×8 units but different quantities across and down. Having the LED addressing map in a header file allowed for efficiencies that weren’t available with dynamic configuration and the include guard made sure we didn’t try to use more than one map.

Источник

Ticket #19845 (closed defect: fixed)

Last modified 12 months ago

Linux kernel version 5.9 — we need changes

Reported by:	burdi01	Owned by:
Component:	other	Version:	VirtualBox 6.1.10
Keywords:	linux kernel 5.9	Cc:
Guest type:	Linux	Host type:	Linux

Description

Stock kernel 5.9-rc3 on Slackware Current64:
— VirtualBox-6.1.13-140124-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-140124.vbox-extpack: build failure

I know this is early in the cycle 🙂

Attachments

Change History

Changed 14 months ago by burdi01

• attachmentvbox-setup.log added

comment:1 Changed 13 months ago by burdi01

From the above vbox-setup.log:

In file included from /tmp/vbox.0/linux/SUPDrv-linux.c:33:[[BR]] /tmp/vbox.0/r0drv/linux/the-linux-kernel.h:141:11: fatal error: linux/smp_lock.h: No such file or directory

comment:2 Changed 13 months ago by fbatschu

1) smp_lock.h issue:

$kmk KERN_VER=linux-5.9-rc3 KERN_DIR=/home/ws/linux-5.9-rc3

Files #including this file: smp_lock.h

«linux/smp_lock.h» is the header file for the «Big Kernel Lock»,

which as such no longer exists after Linux kernel version 2.6.39.

smp_lock.h has been removed in Linux kernel version 2.6.39 but the HAVE_UNLOCKED_IOCTL is still there in 2.6.39, 3.19, 4.20.17 and 5.8.5 b ut is finally removed in 5.9-rc1 with commit:

comment:3 Changed 13 months ago by fbatschu

• Host type changed from other to Linux
• Guest type changed from other to Linux

comment:4 Changed 13 months ago by fbatschu

after fixing issue 1) we find issue 2)

2) HAVE_UNLOCKED_IOCTL removed from linux/fs.h

We have a lot of places throughout the code base that make use of HAVE_UNLOCKED_IOCTL on Linux to decided how the struct ‘file_operations» is defined. Those fail now since 5.9 removed it, yet its meaning as such remains valid. to fix both we can do:

comment:5 Changed 13 months ago by fbatschu

3) get_user_pages_remote() changed in Linux kernel version 5.9

‘get_user_pages_remote()’ API doesn’t get ‘struct task_struct’ parameter after:

and we fail like this

=> 1st arg struct task_struct *tsk removed

comment:6 Changed 13 months ago by fbatschu

4) sched_setscheduler() has been unexported

I.e. no more EXPORT_SYMBOL_GPL(sched_setscheduler) available with 5.9-rc1

and is thus no longer available to us in 5.9, typical failure mode while building the vboxdrv module:

sched_setscheduler() is a problem in: trunk/src/VBox/Runtime/r0drv/linux/thread2-r0drv-linux.c

where we attempt to set scheduling priorities for our kernel threads. We do this for 2 scheduling classes, SCHED_NORMAL and SCHED_FIFO.

For the SCHED_FIFO case in this code, we should use instead the new sched_set_fifo() and sched_set_fifo_low() interfaces. However in general SCHED_FIFO is discouraged and we probably should drop that in the longer run. For the rest of the cases of SCHED_NORMAL we should probably use sched_set_normal() and set a nice value instead of the current priority for sched_setscheduler().

Eg something like this is a start and with that, no more other failures crop up with 5.9-rc3

comment:7 Changed 13 months ago by fbatschu

• Owner set to fbatschu
• Status changed from new to accepted

comment:8 Changed 13 months ago by burdi01

Stock kernel 5.9-rc3 on Slackware Current64:
— VirtualBox-6.1.13-140124-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.13-140124.vbox-extpack:
After applying the 59-diffs.txt patch and copying the vboxdrv/r0drv/linux/the-linux-kernel.h file to vboxnet/r0drv/linux/ the host kernel modules built without a problem and my (non-guest-additions) guests run OK.
😀

comment:9 Changed 13 months ago by burdi01

Stock kernel 5.9-rc3 on Slackware Current64:
— VirtualBox-6.1.14-140239-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.14-140239.vbox-extpack:
After applying the 59-diffs.txt patch and copying the vboxdrv/r0drv/linux/the-linux-kernel.h file to vboxnet/r0drv/linux/ the host kernel modules built without a problem and my (non-guest-additions) guests run OK.
😀

comment:10 Changed 13 months ago by burdi01

Stock kernel 5.9-rc4 on Slackware Current64:
— VirtualBox-6.1.14-140239-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.14-140239.vbox-extpack:
After applying the 59-diffs.txt patch and copying the vboxdrv/r0drv/linux/the-linux-kernel.h file to vboxnet/r0drv/linux/ the host kernel modules built without a problem and my guests (I only have guests without guestadditions) run OK.
😀

comment:11 Changed 13 months ago by fbatschu

the next one is:

5) drm_gem_object_put_unlocked() removed

=> entirely gone in 5.9-rc1, but new introduced in 5.9-rc1 this which has been renamed from previous: drm_gem_object_put(). We can use that instead.

comment:12 Changed 13 months ago by fbatschu

6) struct drm_driver .master_set — function return value change from int to void

comment:13 Changed 13 months ago by burdi01

Stock kernel 5.9-rc4 on Slackware Current64:
— VirtualBox-6.1.14-140239-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.14-140239.vbox-extpack:
After applying the revised 59-diffs.txt patch (excluding the Additions patch) and copying the vboxdrv/r0drv/linux/the-linux-kernel.h file to vboxnet/r0drv/linux/ the host kernel modules built without a problem and my guests (I only have guests without guestadditions) run OK.

Stock kernel 5.9-rc4 on Slackware Current64:
— VirtualBox-6.1.15-140270-Linux_amd64.run with Oracle_VM_VirtualBox_Extension_Pack-6.1.15-140270.vbox-extpack:
After applying the revised 59-diffs.txt patch (excluding the Additions patch) and copying the vboxdrv/r0drv/linux/the-linux-kernel.h file to vboxnet/r0drv/linux/ the host kernel modules built without a problem and my guests (I only have guests without guestadditions) run OK.

comment:14 Changed 13 months ago by fbatschu

7) struct ttm_buffer_object has no member ‘offset’ anymore in 5.9-rc1

Solution: we will calculate directly as ‘bo->bo.mem.start comment:15 Changed 13 months ago by fbatschu

the attached diffs should work for 5.9-rc4: https://git.kernel.org/torvalds/t/linux-5.9-rc4.tar.gz for both host & guest

comment:16 Changed 13 months ago by fbatschu

the attached diffs still work for https://git.kernel.org/torvalds/t/linux-5.9-rc5.tar.gz and Trunk svn revision r140354

comment:17 Changed 13 months ago by fbatschu

the attached diffs still work for https://git.kernel.org/torvalds/t/linux-5.9-rc6.tar.gz and Trunk svn revision r140354

comment:18 Changed 13 months ago by burdi01

Thank you for keeping us posted.
😀

comment:19 Changed 13 months ago by fbatschu

the attached diffs still work for https://git.kernel.org/torvalds/t/linux-5.9-rc7.tar.gz and Trunk SVN revision r140593

comment:20 follow-up: ↓ 21 Changed 13 months ago by burdi01

Kernel 5.9-rc7 crashes on my system — see https://lkml.org/lkml/2020/9/28/674 .
Therefore I tested VirtualBox-6.1.15-140592-Linux_amd64.run with kernel 5.8.12: OK.
Alas after applying the diffs vboxconfig fails.
Uploading vbox-setup.log .

Changed 13 months ago by burdi01

• attachmentvbox-setup.log.new added

Changed 13 months ago by fbatschu

• attachment59-diffs.txt added

for 5.9-rc7 59-diffs-29092020.txt

comment:21 in reply to: ↑ 20 Changed 13 months ago by fbatschu

Kernel 5.9-rc7 crashes on my system — see https://lkml.org/lkml/2020/9/28/674 .
Therefore I tested VirtualBox-6.1.15-140592-Linux_amd64.run with kernel 5.8.12: OK.
Alas after applying the diffs vboxconfig fails.
Uploading vbox-setup.log .

Yikes! That is strange, on my 5.4.0 Trunk build system this does not occure.

The problem presumably is that thread2-r0drv-linux.c does not include iprt/err.h but only iprt/errcore.h which duplicates some but not all of the error values declared in err.h thus giving the wrong impression it is equivilent in that regard to err.h which it is not.

Lets swap VERR_IPE_UNEXPECTED_ERROR_STATUS with VERR_GENERAL_FAILURE for the time until this is putbacked. See attached new diffs 59-diffs-29092020.txt

Источник

GCC version error on dkms while compiling NVIDIA Drivers #1133

Comments

voaneves commented Aug 16, 2019

Tried to follow the installation tutorial on the documentation site and ended-up with the following error

The commands I executed were

and all of those resulted on the same log file.

Kernel version 5.2.8-818.native
Clear Linux version 30790
dkms version native

Do you guys know of any solution to this?

The text was updated successfully, but these errors were encountered:

lebensterben commented Aug 16, 2019

@Neves4 Hi I saw the same error today and talked about this on IRC channel. It’s said that a newer version of kernel is about to be released soon and that should be compiled with 9.2.1.

puneetse commented Aug 20, 2019

This appears to be resolved for me using 30810.

lebensterben commented Aug 20, 2019

This appears to be resolved for me using 30810.

@puneetse Yes I can confirm this.

amygilliam1 commented Aug 21, 2019

Can’t reproduce. Re-open if it is seen again.

voaneves commented Aug 24, 2019 •

Guys,
Fresh installed today, still getting errors. Output when compiling nvidia 390.87:

/var/log/nvidia-installer.log

/var/lib/dkms/nvidia/390.87/build/make.log

It looks like it can be fixed by answer nº 11 here, but looks troublesome to be editing the files. Am I missing anything? I followed all the steps carefully.

Kernel version 5.2.9-825.native
Clear Linux version 30850
dkms version native

@amygilliam1 can you reopen, please? Or is it better for me to open a new issue?

Источник