Jump to content

[SOLVED] Compiling drivers error. No header files found.


vaid

Recommended Posts

after apt_get install linux-headers-$(uname -r)

 

make headers_check -ok

make headers_install-ok

 

make scripts
  HOSTCC  scripts/selinux/genheaders/genheaders
scripts/selinux/genheaders/genheaders.c:13:22: fatal error: classmap.h: No such file or directory
 #include "classmap.h"
                      ^
compilation terminated.
 

 

what can i do at this moment?

 

 

Link to comment
Share on other sites

hello again!

 

i make scripts in headers directory when i am installing previous version image . that's good

may be you can  help me with next trouble.i am getting compile error with xusb_

 


root@cubietruck:/usr/src# cd dahdi*
root@cubietruck:/usr/src/dahdi-linux-complete-2.11.1+2.11.1# make all
make -C linux all
make[1]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux'
make -C drivers/dahdi/firmware firmware-loaders
make[2]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/firmware'
make[2]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/firmware'
make -C /lib/modules/4.9.5-sunxi/build SUBDIRS=/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi DAHDI_INCLUDE=/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/include DAHDI_MODULES_EXTRA=" " HOTPLUG_FIRMWARE=yes modules DAHDI_BUILD_ALL=m
make[2]: Entering directory '/usr/src/linux-headers-4.9.5-sunxi'
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/Kbuild:124: CPU Architecture 'arm' does not support VPMADT032 or HPEC. Skipping.
  VERSION /usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/xpp/xpp_version.h

  Building modules, stage 2.
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux/drivers/dahdi/Kbuild:124: CPU Architecture 'arm' does not support VPMADT032 or HPEC. Skipping.
  MODPOST 18 modules
make[2]: Leaving directory '/usr/src/linux-headers-4.9.5-sunxi'
make[1]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/linux'
(cd tools && [ -f config.status ] || ./configure --with-dahdi=../linux)
make -C tools all
make[1]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools'
make  all-recursive
make[2]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools'
Making all in xpp
make[3]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp'
Making all in perl_modules
make[4]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/perl_modules'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/perl_modules'
Making all in oct612x
make[4]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/oct612x'
make[4]: Nothing to be done for 'all'.
make[4]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/oct612x'
Making all in xtalk
make[4]: Entering directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk'
  CCLD     xusb_test
xusb_test-xusb_test.o: In function `xusb_destructor':
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:27: undefined reference to `xusb_destroy'
xusb_test-xusb_test.o: In function `run_spec':
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:65: undefined reference to `xusb_find_byproduct'
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:75: undefined reference to `xusb_claim'
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:81: undefined reference to `xusb_showinfo'
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_test.c:82: undefined reference to `xusb_release'
./.libs/libxtalk.a(libxtalk_la-xusb_common.o): In function `xusb_open_one':
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:236: undefined reference to `xusb_find_byproduct'
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:248: undefined reference to `xusb_claim'
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:254: undefined reference to `xusb_destroy'
./.libs/libxtalk.a(libxtalk_la-xusb_common.o): In function `xusb_destroy_interface':
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:181: undefined reference to `xusb_release'
./.libs/libxtalk.a(libxtalk_la-xusb_common.o): In function `xusb_flushread':
/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk/xusb_common.c:332: undefined reference to `xusb_recv'
collect2: error: ld returned 1 exit status
Makefile:628: recipe for target 'xusb_test' failed
make[4]: *** [xusb_test] Error 1
make[4]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp/xtalk'
Makefile:1018: recipe for target 'all-recursive' failed
make[3]: *** [all-recursive] Error 1
make[3]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools/xpp'
Makefile:1113: recipe for target 'all-recursive' failed
make[2]: *** [all-recursive] Error 1
make[2]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools'
Makefile:662: recipe for target 'all' failed
make[1]: *** [all] Error 2
make[1]: Leaving directory '/usr/src/dahdi-linux-complete-2.11.1+2.11.1/tools'
Makefile:9: recipe for target 'all' failed
make: *** [all] Error 2
 

Link to comment
Share on other sites

It is almost2019 and this is still preventing one to compile like rtl wifi modules.   Get this error when ... sudo make scripts

Quote

scripts/selinux/genheaders/genheaders.c:13:10: fatal error: classmap.h: No such file or directory
 #include "classmap.h"
          ^~~~~~~~~~~~
compilation terminated.

 

Link to comment
Share on other sites

 

48 minutes ago, denni_isl said:

It is almost2019 and this is still preventing one to compile like rtl wifi modules.   Get this error when ... sudo make scripts

 

And you still don't have rights to complain -> https://www.armbian.com/get-involved/ Linux is a work of XXXX people. Only X works on Armbian. In their time.

Link to comment
Share on other sites

Thank you for the respond.   It is actually a good point, and understood.   And this https://www.armbian.com/get-involved/#communication

and the Armbian documentations are actually the best source I have seen on the net for the everyday hobbyist wanting to get a better understanding of computers and now those days embedded systems.    Regarding this issues with being unable to compile drivers for for arm64 boards, I have came to the conclusions that it is actually because aarch64 is just not there yet.   And I am not a programmer so I have to remind my self ... hands off.   arm64 is like a new kid in the block in the linux world.   Android is just another story.     Is there any migrating from Android to linux in the arm and arm64 support?   Or is the Android source closed from the linux world?    Now I am wondering how far arm64 is in it's development.   Did see this of non supported software from debian site. https://wiki.debian.org/Arm64PortANFUList

and it is quite a lot.  

 

 

Link to comment
Share on other sites

6 minutes ago, denni_isl said:

I have came to the conclusions that it is actually because aarch64 is just not there yet.  


I am not completely sure, without looking deeply into the problem, but such errors could easily pop-out on amd64 system as well. 
 

7 minutes ago, denni_isl said:

Android is just another story.


Yes, its kernel is worse situation and comes with zero support. It's full of blobs and not standard solutions. Why wasting time with it? Android on OS level doesn't seems to be much of our interest anyway. And. "Nice and intuitive" UI doesn't help you when your system is fragile/unstable due to the poor kernel support. That is an everyday story behind Android on development boards. We only have better tools and less garbage around when dealing with support.

Link to comment
Share on other sites

Both firefly rk3399 and rockpro64 are amazing products, and working like a charm with armbian though still lacking some things.   Firefly is more working out of the box when rockpro64 does not yet support for it's components like the audio jack, wifi module and isa(okay in cli)  slot.   Then it is the usual thing that the hardware that is ahead of the software.   But what did take me with a surprise is the lack of comparability with usb wifi dongles now almost as common as coffee <_<.  

Link to comment
Share on other sites

10 minutes ago, denni_isl said:

But what did take me with a surprise is the lack of comparability with usb wifi dongles now almost as common as coffee


And who should do that? We provide a list of (good) ones - on the download pages - that work out of the box. For each kernel/board. It's planned to do more indeep testings, but day has only 24h. Some of the testings can be found scattered in this topic and elsewhere on the forum.

Link to comment
Share on other sites

8 minutes ago, Igor said:


And who should do that? We provide a list of (good) ones - on the download pages - that work out of the box. For each kernel/board. It's planned to do more indeep testings, but day has only 24h. Some of the testings can be found scattered in this topic and elsewhere on the forum.

Did not see this threat before.  Interesting.    If only I had programming experience I would be willing to try to help out with migrating all those rtl--- modules on github to arm64.   What  i can see is that coordinated effort must be the best way to get the compiling environment right and then being able to adjust those modules.   

 

Btw. you at armbian are doing a excellent  job.

 

Link to comment
Share on other sites

2 minutes ago, denni_isl said:

to arm64


They are not working on x86 Ubuntu as well. They usually work on Windows OOB, while Linux support is not existing or not so good. Wireless networking on Linux is not directly related to Armbian. We already went much further than generic Linux distributions. 
 

5 minutes ago, denni_isl said:

If only I had programming experience


Whatever you do to relieve those who can is already a valuable contribution. In the spirit of "Contribute".

Link to comment
Share on other sites

SUCCESS AT LAST!   Installing a Realtech wireless wifi dongle driver on rockpro64.  

Okay being a stubborn person,  is sometimes beneficial.  

I was at last able to install driver for my speedy Chinese USB dongle with Realtech ship. lsusb gives vendor 0bda and product b812 witch is dependent upon driver rtl8812bu.     Now I want to contribute to the community on how.  Did fallow the instructions on  https://docs.armbian.com/Developer-Guide_Build-Preparation/   compiled a new kernel and U-boot,   It did produce 5 *.deb files; linux-source-default-rockchip64_5.67_all.deb, linux-headers-rockchip64_5.67_arm64.deb,  linux-u-boot-rockpro64_5.67_arm64.deb, linux-image-rockchip64_5.67_arm64.deb  and installed them on the rockpro64 board.   It did also include  /usr/src/linux-source-4.4.167-rockchip64.tar.xz which I extracted into /usr/src/linux-headers-4.4.167-rockchip64 directory and did make clean (because of previous compile error of lacking files) and then make scripts (and viola it did work!!!).   Then it was github next and this driver did look promising https://github.com/cilynx/rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959  Fallowed the instructions of dkms install there

 

Quote

cd rtl88x2BU_WiFi_linux_v5.3.1_27678.20180430_COEX20180427-5959 VER=$(sed -n 's/\PACKAGE_VERSION="\(.*\)"/\1/p' dkms.conf) sudo rsync -rvhP ./ /usr/src/rtl88x2bu-${VER} sudo dkms add -m rtl88x2bu -v ${VER} sudo dkms build -m rtl88x2bu -v ${VER} sudo dkms install -m rtl88x2bu -v ${VER} sudo modprobe 88x2bu

 

 

And it did work!   Almost all the headache was because of the driver needing kernel source not just the headers under /usr/src/linux-headers-$(uname -r)

 

Quote

wlx000  IEEE 802.11AC  ESSID:"my_connection-5G"  Nickname:"<WIFI@REALTEK>"
          Mode:Managed  Frequency:5.22 GHz  Access Point: 00:00:00:00:00:00  
          Bit Rate:867 Mb/s   Sensitivity:0/0  
          Retry:off   RTS thr:off   Fragment thr:off
          Encryption key:****-****-****-****-****-****-****-****   Security mode:open
          Power Management:off
          Link Quality=100/100  Signal level=-36 dBm  Noise level=0 dBm
          Rx invalid nwid:0  Rx invalid crypt:0  Rx invalid frag:0
          Tx excessive retries:0  Invalid misc:0   Missed beacon:0

 

 

 

20181223_135937.jpg

Link to comment
Share on other sites

Guest
This topic is now closed to further replies.
×
×
  • Create New...

Important Information

Terms of Use - Privacy Policy - Guidelines