When trying to create a release build of my plugin bundle, the linker fails to succeed because it cannot strip the symbols.
Here is the output:
/Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/strip: symbols referenced by indirect symbol table entries that can't be stripped in: <long path to binary here>
_SecKeychainAddGenericPassword
_SecKeychainAddInternetPassword
_SecKeychainFindGenericPassword
_SecKeychainFindInternetPassword
_SecKeychainItemCopyContent
_SecKeychainItemDelete
_SecKeychainItemFreeContent
_SecKeychainItemModifyAttributesAndData
_SecKeychainLock
_SecKeychainUnlock
_NSLog
_NSStringFromSelector
_NSTemporaryDirectory
_class_addMethod
_class_getInstanceMethod
_class_getInstanceSize
_class_getInstanceVariable
_class_getIvarLayout
_class_getSuperclass
_ivar_getName
_ivar_getOffset
<some other objective-c symbols here, all from system frameworks>
_objc_autoreleasePoolPush
_objc_msgSend
_objc_release
_objc_retain
Interestingly no symbols from the frameworks the project loads or symbols from my code show up here.
The strip style is set to "all symbols", which was the default.
Related
I am trying to use google breakpad, but I am facing a strange issue.
i am working in linux. I have my own library, my_lib.so, which I process with dump_syms and generates this symbol :
$ dump_syms my_lib.so|head -2
MODULE Linux mips 3BB485681467218D36EB2FF02287096C0 my_lib.so
INFO CODE_ID 6885B43B67148D2136EB2FF02287096C
I create the symbols directory with the appropiate subdirectories. I then generate a minidump for the program that uses a stripped version of my_lib.so, but when I try to process it with minidump_stackwalk:
0x77dce000 - 0x77e23fff my_lib.so ??? (WARNING: No symbols, my_lib.so, AC40136B433E5A68F66CCE8C2C2E6C250)
It is seaching for a differente ID, AC40136B433E5A68F66CCE8C2C2E6C250, so it does not find the symbols. Why the mismatch?
Knowing that it searches for AC40136B433E5A68F66CCE8C2C2E6C250 I manually changed the tree directory in symbols, to match that one, just to test. I also changed the id inside the my_lib.so.sym file, and then minidump_stalkwalk does not complain about not finding the symbols, but still I can't see the stack trace.
Any ideas about this mismatch?
by the way, if I run readelf -n over the original library and the stripped one, I get the same GNU BUILD ID.
duplicate symbol _GTMNSDictionaryURLArgumentsExportToSuppressLibToolWarning in:
/Users/Varshana/Library/Developer/Xcode/DerivedData/Lodore-axtsfmjdyxbqyccujoquacrynsxv/Build/Products/Debug-iphonesimulator/GoogleToolboxForMac/libGoogleToolboxForMac.a(GTMNSDictionary+URLArguments.o)
/Users/Varshana/Documents/Lodore final stage/GoogleSignInDependencies.framework/GoogleSignInDependencies(GTMNSDictionary+URLArguments_aec9c2446af4c2ac5a7380b418b337ea.o)
duplicate symbol _kGTMOAuth2WebViewKey in:
/Users/Varshana/Library/Developer/Xcode/DerivedData/Lodore-axtsfmjdyxbqyccujoquacrynsxv/Build/Products/Debug-iphonesimulator/GTMOAuth2/libGTMOAuth2.a(GTMOAuth2Authentication.o)
/Users/Varshana/Documents/Lodore final stage/GoogleSignInDependencies.framework/GoogleSignInDependencies(GTMOAuth2Authentication_ad53759ab562393658e6c193e56628dd.o)
duplicate symbol _kGTMOAuth2ErrorRequestKey in:
/Users/Varshana/Library/Developer/Xcode/DerivedData/Lodore-axtsfmjdyxbqyccujoquacrynsxv/Build/Products/Debug-iphonesimulator/GTMOAuth2/libGTMOAuth2.a(GTMOAuth2Authentication.o)
/Users/Varshana/Documents/Lodore final stage/GoogleSignInDependencies.framework/GoogleSignInDependencies(GTMOAuth2Authentication_ad53759ab562393658e6c193e56628dd.o)
don't worry, just xcode bug. try clean and build and it will work, or better, go to xcode->preferences->location->Derived Data. delete all files inside derived data and then restart xcode. clean and build the project and then it will work perfectly
ps: updated for cleaning
Cmd + Shift + Alt + K
To check the exact error for this issue check following:
Select issue navigator > Click on error will show logs for error > In that select All Messages tab.
75 duplicate symbols for architecture x86_64
Means that you have loaded same functions twice. As the issue disappear after removing -ObjC from Other Linker Flags, this means that this option result that functions loads twice:
from Technical Q&A
This flag causes the linker to load every object file in the library
that defines an Objective-C class or category. While this option will
typically result in a larger executable (due to additional object code
loaded into the application), it will allow the successful creation of
effective Objective-C static libraries that contain categories on
existing classes.
https://developer.apple.com/library/content/qa/qa1490/_index.html
I am writing a Fortran code using Emacs and CMake with the Ninja generator. If, instead of Ninja I use make as the generator, and there's a coding mistake, I get an error message like
/home/raul/Projects/test/main.f90:54:9:
my_cols = 1
1
Error: Symbol ‘my_cols’ at (1) has no IMPLICIT type
Emacs reports the correct location of the source file along with line and column numbers so that I can quickly jump to the offending code. On the other hand, with Ninja, the error message returned looks something like this:
CMakeFiles/run.dir/main.f90-pp.f90:54:9:
1
Error: Symbol ‘my_cols’ at (1) has no IMPLICIT type
I am pointed to what looks like a preprocessed Fortran source file, not the original source file. The line and column numbers correspond to the original file, and the contents of the error message is slightly different (the line above "1" has gone missing). This is clearly annoying because I need to make any fixes in the original file, not the preprocessed one. Is there any way to change this behavior? I'm not sure whether this has something to do with Emacs, Ninja, Cmake, or Fortran.
EDIT. Minimal example.
# CMakeLists.txt
cmake_minimum_required(VERSION 3.0)
project(test Fortran)
add_executable(main main.f90)
# main.f90
implicit none
a = 5
end program
With gfortran, I get
[3/4] Building Fortran object CMakeFiles/main.dir/main.f90.o
FAILED: CMakeFiles/main.dir/main.f90.o
/usr/bin/f95 -I../ -c CMakeFiles/main.dir/main.f90-pp.f90 -o CMakeFiles/main.dir/main.f90.o
CMakeFiles/main.dir/main.f90-pp.f90:2:3:
# 1 "<built-in>"
1
Error: Symbol ‘a’ at (1) has no IMPLICIT type
ninja: build stopped: subcommand failed.
Interestingly, with the Intel Fortran compiler (ifort) I get
[3/4] Building Fortran object CMakeFiles/main.dir/main.f90.o
FAILED: CMakeFiles/main.dir/main.f90.o
/opt/intel/compilers_and_libraries_2017.4.196/linux/bin/intel64/ifort -I../ -c CMakeFiles/main.dir/main.f90-pp.f90 -o CMakeFiles/main.dir/main.f90.o
../main.f90(2): error #6404: This name does not have a type, and must have an explicit type. [A]
a = 5
--^
compilation aborted for CMakeFiles/main.dir/main.f90-pp.f90 (code 1)
ninja: build stopped: subcommand failed.
The error message is slightly different and now it is able to point to the correct location. (On a more complex project with several subdirectories also ifort gets it wrong.)
I have managed to build the Kicad 4.0.6 in Linux Mageia 5.1 with gcc version 4.9.2. I first manually fixed two wxWidgets 3.0.2 header files in the /usr/include/wx-3.0/wx/ directory: regex.h and features.h. Kicad then compiled successfully. With the native wx-3.0 headers, the compiler generated the error in pcbnew/netlist_reader.cpp due to the undefined variable wxRE_ADVANCED.
The features.h header checks if the macro WX_NO_REGEX_ADVANCED is defined. If yes, features.h UNdefines wxHAS_REGEX_ADVANCED macro, and defines it, if no. The macro wxHAS_REGEX_ADVANCED, in turn, is used in regex.h to determine if among the enum constants wxRE_ADVANCED = 1 is present. The standard prebuilt Mageia 5 packages wxgtku3.0_0 and lib64wxgtku3.0-devel that I installed with the use of Mageia's software manager urpmi from Mageia repository WX_NO_REGEX_ADVANCED is defined, therefore wxHAS_REGEX_ADVANCED is undefined, and, hence, wxRE_ADVANCED is undefined either. Kicad 4.0.6 source package assumes wxRE_ADVANCED = 1, therefore the build process stops with the error.
Then I reverted /usr/include/wx-3.0/wx/regex.h and features.h to their original state and learned how to add the definition of wxRE_ADVANCED to CMakeLists.txt. However, I still have a question.
The recommended format of adding the definition to CMakeLists.txt I found at CMake command line for C++ #define is this:
if (NOT DEFINED wxRE_ADVANCED)
set(wxRE_ADVANCED 1)
endif()
add_definitions(-DwxRE_ADVANCED=$(wxRE_ADVANCED))
However, it did not work! The macro expansion for wxRE_ADVANCED in pcbnew/netlist_reader.cpp was empty. I printed it at compile time inserting the following lines into the netlist_reader.cpp file (this was hard to find, most of the recommended formats did not work. The correct one is in C preprocessor: expand macro in a #warning):
#define __STRINGIFY(TEXT) #TEXT
#define __WARNING(TEXT) __STRINGIFY(GCC warning TEXT)
#define WARNING(VALUE) __WARNING(__STRINGIFY(wxRE_ADVANCED = VALUE))
Pragma (WARNING(wxRE_ADVANCED))
Finally, I simplified the CMakeLists.txt definition down to this, and it was a success:
if (NOT DEFINED wxRE_ADVANCED)
set(wxRE_ADVANCED 1)
endif()
add_definitions(-DwxRE_ADVANCED=1)
My question: what is the meaning of "-DwxRE_ADVANCED=$(wxRE_ADVANCED)" if it does not work? Is it possible not to use set(wxRE_ADVANCED 1), and simply write add_definitions(-DwxRE_ADVANCED=1)? Thank you.
P.S. Yes, the Kicad 4.0.6 build process successfully finished with only one line added to the top level CMakeLists.txt file:
add_definitions(-DwxRE_ADVANCED=1)
A variable is called via $variable or ${variable}. Note the curly brackets, not parentheses.
Also, it is recommended to use:
target_compile_definitions(mytarget PUBLIC wxRE_ADVANCED=1)
on a target directly, rather than the general add_definitions() command.
I have next workflow:
1) Build dll and pdb files.
2) Share dll to cutomer
3) Analize memory dump from customer.
When I run !analyze -v in WinDbg I got (below part of output)
....
MANAGED_STACK_COMMAND: _EFN_StackTrace
PRIMARY_PROBLEM_CLASS: WRONG_SYMBOLS
BUGCHECK_STR: APPLICATION_FAULT_WRONG_SYMBOLS
// some callstack here
MODULE_NAME: RTPLogic
IMAGE_NAME: RTPLogic.dll
DEBUG_FLR_IMAGE_TIMESTAMP: 58a43706
STACK_COMMAND: ~541s; .ecxr ; kb
FAILURE_BUCKET_ID: WRONG_SYMBOLS_c0000374_RTPLogic.dll!CSRTPStack::Finalize
BUCKET_ID: X64_APPLICATION_FAULT_WRONG_SYMBOLS_rtplogic!CSRTPStack::Finalize+1da
Looks like we have wrong debug symbol for RTPLogic.dll.
I download ChkMatch tool.
I get pdb path from windbg
0:541> !lmi RTPlogic.dll
Loaded Module Info: [rtplogic.dll]
Module: RTPLogic
.....
Age: 1, Pdb: D:\Work\path_to_original_pdb\RTPLogic.pdb
Image Type: MEMORY - Image read successfully from loaded memory.
Symbol Type: PDB - Symbols loaded successfully from image header.
C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
Compiler: Resource - front end [0.0 bld 0] - back end [9.0 bld 21022]
Load Report: private symbols & lines, not source indexed
C:\ProgramData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb
I have logs related to this dump and I see that my changes appears in logs. So customer not forgotten to install my DLL before get the memdump.
I run ChkMatch
PS D:\tools> .\ChkMatch.exe -c "D:\Work\path_to_dll\RTPLogic.dll" "C:\Progra
mData\dbg\sym\RTPLogic.pdb\9F82CDF359044635ADEBA578CA1D1D031\RTPLogic.pdb"
.....
Result: Matched
How it possible that I got wrong debug symbols in such situation?
The symbols for RTPLogic.dll!CSRTPStack::Finalize are correct, but other symbols that are required to reconstruct the call stack are incorrect. It's likely that you have some operating system methods on the call stack and the symbols for ntdll or similar are missing.
Since with ChkMatch, you're only checking one single PDB file, the result of ChkMatch is as reliable and correct (for one PDB) as that of WinDbg (for many PDBs) and they do not contradict each other.
Your sympath probably contains only a local path to your own DLLs and does not contain any information about Microsoft's symbol server. In the output of .sympath (which you did not post), I expect to see something like
0:000> .sympath
D:\Work\path_to_dll
You should include Microsoft symbols as well, as described in How to set up symbols in WinDbg. To fix the problem, use the following commands:
.symfix+ c:\symbols
.reload /f
The output of .sympath should now look like
0:000> .sympath
D:\Work\path_to_dll;SRV*c:\symbols*http://msdl.microsoft.com/download/symbols
This should help WinDbg in reconstructing the complete call stack, resolve OS methods of ntdll and others and thus get rid of the "wrong symbols" message.