Is it possible to disable xcode from checking for apple mach-o linker errors?
What you can do is to make sure you are adding all the necessary frameworks and importing them where ever necessary, And also, check under the compile sources under the build phases that your class files are included there, and Mach-o-linker's would never come in your way.
Related
Situation:
I am using CI to compile a Windows version of my project using CMake and MSVC
It errors out right at the end complaining of two missing symbols (__std_system_error_allocate_message and __std_system_error_deallocate_message)
When I replicate the build process on my own computer, the build finishes fine and the artifacts run without errors.
Searching for these symbols on Google yields no clues as to which libraries they are supposed to be defined in.
Which leads to my question:
Is it possible to see where the MSVC linker is finding a particular symbol?
I was able to find instructions to look at what symbols are defined in a particular library, but this project is linking dozens of libraries, and the ones I have searched so far do not define the symbol. I think this approach is prone to errors as I might miss a library without knowing it.
#Richard Critten pointed me on the right path, the problem was due to having different versions of the MSVC toolchain on each system. GitLab's CI runners were using build tools version 16.2.3.0 while I was using a more recent 16.6.1.0. Uninstalling that and installing 16.2.3 from this page reproduced the error. Recompiling a dependency I had previously compiled with the newer toolchain then resolved the error on both systems.
There is a project that has a prebuilt dependencies (a bunch of static libs), all these libraries have debug info sections generated in default toolchain format - DWARF-4. I'm trying to compile my sources with -gdwarf-5, but linker fails to link final loadable binary:
ld.lld: error: linking module flags 'Dwarf Version': IDs have conflicting values ('i32 4' from foo/bar/baz.cc with 'i32 5' from ld-temp.o)
Is there any way to convince linker to continue even if different TU use different DWARF versions? After some googling I've found this ticket https://reviews.llvm.org/D52952, where the same issue was reported as warning, which makes me think that there might be some chances to suppress it.
P.S. All above is about LLVM toolchain from Android NDK r20 (claims to be LLVM 8), linker is lld.
P.S.S. I have no chance to recompile dependencies, that is why I'm looking for a way to allow different DWARF versions in final binary.
The NDK defaults to passing -Wl,--fatal-warnings to the linker because the most common type of linker warning is that something isn't defined, which means your app is broken. More warnings have been added to the linkers over the years, and some (and I believe this is the case here) are fairly innocuous.
Unfortunately, as far as I know there's no way to control the fatal warnings on a per-warning basis like you can with -Werror=warning-name with the compiler. If you're okay with disabling all of the fatal linker warnings, you can disable that feature with -Wl,--no-fatal-warnings (add it to your ldflags). If you're using ndk-build you can do this on a per-module basis with LOCAL_DISABLE_FATAL_LINKER_WARNINGS := true.
I've downloaded Boost Binaries from here. My project depends on boost_system and boost_filesystem, and builds correctly if I add the proper dependencies to Linker Options when using Visual Studio for compilation, but I'm now trying to compile under Code::Blocks (MinGW compiler) and running into the following:
"directve `/FAILIFMISMATCH:"_MSC_VER=1800" /FAILIFMISMATCH:"_ITERATOR_DEBUG_LEVEL=0" /FAILIFMISMATCH:"RuntimeLibrary=MD_DynamicRelease" /DEFAULTLIB:"msvcprt" /DEFAULTLIB:"uuid.lib" /DEFAULTLIB:"uuid.lib" "
Though that's a warning, it keeps me from finding the dependencies, because my project fails to build with undefined reference to 'boost::system::generic_category()' and plenty of other related undefined references.
Question: Should I compile Boost from source using MinGW, in order to solve my problem?
Of course, I'm using the proper libraries for my build configuration (Release, dynamic runtime library).
I'm making an answser based on the comments posted below my question, just to make things proper.
So, building boost from the source code using the same compiler (I used TDM-GCC with gcc 4.8.1) did solve the linking issues.
As noted by Rup, one "can't mix C++ compiled with GCC and Visual Studio: they have different C++ ABI implementations, and generate different 'manglings' of identifier names so that linker symbols won't match up."
Additional reference: Interoperability of Libraries Created by Different Compiler Brands
While using C++ in Visual Studio 2013, I've come across a really weird warning/bug thing.
I have a static library and a console application.
Static library imports 4 3rd party .lib files, and their headers.
Console application imports the static library and the headers of the original 4 .lib files, so that I can use the code from the original 4 .libs and my .lib.
(I think this is the right setup in this situation, if there is a better way, do tell!)
However, when I build the static library, I get a warning: "LNK4221: This object file does not define any previously undefined public symbols, so it will not be used by any link operation that consumes this library" for each .lib imported.
But where is it getting the code if not from the libraries? If I remove the .libs from being imported, the build fails stating that it needs them! I don't know what to do in a situation like this. I would be happy enough to just leave the .libs being imported as is and ignore the warnings, but when I try to disable them (Under disable specific warning, "4221", in the compiler options), the warnings are not disabled!
Edit: The 4 3rd party .libs are standalone - they do not use each other's code so I do need to import all of them.
I am truly at a loss - any advice would be much appreciated.
I found a way of disabling the warnings using /ignore: on the linker command line, but I'm still confused as to why the linker gave the warnings in the first place, when removing the library as input caused multiple "unresolved external symbol" errors.
Oh well, problem (sorta) solved.
Have wasted almost full 4 days trying to compile this package. It compiles fine in OSX 10.6, but gives Undefined reference errors when I try to compile it on a linux (Kubuntu 10.04, 3.8.0.27 kernel) machine.
The error seem to be that the makefiles are ordered wrong, but AFAIK, I am the only one having trouble compiling it. So I'm trying to find what's making the difference. The software package is quite big and editing the Makefiles and moving 30-50 libraries here and there doesn't seem like a good idea.
Here's the differences I think I found so far
Compiler - gcc-4.7 (Linux) and llvm-gcc-4.2 (OSX)
Compiler flags --shared (Linux) and -dynamic -dynamiclib -undefined dynamic_lookup (OSX)
Anyone have any suggestions?
I tried using clang++ and llvm-gcc-4.7 as the compiler, but I think it still used the same linker (ld?). So I could try to specify to use llvm? How do I do that?
is --shared flag somehow different from the dynamic -dynamiclib -undefined dynamic_lookup flags in OSX?
Does the linux kernel or distribution matter? (I think they compiled it fine on a CentOS machine)
Please help.
Thanks a lot.
Compiled it with gcc 4.4 and worked flawlessly. I guess the order doesn't matter on 4.4 for the given package.
The undefined references type of errors can be caused by a symbol not being compiled in, not being linked or being linked out of order. The way to debug this is to check the linker line, the symbol that the linker complains about. The error message will probably tell you what object file has the dependency.
Now, you need to find out whether the symbol is compiled or linked, for that you will need to find if it is in any of the object files or in any of the libraries and which. You can use the nm command line tool to list the symbols that are defined in any given .o or library. If the symbol is not there, then you need to figure out what to add to the linker line and that will solve it.
If the symbol appears in one library, then identify which of the libraries depends on that symbol (from the linker error message) and the library that contains it. The former must be listed before the latter in the linker command line (assuming static linking).
As a simple hack, although I recommend against it, you can instruct the gcc linker to do multiple passes by using the --start-group and --end-group command line options. Although I really recommend that you figure out the order of dependencies, as that will also give you a better insight into your project.