On 01/17/2015 08:07 PM, poma wrote:
> On 17.01.2015 04:02, Stephen Morris wrote:
>> On 01/16/2015 08:38 AM, Stephen Morris wrote:
>>> On 01/15/2015 11:46 PM, poma wrote:
>>>> On 15.01.2015 08:50, Stephen Morris wrote:
>>>>> I have a driver for a wifi usb device that I need to compile because
>>>>> there are no drivers in the kernel, which has been obtained from the
>>>>> vendor of the device. When I attempt to compile the code the compile
>>>>> fails on the grounds that some warnings are being translated into
>>>>> errors. From my perspective these errors should not be happening
>>>>> because, when a debugging module wants to time stamp the build, that
is
>>>>> not an error and is perfectly acceptable. How do I get the compiler
to
>>>>> stop producing these errors. The messages I get are listed below.
>>>>>
>>>>> Authentication requested [root] for make driver:
>>>>> make ARCH=x86_64 CROSS_COMPILE= -C
>>>>> /lib/modules/3.17.8-300.fc21.x86_64/build
>>>>>
M=/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411
>>>>>
>>>>> modules
>>>>> make[1]: Entering directory
'/usr/src/kernels/3.17.8-300.fc21.x86_64'
>>>>> CC [M]
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_cmd.o
>>>>>
>>>>> CC [M]
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_security.o
>>>>>
>>>>> CC [M]
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.o
>>>>>
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:
>>>>>
>>>>> In function ‘dump_drv_version’:
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:66:64:
>>>>>
>>>>> error: macro "__DATE__" might prevent reproducible builds
>>>>> [-Werror=date-time]
>>>>> DBG_871X_SEL_NL(sel, "build time: %s %s\n", __DATE__,
__TIME__);
>>>>> ^
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:66:1:
>>>>>
>>>>> error: macro "__TIME__" might prevent reproducible builds
>>>>> [-Werror=date-time]
>>>>> DBG_871X_SEL_NL(sel, "build time: %s %s\n", __DATE__,
__TIME__);
>>>>> ^
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:66:1:
>>>>>
>>>>> error: macro "__DATE__" might prevent reproducible builds
>>>>> [-Werror=date-time]
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:66:1:
>>>>>
>>>>> error: macro "__TIME__" might prevent reproducible builds
>>>>> [-Werror=date-time]
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:66:1:
>>>>>
>>>>> error: macro "__DATE__" might prevent reproducible builds
>>>>> [-Werror=date-time]
>>>>>
/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.c:66:1:
>>>>>
>>>>> error: macro "__TIME__" might prevent reproducible builds
>>>>> [-Werror=date-time]
>>>>> cc1: some warnings being treated as errors
>>>>> scripts/Makefile.build:257: recipe for target
>>>>>
'/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.o'
>>>>>
>>>>> failed
>>>>> make[2]: ***
>>>>>
[/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411/core/rtw_debug.o]
>>>>>
>>>>> Error 1
>>>>> Makefile:1377: recipe for target
>>>>>
'_module_/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411'
>>>>>
>>>>> failed
>>>>> make[1]: ***
>>>>>
[_module_/usr/local/downloads/dlink/RTL8812AU_linux_v4.3.2_11100.20140411/driver/rtl8812AU_linux_v4.3.2_11100.20140411]
>>>>>
>>>>> Error 2
>>>>> make[1]: Leaving directory
'/usr/src/kernels/3.17.8-300.fc21.x86_64'
>>>>> Makefile:1350: recipe for target 'modules' failed
>>>>> make: *** [modules] Error 2
>>>>> ##################################################
>>>>> Compile make driver error: 2
>>>>> Please check error Mesg
>>>>> ##################################################
>>>>>
>>>>>
>>>>>
>>>> $ sed -i '/uninitialized/ i\EXTRA_CFLAGS +=
-Wno-error=date-time'
>>>> Makefile
>>>>
>>>> If it crashes, try your luck with these:
>>>>
>>>> $ git clone
https://github.com/gnab/rtl8812au.git
>>>> $ cd rtl8812au/
>>>> ...
>>>> $ git clone
https://github.com/abperiasamy/rtl8812AU_8821AU_linux.git
>>>> $ cd rtl8812AU_8821AU_linux/
>>>> ...
>>>> $ make
>>>> $ su
>>>> # cp 8812au.ko /lib/modules/$(uname -r)/updates/
>>>> # depmod
>>>> # modprobe -v 8812au
>>> Thanks poma, I'll check these out. The git source might be better than
>>> what I have at the moment as the vendor source I have seems to be
>>> requiring kernel config parameters that appear to not be active in the
>>> kernels I am using.
>> I've compiled the code and after copying the compiled module and running
>> the modprobe the device immediately connected. I'll run a few more tests
>> and try a reboot to see if it still works successfully.
>> I am assuming that I will need to perform all these steps everytime the
>> kernel is upgraded, would that be correct?
> If you put the source code on a permanent location,
> this part of the procedure is necessary for a new i.e. an upgraded kernel:
>
> $ cd /path/to/rtl8812au/
> $ make clean
> $ make
> $ su
> # cp 8812au.ko /lib/modules/$(uname -r)/updates/
> # depmod
> # modprobe -v 8812au
Thanks poma, I thought that might be the case. I already have the source
in a permanent location, I'll also place a text file in there with these
instructions so I don't forget.
Is the updates directory the location the default location for depmod
and modprobe? If a make install is done that places the ko file much
deeper in the directory path in a wireless subdirectory.
Is there any possibility that this driver will make it into the kernel
by default, or is the chipset too new with insufficient usage for that
to happen?
All locations are covered, however
/lib/modules/$(name -r)/updates is checked for modules first.
As for the device and official support in the kernel,
you can read Larry's response that Bob sent me.
Probably the same applies to the device you are using.