- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello, everyone,
Found, that ICC handles PDB files in somewhat different way than MSVC do, which could lead to errors during build. E.g. for OpenSSL builds using ICC on Windows got:
1. improper PDB files naming:
[run 'Compiler 17.0 Update 2 for Intel 64 Visual Studio 2015 environment' command && change into OpenSSL sources directory] c:\libOPENSSL-1.1.1-dev\build>set CC=icl c:\libOPENSSL-1.1.1-dev\build>perl Configure threads no-deprecated shared no-asm VC-WIN64A && nmake [snip] "C:\ProgramData\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "crypto\include\internal\bn_conf.h.in" > crypto\include\internal\bn_conf.h "C:\ProgramData\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "crypto\include\internal\dso_conf.h.in" > crypto\include\internal\dso_conf.h "C:\ProgramData\Perl64\bin\perl.exe" "-I." -Mconfigdata "util\dofile.pl" "-omakefile" "include\openssl\opensslconf.h.in" > include\openssl\opensslconf.h icl /I "." /I "crypto\include" /I "include" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_API_COMPAT=0x10100000L "-DENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 /Zi /Fdossl_static -c /Focrypto\aes\aes_cbc.obj "crypto\aes\aes_cbc.c" aes_cbc.c error #31000: corrupt PDB file ossl_static\vc140.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead error code 3 ( can't write file, out of disk, etc.) opening pdb ossl_static\vc140.pdb compilation aborted for crypto\aes\aes_cbc.c (code 1) NMAKE : fatal error U1077: '"C:\Program Files (x86)\IntelSWTools\compilers_and_libraries\windows\bin\intel64\icl.EXE"' : return code '0x1' Stop.
which relate to compiler keys
'/Fdossl_static
', '/Fddso
' and '/Fdapp
'
in file 'Configurations/10-main.conf
' from OpenSSL sources folder.
And if they are changed to
'/Fdossl_static.pdb
', '/Fddso.pdb
' and '/Fdapp.pdb
'
before build, PDB files are created with proper names
'ossl_static.pdb
', 'dso.pdb
' and 'app.pdb
',
and all 'nmake
' tasks finishes successfully.
Error not reproduces for builds using MSVC. E.g. ICC, unlike MSVC, require explicitly specify '.pdb
' extension of PDB files in '/Fd
' keys. Otherwise ICC set PDB file names to '...\vc140.pdb
'.
2. improper PDB files handling for parallel builds:
[extract 'jom' and 'nasm' executables to OpenSSL directory && run 'Compiler 17.0 Update 2 for Intel 64 Visual Studio 2015 environment' command && change into OpenSSL sources directory] c:\libOPENSSL-1.1.1-dev\build>set CC=icl c:\libOPENSSL-1.1.1-dev\build>perl Configure -QxAVX -fp:strict -Qprec -Zc:wchar_t -nologo -Qstd=c11 -O3 -MD threads no-deprecated shared VC-WIN64A && jom /J4 [snip] icl /I "include" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_API_COMPAT=0x10100000L "-DENGINESDIR=\"C:\\Program Files\\OpenSSL\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\Program Files\\Common Files\\SSL\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 -QxAVX -fp:strict -Qprec -Zc:wchar_t -nologo -Qstd=c11 -O3 -MD /Zi /Fdapp.pdb -c /Fotest\buildtest_x509v3.obj "test\buildtest_x509v3.c" icl: command line warning #10120: overriding '/O2' with '/O3' buildtest_x509v3.c IF EXIST test\shlibloadtest.exe.manifest DEL /F /Q test\shlibloadtest.exe.manifest error #31000: corrupt PDB file app.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead error code 3 ( can't write file, out of disk, etc.) opening pdb app.pdb compilation aborted for test\buildtest_x509.c (code 1) jom: C:\libOPENSSL-1.1.1-dev\build\Makefile [test\buildtest_x509.obj] Error 1 link /nologo /debug /subsystem:console /opt:ref /out:test\shlibloadtest.exe @C:\Users\test\AppData\Local\Temp\shlibloadtest.exe.5752.221687.jom IF EXIST test\shlibloadtest.exe.manifest mt -nologo -manifest test\shlibloadtest.exe.manifest -outputresource:test\shlibloadtest.exe jom: C:\libOPENSSL-1.1.1-dev\build\Makefile [all] Error 2
Error reproduced for Release+Shared
configuration if jobs number > 3 (other configurations require more; need be verified). Running 'nmake
' or 'jom /J1
' command from that point continue build and successfully finishes all tasks.
ICC has no appropriate compiler key for PDB files handling during parallel builds (similar to '/FS
' for MSVC). Then assumed, that ICC dealing with this "things" by itself. In such case it turns out, that ICC has limitation on parallel jobs number for single PDB file processing, which MSVC hasn't.
Since ICC on Windows imitates MSVC, is it possible to make its behavior regarding PDB files identical to MSVC for both cases above?
UPDATE: Reproduced 'error #31000: corrupt PDB file' for Boost-1.64 parallel build using ICC with Debug+Shared configuration for Boost.Thread module. Not reproduced, if build made without parallelism.
Environment:
- Windows 10 x64,
- IPSXE 2017 Update 2,
- VS 2015 Update 3,
- Windows SDK 10.0.14393.33,
- Active Perl 5.24.1,
- nasm 2.13rc20,
- jom 1.1.2,
- OpenSSL 1.1.1-dev (f919c12f5c8b92f0318c650573e774fe6522c27c).
Alexander
- Tags:
- CC++
- Development Tools
- Intel® C++ Compiler
- Intel® Parallel Studio XE
- Intel® System Studio
- Optimization
- Parallel Computing
- Vectorization
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks for the report. From a debug developer:
I filed CMPLRS-42592 against DGI for the first issue.
The second issue is an unsupported feature and is documented in CMPLRS-4435..
This is from the description in CMPLRS-4435:
MSPDBSRV.EXE is a service that gets started by VS to handle access to the pdb file. I believe it has been troublesome in the past when doing parallel builds (for both MS and us). If it’s not already running, I think it will get started when we make a call into one of the mspdb dlls. It’s purely a guess on my part, but perhaps they have developed a replacement for MSPDBSRV.EXE that is the new default and the /FS switch forces the old behavior. We’ll want to look at this and possibly support this switch.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
thanks for the report. From a debug developer:
I filed CMPLRS-42592 against DGI for the first issue.
The second issue is an unsupported feature and is documented in CMPLRS-4435..
This is from the description in CMPLRS-4435:
MSPDBSRV.EXE is a service that gets started by VS to handle access to the pdb file. I believe it has been troublesome in the past when doing parallel builds (for both MS and us). If it’s not already running, I think it will get started when we make a call into one of the mspdb dlls. It’s purely a guess on my part, but perhaps they have developed a replacement for MSPDBSRV.EXE that is the new default and the /FS switch forces the old behavior. We’ll want to look at this and possibly support this switch.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thank you for a quick response. It will be convenient to get this functionality, or at least part of it, in future ICC versions.
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
With regards to the second issue, adding support for the "/FS" option in ICC unfortunately would not resolve this error. The description of the "/FS" option includes the following text:
"The /FS compiler option prevents the compiler from locking the PDB file and forces writes to go through MSPDBSRV.EXE, which serializes access."
The "/FS" option was added in VS2013 because the default behavior of MSVC was changed to avoid using MSPDBSRV.EXE in an attempt to reduce compile time. Prior to VS2013, writes to the pdb file always went through MSPDBSRV.EXE.
Forcing writes of the PDB file to go though MSPDBSRV.EXE is actually the only method ICC supports, i.e. the "/FS" behavior is always enabled with ICC when using /Zi.
The other option for writing debug info, /Z7, will cause the compilers to write all the debug info (not just some) into the object files. The pdb file will then get generated at link time. The downside to this approach is it will increase object file size and link time.
-Steve
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Just tested OpenSSL parallel build using MSVC _without_ '-FS' key and got error:
cl /I "." /I "crypto\include" /I "include" /I "c:\libOPENSSL-1.1.1-dev\build\..\..\libZLIB-1.2.11\MSVC64RH\include" -DZLIB -DZLIB_SHARED -D"LIBZ=\"ZLIB1\"" -DOPENSSL_USE_APPLINK -DDSO_WIN32 -DNDEBUG -DOPENSSL_THREADS -DOPENSSL_NO_STATIC_ENGINE -DOPENSSL_PIC -DOPENSSL_IA32_SSE2 -DOPENSSL_BN_ASM_MONT -DOPENSSL_BN_ASM_MONT5 -DOPENSSL_BN_ASM_GF2m -DSHA1_ASM -DSHA256_ASM -DSHA512_ASM -DRC4_ASM -DMD5_ASM -DAES_ASM -DVPAES_ASM -DBSAES_ASM -DGHASH_ASM -DECP_NISTZ256_ASM -DPADLOCK_ASM -DPOLY1305_ASM -DOPENSSL_API_COMPAT=0x10100000L -DWIN32 -D_WIN32 -DWIN64 -D_WIN64 -DUNICODE -D_UNICODE -D_CRT_SECURE_NO_DEPRECATE -D_SCL_SECURE_NO_DEPRECATE -DNDEBUG -D_NDEBUG "-DENGINESDIR=\"C:\\libOPENSSL-1.1.1-dev\\MSVC64RH\\lib\\engines-1_1\"" "-DOPENSSLDIR=\"C:\\libOPENSSL-1.1.1-dev\\build\\..\\MSVC64RH\\ssl\"" -W3 -wd4090 -Gs0 -GF -Gy -nologo -DOPENSSL_SYS_WIN32 -DWIN32_LEAN_AND_MEAN -DL_ENDIAN -D_CRT_SECURE_NO_DEPRECATE -DUNICODE -D_UNICODE /MD /O2 -arch:AVX -fp:strict -Zc:wchar_t -nologo -O2 -MD /Zi /Fdossl_static -c /Focrypto\aes\aes_ige.obj "crypto\aes\aes_ige.c" aes_ige.c crypto\aes\aes_ige.c: fatal error C1041: cannot open program database 'c:\libOPENSSL-1.1.1-dev\build\ossl_static.pdb'; if multiple CL.EXE write to the same .PDB file, please use /FS
which is pretty similar to ICC error from second issue:
error #31000: corrupt PDB file app.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead error code 3 ( can't write file, out of disk, etc.) opening pdb app.pdb
E.g. both errors relate to inability "write to (the same .PDB) file". And MSVC parallel build error not reproduced, if '-FS' option is used. Thus I assume '-FS' option relate to this issue.
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Any news on this? CMPLRS-42592 reproduced in IPSXE 2018 Update 3:
c:\test>echo void foo(){}; > test.c && icl -nologo -c test.c -Fdtest && echo SUCCEDED || echo FAILED test.c SUCCEDED c:\test>echo void foo(){}; > test.c && icl -nologo -c test.c -Zi -Fdtest && echo SUCCEDED || echo FAILED test.c error #31000: corrupt PDB file test\vc140.pdb; delete and rebuild; if problem persists, delete and try /Z7 instead error code 3 ( can't write file, out of disk, etc.) opening pdb test\vc140.pdb compilation aborted for test.c (code 1) FAILED c:\test>echo void foo(){}; > test.c && icl -nologo -c test.c -Zi -Fdtest.pdb && echo SUCCEDED || echo FAILED test.c SUCCEDED
while was expected to be fixed in IPSXE 2018 Update 2.
Alexander
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I've had issues on Windows builds with "failure to write to ...pdb" being caused by the Anti-Virus software having a file lock on the file. To correct for this, set an exclusion for the output folder.
Jim Dempsey

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page