LNK4099 warnings can occur when building on Windows during the link phase of a static compilation.
E.g. when building using nmake and VC10 I get a stream of LNK4099 warnings like:
libcurl_a_debug.lib(rc2_cbc.obj) : warning LNK4099: PDB 'lib.pdb' was not found with 'libcurl_a_debug.lib(rc2_cbc.obj)' or at 'C:\dev\scaler\center\dlux\lib.pdb'; linking object as if no debug info
StackOverflow gives a good overview of the problem, but not the detail required to understand it.
Rather than ignore the warning or disable the warning, I would like to fix the makefiles in my build to remove the problem.
How does the problem arise? How do I remove the cause of the warnings?
Understand that the underlying problem is a missing debug symbols file (.pdb) for the library mentioned in the warning. Library files contain a static reference to the .pdb on an object file basis. When a library is used by another library and static compilation is used, Visual Studio collects all the symbols into a single .pdb and the .pdb references in the object files are updated. However, if it cannot find the symbols, it will leave the old path in place.
Fix the warning by recompiling the library mentioned in the warnings, and make sure the compiler has access to the .pdb of every referenced library. This involves determining which .pdb file cannot be found, and then making changes to ensure the .pdb can be found.
Which object file (and thus library) are we missing the symbols (.pdb) for?
#goth provided a blog link explaining where the .pdb reference comes from, but here is my summary:
A library contains a number of object files. Each object file includes a path to the debug symbols. We can use tools extract this information. Based on the object file and path, we can figure out which debug symbols file (.pdb) could not be found.
Open the Visual Studio Command Prompt. This creates a command shell with environment variables required to access Visual Studio tools. (Should be under "Visual Studio Tools" buried in the Start Menu, but this varies)
Obtain the internal path of the object file in the library using the lib tool's /list option. E.g.
C:\dev\libcurl\win\lib>lib /list libcurl_a_debug.lib > list_of_object_files_in_library.txt
C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>more list_of_object_files_in_library.txt
Microsoft (R) Library Manager Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/file.obj
..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/timeval.obj
..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/rc2_cbc.obj
...
Using the path, extract the object file using the lib tool's /extract option.
C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>lib /extract:..\builds\libcurl-vc10-x86-debug-static-ssl-static-ipv6-spnego-obj-lib/timeval.obj libcurl_a_debug.lib
Microsoft (R) Library Manager Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
The object file contains a debug section called .debug$T that we can extract using the dumpbin tool. E.g.
C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>dumpbin /section:.debug$T /rawdata rc2_cbc.obj > dump_of_object_file_debug_info.txt
C:\dev\scaler\center\agent\thirdparty\libcurl\win\lib>more dump_of_object_file_debug_info.txt
Microsoft (R) COFF/PE Dumper Version 10.00.40219.01
Copyright (C) Microsoft Corporation. All rights reserved.
Dump of file ./rc2_cbc.obj
File Type: COFF OBJECT
SECTION HEADER #9
.debug$T name
0 physical address
0 virtual address
5C size of raw data
1D53 file pointer to raw data (00001D53 to 00001DAE)
0 file pointer to relocation table
0 file pointer to line numbers
0 number of relocations
0 number of line numbers
42100040 flags
Initialized Data
Discardable
1 byte align
Read Only
RAW DATA #9
00000000: 04 00 00 00 56 00 15 15 03 7A 47 A3 3D 4A 8C 4B ....V....zGú=J.K
00000010: A2 A5 26 D3 D6 57 15 46 3A 00 00 00 73 3A 5C 73 óÑ&ËÍW.F:...s:\s
00000020: 63 61 6C 65 78 2E 6E 65 77 5C 63 65 6E 74 72 6F caler.new\center
00000030: 5C 6F 70 65 6E 73 73 6C 5C 62 75 69 6C 64 5C 6F \openssl\build\o
00000040: 70 65 6E 73 73 6C 2D 31 2E 30 2E 30 62 5C 74 6D penssl-1.0.0b\tm
00000050: 70 33 32 5C 6C 69 62 2E 70 64 62 00 p32\lib.pdb.
Summary
5C .debug$T
Above, you see that the object file says its debug symbols s:\scaler.new\center\openssl\build\openssl-1.0.0b\tmp32\lib.pdb. Therefore, the problem lies with the .pdb generated when we built the openssl library used by libcurl.
How do I add the debug symbols to the library generating the warning?
The /Fd option governs the name and location of the .pdb symbols file. E.g. when compiling libcurl, I used the following flags:
...
!IF DEFINED(VC10)
NT_MAK_FLAGS = APP_CFLAG="/GX /GZ /MTd /Fdtmp32.dbg/app" LIB_CFLAG="/Zl /Z7 /Fdtmp32.dbg/lib"
!ENDIF
...
The symbol file name of lib.pdb and its path relative to the build is given by /Fdtmp32.dbg/lib.
The problem is that the NT_MAK_FLAGS is reused for a number of libraries that are generated when openssl is compiled. As a result, lib.pdb is clobbered (overwritten) for all but the last library. To resolve the problem, each library should be given .pdb with a unique name. To simplify matters further, ensure that the compilation location is in the same tree as the libcurl build.
This happened to me with a library .lib and maybe the attached image will help others. In my case I had to make sure that the .lib and the .pdb file were in the same directory, so note how $(OutDir) appears in the settings.
I think they got misaligned when I imported an old 32 bit VS2010 project into VS2013 and set it up for 64 bits.
So I end up with this (good) situation:
Related
I am trying install a windows USB driver with a simple structure (containing only the following content -
app.inf,
app.cat
WdfCoInstaller01005.dll
WinUSBCoInstaller.dll
).
The driver is sha 256 signed using a valid standard kernel mode code signing certificate issued by Digicert. I could see the digital signature in the app.cat file when I am see the properties of the file.
I am trying to install the driver via install-shield setup in the Windows 7 SP1 64 Bit machine with all latest updates installed( including KB3033929). It still shows the warning Windows cant verify the publisher of this driver software.
For troubleshooting this I have tried installing the certificate in the target machine as one of the Stackoverflow link suggests. Still no hope.
I have used the following commands during the process of generating the .cat file and signing the .cat file. (There is no .sys file)
Inf2Cat /driver:"C:\CodeSigning" /os:7_X64,7_X86
C:\Program Files (x86)\Windows Kits\10\bin\10.0.15063.0\x64>signtool.exe si
gn /v /ac "C:\CodeSigning\DigiCert High Assurance EV Root CA.crt" /a /t ht
tp://timestamp.digicert.com "C:\CodeSigning\Driver\app.cat"
EDIT Adding more information.
I have tried Sha256 Signing also (Referring from https://www.digicert.com/code-signing/driver-signing-in-windows-using-signtool.htm (section :Internet Explorer or Chrome for Windows)
signtool sign /v /ac "C:\path\DigiCert High Assurance EV Root CA.crt" /a /tr http://timestamp.digicert.com /td sha256 /fd sha256 "c:\path\to\FileToSign.cat"
Still I am getting the same error.
EDIT 2- Adding the source of the Inf file
Please refer the source of the .inf file below (Could be little legacy).
[Version]
Signature = "$Windows NT$"
Class =XYZdevice
ClassGuid={ad769fbf-c592-4b8c-940a-6e3782a545e8}
Provider = %ProviderName%
DriverVer=10/13/2017,6.00.2064
CatalogFile=%MFGFILENAME%.cat
; ========== Manufacturer/Models sections ===========
[Manufacturer]
%ProviderName% = XYZInc,NTx86,NTamd64
[XYZInc.NTx86]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_1448&PID_4AC0&REV_0001
[XYZInc.NTamd64]
%USB\MyDevice.DeviceDesc% =USB_Install, USB\VID_1448&PID_4AC0&REV_0001
; =================== Installation ===================
[ClassInstall32]
AddReg=SampleClass_RegistryAdd
[SampleClass_RegistryAdd]
HKR,,,,%ClassName%
;[1]
[USB_Install]
Include=winusb.inf
Needs=WINUSB.NT
;[2]
[USB_Install.Services]
Include=winusb.inf
AddService=WinUSB,0x00000002,WinUSB_ServiceInstall
;[3]
[WinUSB_ServiceInstall]
DisplayName = %WinUSB_SvcDesc%
ServiceType = 1
StartType = 3
ErrorControl = 1
ServiceBinary = %12%\WinUSB.sys
;[4]
[USB_Install.Wdf]
KmdfService=WINUSB, WinUsb_Install
[WinUSB_Install]
KmdfLibraryVersion=1.5
;[5]
[USB_Install.HW]
AddReg=Dev_AddReg
[Dev_AddReg]
HKR,,DeviceInterfaceGUIDs,0x10000,"{15630179-b622-4834-8ff7-9916b1446884}"
;[6]
[USB_Install.CoInstallers]
AddReg=CoInstallers_AddReg
CopyFiles=CoInstallers_CopyFiles
[CoInstallers_AddReg]
HKR,,CoInstallers32,0x00010000,"WdfCoInstaller01005.dll,WdfCoInstaller","WinUSBCoInstaller.dll"
[CoInstallers_CopyFiles]
WinUSBCoInstaller.dll
WdfCoInstaller01005.dll
[DestinationDirs]
CoInstallers_CopyFiles=11
; ================= Source Media Section =====================
;[7]
[SourceDisksNames]
1 = %DISK_NAME%,,,\i386
2 = %DISK_NAME%,,,\amd64
[SourceDisksFiles.x86]
WinUSBCoInstaller.dll=1
WdfCoInstaller01005.dll=1
[SourceDisksFiles.NTamd64]
WinUSBCoInstaller.dll=2
WdfCoInstaller01005.dll=2
; =================== Strings ===================
[Strings]
MFGFILENAME="XYZDevice"
ProviderName="XYZ Inc"
ClassName="XYZ device"
USB\MyDevice.DeviceDesc="XYZ"
WinUSB_SvcDesc="XYZ"
DISK_NAME="Drivers"
I have verified the counter signature details also. Please refer the image below.
Thumbprint of the certificate used for cross signing (thumbprint: 2f 25 13 af 39 92 db 0a 3f 79 70 9f f8 14 3b 3f 7b d2 d1 43 cross-certificate for DigiCert High Assurance EV Root CA)
Thumbprint of the cross signed certificate which can be seen from the properties of the signed file is 40 01 91 47 5c 98 89 1d eb a1 04 af 47 09 1b 5e b6 d4 cb cb
(I dont know whether it is correct or not)
Please help. I have spent plenty of time on this and still end up with no results. Any help on this would be really appreciable.
BLUF
If you know a windows machine certificate file name, can you view the file contents in the windows certificate store?
Background
I am working with the Windows 7+ VPN Client. It does not let you directly select the certificate that should be used for a connection and provides very limited feedback. The most notorious error RRAC is 13801 that roughly sums up to 'I don't like something about a certificate being used, but i am not going to tell you what exactly'.
Using the Event Viewer to view Security entries, I do see that there is a request for a certificate. Something like:
ProviderName Microsoft Software Key Storage Provider
AlgorithmName UNKNOWN
KeyName {#################}
KeyType %%2499
KeyFilePath C:\ProgramData\Microsoft\Crypto\RSA\MachineKeys\<filename>
Operation %%2458
ReturnCode 0x0
I was wondering how i could use the filename mentioned above to view the certificate properties (IE: see that the one i want is being used). Right now my only method is to import a certificate via mmc and see the new file being created at the time of import. I cannot use this trick for certificates that are already imported on the system.
All of the identifiers here are for the private key. The private key doesn't know where the certificate lives, because the architecture is that the cert object / cert store know where the private key is for a given certificate.
To see the mapping between certs in a cert store and the keys on the system you can use certutil -store, e.g.:
C:\>certutil -store my
my
================ Certificate 0 ================
...
================ Certificate 7 ================
Serial Number: 3451b93c10f9279348a949f729d1ff10
Issuer: CN=localhost
NotBefore: 1/26/2015 2:19 PM
NotAfter: 1/25/2020 4:00 PM
Subject: CN=localhost
Signature matches Public Key
Root Certificate: Subject matches Issuer
Template:
Cert Hash(sha1): 15 e3 4c d3 2d a7 54 99 a9 17 8f 17 26 25 63 25 8f 3a 94 28
Key Container = IIS Express Development Certificate Container
Unique container name: fad662b360941f26a1193357aab3c12d_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd
Provider = Microsoft RSA SChannel Cryptographic Provider
Encryption test passed
CertUtil: -store command completed successfully.
Where the thing to match is Key Container in this output is the same as KeyContainerName in the event, and Provider in this output is ProviderName in the event.
You can also dump the user store (the default is the machine):
C:\>certutil -user -store -silent my
my
================ Certificate 0 ================
Serial Number: 0123456789abcdef
Issuer: E=issueremail#example.org, CN=cn.issuer.example.org, OU=ExampleOU, O=ExampleO, L=Locality, S=State, C=Country
NotBefore: 11/12/2013 6:15 AM
NotAfter: 12/13/2014 7:16 AM
Subject: E=subjectemail#example.org, CN=cn.subject.example.org, OU=ExampleOU, O=ExampleO, L=Locality, S=State, C=Country
Non-root Certificate
Template:
Cert Hash(sha1): ff 3d 35 54 54 fd ff ea 52 cd 71 6f e7 14 24 75 3f f7 fe cf
Key Container = {F76693EF-BDC3-4AEC-855A-3A2F65EB9C14}
Unique container name: 0148994a057f4e05acb6407550cdde40_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd
Provider = Microsoft Enhanced RSA and AES Cryptographic Provider
Private key is NOT exportable
Encryption test passed
...
================ Certificate 51 ================
Serial Number: 0123456789abcdef
Issuer: E=issueremail#example.org, CN=cn.issuer.example.org, OU=ExampleOU, O=ExampleO, L=Locality, S=State, C=Country
NotBefore: 11/12/2013 6:15 AM
NotAfter: 12/13/2014 7:16 AM
Subject: E=subjectemail#example.org, L=Locality, S=State, C=Country
Non-root Certificate
Template:
Cert Hash(sha1): 2a 81 f8 d1 c7 40 13 2f 15 5a 5e 30 41 1a 2b 13 71 93 db 9e
Key Container = {2572D484-D352-4B32-BB00-236B755B7F81}
Unique container name: b11d717c1718a3bc6ad1769f2226998e_1fcb2e07-cec4-4ba1-9c78-58a431e1aefd
Provider = Microsoft Enhanced RSA and AES Cryptographic Provider
Private key is NOT exportable
Encryption test passed
In addition to the -user switch I specified -silent, because I have some smartcard backed certificates and I didn't want to deal with getting prompted for the card and PIN.
Summary: A VS2015 solution with mixed C and Assembler, does not display symbols in assembler code when debugging after upgrading to VS2017 or VS2019).
[Oct 2109: problem solved, see note at end].
Long details:
I have a VS 2015 xxx.sln with 32 bit C code compiled by the VS 2015 compiler, with a large 32 bit assembler code parlanse0.asm assembled by a custom command line:
parlanse0.asm Property Pages
Item Type: Custom Build Tool
Command Line: ml /D SANITYCHECKS="1" /D EVENTBUFFERENABLE="1" /D TESTING="1" /D PROFILE="0" /Sg /Sl132 /Sx /Zd /Zi /c /Cx /coff /Zd /Fl "%(FullPath)"
Outputs: parlanse0.obj;%(Outputs)
Additional Dependencies: <list of MASM include file>
Link Objects: Yes
Treat Output As Content: No
I'm not sure this is relevant, but here's the Linker options:
/OUT:"Debug\run.exe" /MANIFEST /PROFILE /NXCOMPAT:NO /PDB:"Debug/erun.pdb" /DYNAMICBASE:NO "odbc32.lib" "odbccp32.lib" "netapi32.lib" "iphlpapi.lib" "psapi.lib" "kernel32.lib" "user32.lib" "gdi32.lib" "winspool.lib" "comdlg32.lib" "advapi32.lib" "shell32.lib" "ole32.lib" "oleaut32.lib" "uuid.lib" /LARGEADDRESSAWARE /MACHINE:X86 /SAFESEH:NO /INCREMENTAL:NO /PGD:".\Debug\run.pgd" /SUBSYSTEM:CONSOLE",5.01" /MANIFESTUAC:"level='asInvoker' uiAccess='false'" /ManifestFile:".\Debug\run.exe.intermediate.manifest" /MAP":.\Debug/run.map" /ORDER:#"RTSCFunctionOrder.txt" /ERRORREPORT:PROMPT /NOLOGO /LIBPATH:"C:\Program Files\Microsoft Platform SDK\Lib" /DELAYLOAD:"iphlpapi.dll" /DELAYLOAD:"comdlg32.dll" /TLBID:1
[If this is the linker command line, where does it get the names of the .obj files it processes?]
This solution compiles/builds/runs fine under VS 2015.
I'm trying to upgrade to VS 2017 (update: Sept 2019, problem never resolved, so I just tried it again with VS 2019... same problem).
The upgrade seemed trivial: I simply started VS 2017 and pointed it at the VS 2015 solution file. Apparently
nothing changes, at least my source control (over the various MS build files like .sln don't see any changes). Magically, almost everything works: I can compile/run/debug the application.
However, the assembly source code is no longer visible when I'm in the debugger and attempt to "go to source code" when I've stepped into a bit of assembler. "Goto source code" from the assembler works fine in VS 2015. Likewise, if during debugging I choose an assmbley language source line and attempt to "Go to disassembly" I get a pop-up window "Disassembly cannot be displayed... there is no executable code associated with this location", and that's clearly wrong. Also behavior that was find under VS 2015.
What do I have to change? Are there documents somewhere that describe what is different?
[Addition: The assembler source is in a different directory than the .C sources. This causes the .sbr file for the assembler code to be produced in a different directory from the .sbr files for the C code. Apparently the assembler code .sbr is not picked up the build process; in one of the log files I can see all the .sbr files for the C code but not for the assembler.
So this doesn't look right. However, my understanding is .sbr files support VisualStudio tag lookup, not object-location-to-source-line map so I think this is a red herring. Where is the object-location-to-source-line map produced? Does the linker do it?]
[Addition: following the advice in the comments to look at another answer, I changed the /DEBUG option to /DEBUG:FULL with no apparent effect on the problem.]
[I found some article on PDB files, and how the C++ compiler "updates" it as is compiles individual .cpp (.c?) files. Is MASM supposed to generate a PDB files? So... how would MASM update the compiler's target PDB file?]
... added after 2 month delay ...
I see this in a disassembly window on my assembler code:
00480107 CC int 3
00480108 CC int 3
RTSAllocate11D_end:
00480109 8D A4 24 00 00 00 00 lea esp,[esp]
00480110 8D A4 24 00 00 00 00 lea esp,[esp]
00480117 8D A4 24 00 00 00 00 lea esp,[esp]
0048011E 8D A4 24 00 00 00 00 lea esp,[esp]
00480125 8D A4 24 00 00 00 00 lea esp,[esp]
0048012C 8D A4 24 00 00 00 00 lea esp,[esp]
00480133 8D A4 24 00 00 00 00 lea esp,[esp]
0048013A 8D 9B 00 00 00 00 lea ebx,[ebx]
allocate_2to1E_bytes:
These are my symbols, so they are clearly getting to the debugger. I ask the disassembly window to show line numbers... it does nothing. So somehow the symbols are getting through, but not the line number information or maybe not the source file location. Thoughts?
EDIT: October 9, 2019: PROBLEM CLAIMED SOLVED. A long interaction with Microsoft got them to agree this is a problem in the debugger. I verified that VS 2015 Update 1 was the last version that worked properly; VS 2015 Update 2 and later, VS 2017 and VS 2019 all suffer from the same problem. MS has told me that they have identified the problem and a fix will be available in VS 2019 v16.4 Public Release in December 2019.
for have debugging info (in pdb file) need 2 steps:
compiler must include debugging information to obj file for ml[64]
compiler this is /Zd option
linker must have /DEBUG option in command line. in this case it
get debug info (stored in .debug$S sections of obj / lib files) and
create pdb file
if command line both for compiler and linker correct (have this options) need check in following order:
look in .obj file in any text/binary viewer - are full path string
of sourse asm file name exist in file. simply search for
PARLANSE0.ASM (or how your source file named) in file as is (all
names stored as ansi plain text) - are this name is found are path
is correct ? if yes - this mean with compiler (ml in our case all
correct and we can go forward)
look in pdb file - are this strings exist here also ?
look in exe file - search for .pdb - are full (and correct) path
for your pdb exist in exe file ? again it stored as plain ansi
text
try alternative debugger use - i be suggest windbg - are he can
go to source. for easy check you even can make special temporary
build - set breakpoint before go to asm code (or direct in some asm
procedure) and call this procedure at very begin of exe. even if
this "incorrect" by logic - we need only check - are debugger
understand pdb format and can show source for asm
if windbg can go to asm source code - this mean some problem with integrated vs2017 debugger. if windbg can not - some problems with pdb format generated
Change the assembly file name P.asm to parlanse0.asm
or Add /Fo parlanse0.obj to the beginning of your custom build script.
You cannot generate parlanse0.obj and debug related files(parlanse0.iobj, parlanse0.ipdb) via yours. However, you may build without any problems since the files were compiled before.
I have an ACS ACR122T-E2 NFC reader. I downloaded the linux driver and the ct-api library from
http://www.acs.com.hk/en/products/109/acr122t-usb-tokens-nfc-reader/ .
I have extracted the sample C program from the header given in the ct-api library archive file. I compiled it. I also created the ctacs.ini file with this content:
[CardTerminal]
CTN1=ACR122T
[ACR122T]
ICC1=ACS ACR122 25 00
When I running the compiled executable I just get:
Error: CT_init failed with error -8
where -8 is for "CT Error" based on the documentation in the header file.
Does somebody have some experience with this ACR122T-E2 and the official C API given for it?
Does anyone have some idea on what should I check for or what should I try to do?
The only one thing I guess I might be wrong with, is the ctacs.ini file. I am not really sure if the
ICC1=ACS ACR122 25 00
line is right. I used "lsusb -t" which shows:
Bus 03.Port 1: Dev 25, If 0, Class=Chip/SmartCard, Driver=pn533, 12M
Of course I already have tried
ICC1=ACS ACR122 03 01
config line, but did not help.
Does anybody have some idea, what this configuration line should be?
A after several hour of reading different posts at different sites, studying the available NFC related packages on Ubuntu, and also got a bit of help from the maintainer/developer of the official ACS driver I managed to get this example program to work.
The solution is, to unload/remove the kernel's default drivers.
modprobe -r np533
modprobe -r nfc
Then to install and run pcscd:
apt-get install pcscd
service start pcscd
Install pcsc_scan:
apt-get install pcsc-tools
Now pcsc_scan can be used to figure out the right ICC line for the ini file:
...
Reader 0: ACS ACR122U 00 00
...
Thus the right content the ini file is:
[CardTerminal]
CTN1=ACR122T
[ACR122T]
ICC1=ACS ACR122U 00 00
Now running the compiled example C program (from the ct-api library archive file downloaded from ACS) the output is:
Response: 62 00
Not much, but at least it is working now and I can continue exploring this NFC world.
I am using Windows and was struggling with the ctacs.ini file too. The trick (for me) was retrieving and using the actual CCID name. I retrieved mine by using "Springcard pcsc quick start" which shows the CCID name when the program opens. I use an ACS ACR122U-A9 with windows 8.1. The ini file below works for me.
[CardTerminal]
CTN1=ACS-ACR122-0 ;Just a name, can be an arbitrary value
[ACS-ACR122-0] ;Must correspond to name given above
ICC1=ACS ACR122 0 ;This is the actual name of the device (CCID)
How can I compile usb-storage.ko (only) from kernel source tree ?
Running kernel version: 2.6.35-22-generic (uname -r)
Source version: linux-2.6.35
Doing modprobe usb-storage gives the below error.
FATAL: Error inserting usb_storage (/lib/modules/2.6.35-22-generic/kernel/drivers/usb/storage/usb-storage.ko): Invalid module format
Doing insmod gives the below error.
insmod: error inserting 'drivers/usb/storage/usb-storage.ko': -1 Invalid module format
dmesg gives as below.
usb_storage: no symbol version for module_layout
How can I change the top level Makefile to get it inserted into running version of kernel ?
Makefile(top level)
VERSION = 2
PATCHLEVEL = 6
SUBLEVEL = 35
EXTRAVERSION =
NAME = Sheep on Meth
During kernel development one often encounters these 2 frustrating errors upon insmod ing locally built ko modules.
Error1: <module-name> no symbol version for module_layout
Why?
This means that the Kernel source is NOT built. Once the entire kernel source is built, then a file Modules.symvers will be generated in the top-level directory of the Linux Kernel source. This will contain the address of the symbol module_layout. Henceforth, this will be used when any kernel modules are built.
Fix
Build the complete Kernel source. Ensure that Modules.symvers is generated and it contains a line with the symbol module_layout. Following this, build the kernel module.
Error2: <module-name> disagrees about version of symbol module_layout
Why?
The error means that the kernel source being used differs significantly from the one used to build the kernel image used to boot.
Fix
Manually modifying the ko module file to match the value of module_layout in the ko file with the value in the kernel image being used to boot.
To do so we first need to determine the valid value of module_layout. This is essentially present in each of the valid working ko files present on the system. A quick way to obtain this info is from a valid ko file that successfully loads. Use lsmod to get a list of potential "working.ko" files.
# modprobe --dump-modversions <working.ko> | grep module_layout
0x0b11e775 module_layout
# modprobe --dump-modversions <your.ko> | grep module_layout
0x2719d41e module_layout
NOTE: IF there is no instance of module_layout symbol in your ko file then first follow steps to fix ERROR1 before proceeding below.
Using your favorite hex editor, find and replace the value (4 bytes) in your ko file with the value from the working ko file.
Before Modification:
00016c701e d4 19 276d 6f 64 75 6c 65 5f 6c 61 79 6f 75 |u...module_layou|
After Modification:
00016c7075 e7 11 0b6d 6f 64 75 6c 65 5f 6c 61 79 6f 75 |u...module_layou|
With the above changes, insmod ing the locally built ko file should be successfull.