Recompiling a C++ iPhone app with Xcode 4 I get this nasty linker error:
ld: bad codegen, pointer diff in __static_initialization_and_destruction_0(int, int)
to global weak symbol vmml::Vector2<float>::ZERO for architecture armv6
Anyone know what it means? How to make it go away would be nice too of course :)
The app compiled & linked without error in Xcode 3.
Edit: the solution is to set Symbols Hidden By Default to Yes in all the build settings of all targets in the project. Still none the wiser what the actual problem was.
The solution is to set Symbols Hidden By Default to Yes in all the build settings of all targets in the project. Still none the wiser what the actual problem was.
I had the same problem and also ended up adjusting the visibility settings. However, I was nervous just fiddling with symbol visibility and not understanding the problem, so I did a little more investigation.
If, like me, you're using Pete Goodliffe's script/package to build boost as a framework, the script sets default visibility to hidden (== yes). The visibility options change how symbols are marked by the compiler (default, hidden, internal). That information is used by the linker when making shared object elfs (shared libraries). It shouldn't apply here, so I suspect that this is a linker bug. Inside the boost library you have a weak symbol marked as hidden, and then in your project/another library, the same symbol marked as default. The linker is confused?
As for XCode 3 vs. 4, perhaps the default in 3 was to hide symbols?
In any case, changing default visibility to hidden should really have no effect with only static libs involved, so I feel a lot safer taking this route.
I've posted a few more details in a blog entry for those interested.
I ran into this problem while trying to include the boost libraries one of my projects. After finding this post, setting Symbols Hidden By Default to Yes also solved this issue for me. And I also had to make the same setting in each of the dependent projects to completely get rid of the error.
Just FYI - This only happened on my targets that were using the clang++ stack. GCC and LLVM+GCC targets do not seem to be affected.
Basically any symbols in a library you link to & your own code, need to use the same visibility level, i.e. if all the symbols in a library you include are hidden you need make sure the include files referencing the symbols in your project don't try and set it to visible. the safest way to do this is to have a constant level of default visibility across your project, for me it only became a problem with optimisations on.
Perhaps you are using a library that has hidden symbol information. If a symbol has not been exported from your library, and you attempt to use it externally, it results in a similar linker error. The correct solution would seem to be to find a way to make that symbol "visible" to the outside world via GCC macro definitions and/or modify the library itself to make sure that that particular symbol is truly "hidden" from the outside world --i.e. it isn't something that is ever used or exposed in a header file.
However, proceed with caution: according to Apple documentation, you should not hide some symbol information for a number of reasons; this one listed below seems to be the most alarming of the bunch:
If your symbol uses runtime type identification (RTTI) information, exceptions, or dynamic casts for an object that is defined in another library, your symbol must be visible if it expects to handle requests initiated by the other library. For example, if you define a catch handler for a type in the C++ standard library, and you want to catch exceptions of that type thrown by the C++ standard library, you must make sure that your typeinfo object is visible.
Source: http://developer.apple.com/library/mac/#documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html
Thus, if you want to catch an exception from the library you're linking against, hiding symbol information appears to be a bad choice. The correct solution would be to unhide the symbols of whatever library you're linking to. This can either be done by omitting the following GCC compiler flags:
-fvisibility=hidden --fvisibility-inlines-hidden
(the default visibility should be sufficient), or there are also compiler pragmas that allow you to do this. See: http://gcc.gnu.org/wiki/Visibility
Related
I'm pretty new to c++ (and programming in general) and I'm currently trying to inlcude the "SDL.h" header into a c++ project in Eclipse (I use minGW btw). I've provided the project with the paths to the the header files and the library of SDL. However, whenver I specifically include "SDL.h" and the build then project I get the following Message:
" 'Launching SDL Basic.exe' has encountered a problem. Program file does not exist. "
I'm pretty sure that this has to do with the fact that no .exe file is generated whenever I build the project with SDL.h included. What I don't get is why this happens. When I include some other SDL header, such as SDL_assert, this is not a problem. Then the .exe file is generated just as usual and the program runs just as it should.[enter image description here][1]
http://i.stack.imgur.com/cdV8U.jpg How it looks when SDL.h is included.
http://i.stack.imgur.com/MW7PX.jpg How it looks when something else from SDL is included.
I seem to have fixed the problem. Whenever I ran the program the console window outout " undefined reference to 'Winmain#16' ". So I googled on it and found out that SDL defines its own main function in SDL_main.h, which in total would give me two main functions. To prevent SDL from defining its own main function I had to define the macro SDL_MAIN_HANDLED before I included SDL.h, and look, it worked:
http://i.stack.imgur.com/mNOOE.jpg
If someone can explain this in more detail I'd really appreciate it.
I did a little research and it looks like the undefined reference to WinMain#16 is because SDL is automatically creating a Windows entry point for your application, but you haven't provided the necessary libraries to link in the SDL implementation of that entry point. However, if you intend to use the SDL functionality, you really do need that entry point, because it performs several important initialization steps necessary to leverage the SDL features that you presumably want to use.
Defining SDL_MAIN_HANDLED is a mechanism that would allow you to provide your own Windows entry point (i.e.: WinMain), but that is a more complicated approach (albeit more flexible). This only solves your problem because it happens to prevent "main" from being redefined to "SDL_main" which in turn means that your .cpp file no longer even requires any of the SDL libraries. So it compiles and links, but you won't have any of the SDL functionality you're looking for.
You need to link in the appropriate libraries. See here - it provides some info that might help.
In C, C++ and Objective-C you can compile part of an executable into its own "object file" and use it (and/or a library containing multiple object files) from any other code by including a "header file". Highly-templatized C++ code notwithstanding, a "header" typically contains just the declarations needed to validate the correctness of calling code (and assist the IDE with autocomplete, etc.).
But Swift does not have header files.
Now, apparently it is not currently possible to make a Swift static library, but in the future how would a situation like the above work, wanting to use some existing precompiled code from "new" source code, given that Swift does not have headers?
Would it work something like how [I infer] Java must work, where the compiled form can be introspected enough for the compiler to verify it is being used properly? Does Bitcode in addition to its intermediate representation also provide the necessary "protocol" for retaining such metadata?
If Apple were to port Cocoa to Swift (and keep it closed source), how would it then be "imported" into Swift apps?
Although, really, this question is not anything to do with "closed source" per se but rather trying to understand the boundaries around compilation units in Swift. Based on a similar question for the Go language, mine here could be re-phrased as: can you link to a pre-compiled Swift library without the source?
Well, just consider Apple's Swift libraries. They are closed-source, and you can use them fine and you can see pseudo-"headers" for the stuff in the library in the compiler. The exact mechanism of how this works is not currently publicly documented, but it must exist.
In addition to #user102008, the good new is, Swift will be open sourced by the end of this year, and even ported to Linux by Apple. While we can't guarantee it will always work that way (as Apple has poor records on those kind of issues), people will found suitable solutions within this even if Apple has no interests in doing so.
Even more, afaik, Swift objects were actually Objective-C objects. There'll not be that different to make Swift things work than Objective-C. (More details: http://www.eswick.com/2014/06/inside-swift/) After they were compiled, just do a class dump (or load it into a debugger such as IDA) and you can easily create a .h to make it work like normal static library or a framework.
I have an Iphone app that used the excellent ABContactHelper library origionally written for by Erica Sedun and released on github
Now with the release of XCode4 and Reference Counting support, it causes lots of errors. I have looked at the forks on github, but none seem to have updated to XCode 4 with Reference Counting. I am trying to update it myself but its slow and error prone. I have tried the automatic refactoring support, but to no avail.
Does anyone know of an alternative AddressBook wrapper that provides a simple interface for interacting with the IPhone AddressBook?
In your ARC-enabled project, you can selectively disable ARC for the AddressBook wrapper files by setting the -fno-objc-arc compiler flag for those files.
Add compiler flags in Targets -> Build Phases -> Compile Sources. Enter the compiler flag by double-clicking on the right column of the row under Compiler Flags.
Dealing with ARC/non-ARC issues is a pain in the butt, and I've found that letting CocoaPods handle these problems for me is the way to go. Simply list ABContactHelper as a pod dependency and you're done. Many of the most popular libraries are already there, but if yours isn't, it's really easy to add it.
http://cocoapods.org
Within several projects, I am using 3rd party code that produce more than a few compiler warnings. I obviously do not want to go through and modify code of actively updated 3rd party projects.
This leaves me with a lot of unnecessary warnings that drown out warnings in MY code.
I have used some compiler flags to suppress specific warnings on a per file basis, but that is much too tedious for open source code with 10-20 .m files.
Is there a way all warnings by Xcode group or file path? Or does somebody have a better suggestion?
(FYI: I am using the LLVM 1.5 compiler)
In my experience, XCode 3.x seems to only show the warnings for files that have actually been compiled in the most recent build, so if you build the project, modify a single file and then build the project again, you'll only see the warnings for the modified file. I generally find this to do more harm than good (especially since in Objective-C it's only a warning to call a selector that doesn't exist!) — and thankfully it's fixed in XCode 4 — but in your case in might be useful.
However, for various reasons you might want to consider putting the third-party code into a Framework. This wouldn't automatically suppress the warnings (although it might make it easier to suppress them) but it would mean that the third-party code was compiled into a library and therefore wasn't part of your normal compile cycle.
Turning off warnings on a per file basis is super simple. All that is required is a compiler flag. Here’s the step by step process.
Open the Project Navigator in Xcode
Click on the Project icon at the very top of the navigator
In the resulting detail pane select the target that you are working
with
Select “Build Phases”
Expand “Compile Sources”
In the list locate the file that you’re interested in
Double click the column under the “Compiler Flags” column next to
your file
Add a -w to the resulting dialog
Click “Done”
Build your now warnings free project
here is the reference link
http://blog.bluelightninglabs.com/2011/12/suppressing-xcode-warnings-on-a-per-file-basis/
This is certainly not the easier solution, but you could go through these third-party libraries and fix their warning-causing bugs and submit patches. Then, the warnings go away, the bugs are fixed, and everybody gets to enjoy both improvements.
(How many warnings you'll be able to squash this way will depend on what they are: Deprecated-API warnings may be unavoidable if the library needs to support an older version of Mac OS X or iOS where the now-deprecated APIs were the only way.)
I have a library compiled into a .a file, linked against my application. (iphone, developing with Xcode)
Everything seems to be fine, linking seems to succeed, but when I run the program it crashes. The point of crash is at a memcmp() call in the statically linked library. The debugger shows all kind of stuff called with "dyld" in their names, so it seems that for whatever reason it can not resolve memcmp, starts looking for dynamic libraries, then fails.
AFAIK memcmp is in libc, so should not be a problem. (tried also passing -lc to the linker, and it did not help, just as I expected)
So how it is supposed to work? Why can't a statically linked library use anything from libc? How should I compile it?
Thank you
libc is apparently dynamically linked on your platform. A matching version cannot be found at runtime to satisfy the dependency generated at link time.
I can't explain how this would happen other than filesystem corruption or calling chroot before the dynamic linking happens (which would seem unlikely).
Perhaps someone will find it useful if I share what the problem was:
The library was not compiled for the same OS version as the main program, so it was expecting a different libc than what it found when running.