i tried to port the SimpleFTPsample from apple from this IOS project to my OSX project, but when I try to build I get the following error.
Undefined symbols for architecture x86_64:
"_OBJC_CLASS_$_NetworkManager", referenced from:
objc-class-ref in Document-DAE96E3625ECED63.o
ld: symbol(s) not found for architecture x86_64
clang: error: linker command failed with exit code 1 (use -v to see invocation)
I've searched online, and have been checking all the code I copied twice, all frameworks are added, and the headers included. could somebody please help me to find whats wrong, or even better explain what this means so i can solve it myself in the future? how can i find out what is wrong in the NetworkManager class? i dont get any errors before compiling.
thanks
---EDIT---
forgot to mention that i only need the PUT part of the code in the example, i am only examinating that part. all the rest hasnt been copied over. i copied the NetworkManager.h, NetworkManager.m and copied over the parts of the code that i need from the PUT file.
Usually, when the linker says “what? I've never heard of that class”, it means that the module that implements that class (SomeClass.m) didn't get compiled.
There are two ways that that happens:
Compilation failed
This one would cause an error asking for SomeClass.o (in your case, NetworkManager.o). That's not the error you got, but similar enough that I felt it was worth listing here.
The linker will want an object file, which is produced by a successful compilation. If compilation fails, the object file doesn't exist, so you'll get the “file not found: blah/blah/blah/SomeClass.o” error.
999‰ of compilation failures are because the module contains an error—a syntax error, an unrecognized name (e.g., spelling error/typo), or some other flaw that fails compilation.
Build errors causing other build errors is fairly common, so you should always tackle errors from the top of the list downward.
The solution to this one is to navigate to SomeClass.m and fix everything that's wrong with it, and then try the build again.
You didn't even try to compile it
This is the one you ran into.
Every target has a list of build phases, each describing something that needs to be done to build the target. Most targets have at least Compile Sources and Link Binary with Libraries phases. Every build phase has a list of input files.
The input files for a Compile Sources phase are the module files that Xcode will try to compile. Link Binary with Libraries will implicitly link in everything that the compiler produced—all of the object files—along with the libraries in its list, such as Cocoa.framework.
For each target, Xcode will only try to compile modules that are in that target's Compile Sources build phase.
It's quite possible to forget to add a module to a target but still try to use it in another module within the same target. Maybe you made the module a long time ago for another target, and now want to use that code in the target you're working on now, or maybe you simply forgot to check the box when you created the module or otherwise added it to the project.
Either way, you'll get that error message, telling you that the module whose contents you're trying to use isn't listed for compilation in the target you're trying to use it in.
There are two ways to fix it:
Select or navigate to the “missing” module and show the File Inspector (⌘⌥1), and check the box for the appropriate target under “Target Membership”.
Select the project object in the Project Navigator, select the target within the editor, switch to the Build Phases tab, and drag the “missing” module from the Project Navigator into the Compile Sources build phase.
The way to prevent it is to make sure the relevant targets are checked when you add the module to the project. This includes both creating new modules and adding modules you've obtained from other people (e.g., open source reusable classes).
Related
This is very frustrating, I am trying to add the Parse framework but every time I do, my app crashes (even with no code added). I get the following error:
dyld: Library not loaded: #executable_path/../Frameworks/ParseOSX.framework/ParseOSX
Referenced from: /Users/me/Library/Developer/Xcode/DerivedData/Popup-beyvddmmqfabhhghmlsnrvkissfw/Build/Products/Debug/Popup.app/Contents/MacOS/Popup
Reason: image not found
Sounds like it's having problems finding the framework? There have been other people with this problem but I can find no solution short of creating a new project. I'd rather just find another solution before doing that...
You need to add the frameworks to a new copy files build task. Make sure that they end up in the build products folder, and the "copy only on install" checkbox is NOT checked.
I'm having trouble understanding if/how to share code among several Fortran projects without building libraries or duplicating source code.
I am using Eclipse/Photran with the Intel compiler (ifort) on a linux system, but I believe I'm having a bigger conceptual problem with modules than with the specific tools.
Here's a simple example: In ~/workspace/cow I have a source directory (src) containing cow.f90 (the PROGRAM) and two modules m_graze and m_moo in m_graze.f90 and m_moo.f90, respectively. This project builds and links properly to create the executable 'cow'. The executable and modules (m_graze.mod and m_moo.mod) are stored in ~/workspace/cow/Debug and object files are stored under ~/workspace/cow/Debug/src
Later, I create ~/workplace/sheep and have src/sheep.f90 as the program and src/m_baa.f90 as the module m_baa. I want to 'use m_graze, only: ruminate' in sheep.f90 to get access to the ruminate() subroutine. I could just copy m_graze.f90 but that could lead to code getting out of sync and doesn't take into account any dependencies m_graze might have. For these reasons, I'd rather leave m_graze in the cow project and compile and link sheep.f90 against it.
If I try to compile the sheep project, I'll get an error like:
error #7002: Error in opening the compiled module file. Check INCLUDE paths. [M_GRAZE]
Under Properties:Project References for sheep, I can select the cow project. Under Properties:Fortran Build:Settings:Intel Compiler:Preprocessor I can add ~/workspace/cow/Debug (location of the module files) to the list of include directories so the compiler now finds the cow modules and compiles sheep.f90. However the linker dies with something like:
Building target: sheep
Invoking: Intel(R) Fortran Linker
ifort -L/home/me/workspace/cow/Debug -o "sheep" ./src/sheep.o
./src/sheep.o: In function `sheep':
/home/me/workspace/sheep/src/sheep.f90:11: undefined reference to `m_graze_mp_ruminate_'
This would normally be solved by adding libraries and library paths to the linker settings except there are no appropriate libraries to link to (this is Fortran, not C.)
The cow project was perfectly capable of compiling and linking together cow.f90, m_graze.f90 and m_moo.f90 into an executable. Yet while the sheep project can compile sheep.f90 and m_baa.f90 and can find the module m_graze.mod, it can't seem to find the symbols for m_graze even though all the requisite information is present on the system for it to do so.
It would seem to be an easy matter of configuration to get the linker portion of ifort to find the missing pieces and put them together but I have no idea what magic words need to be entered where in the Photran UI to make this happen.
I confess an utter lack of interest and competence in C and the C build process and I'd rather avoid the diversion of creating libraries (.a or .so) unless that's the only way to make this work.
Ultimately, I'm looking for a pure Fortran solution to this problem so I can keep a single copy of the source code and don't have to manually maintain a pile of custom Makefiles.
So can this be done?
Apologies if this has already been documented somewhere; Google is only showing me simple build examples, how to create modules, and how to link with existing libraries. There don't seem to be (m)any examples of code reuse with modules that don't involve duplicating source code.
Edit
As respondents have pointed out, the .mod files are necessary but not sufficient; either object code (in the form of m_graze.o) or static or shared libraries must be specified during the linking phase. The .mod files describe the interface to the object code/library but both are necessary to build the final executable.
For an oversimplified toy problem such as this, that's sufficient to answer the question as posed.
In a larger project with more complex dependencies (in my case, 80+KLOC of F90 linking to the MKL version of LAPACK95), the IDE or toolchain may lack sufficient automatic or user-interface facilities to make sharing a single canonical set of source files a viable strategy. The choice seems to be between risking duplicate source files getting out of sync, giving up many of the benefits of an IDE (i.e. avoiding manual creation of make/CMake/SCons files), or, in all likelihood, both. While a revision control system and good code organization can help, it's clear that sharing a single canonical set of source files among projects is far from easy given the current state of Eclipse.
Some background which I suspect you already know: Typically (including ifort) compiling the source code for a Fortran module results in two outputs - a "mod" file that contains a description of the Fortran entities that the module defines that the compiler needs to find whenever it sees a USE statement for the module, and object code for the linker that implements the procedures and variable storage, etc., that the module defines.
Your first error (the one you solved) is because the compiler couldn't find the mod file.
The second error is because the linker hasn't been told about the object code that implements the stuff that was in the source file with the module. I'm not an Eclipse user by any means, but a brute force way of specifying that is just to add the object file (xxxxx/Debug/m_graze.o) as an additional linker option (Fortran Build > Settings, under Intel Fortran Linker > Command Line). (Other tool chains have explicit "additional object file" properties for their link stage - there may well be a better way of doing this for the Intel chain.)
For more involved examples you would typically create a library out of the shared code. That's not really C specific, the only Fortran aspect is that the libraries archive of object code needs to be provided alongside the mod files that the Fortran compiler generates.
Yes the object code must be provided. E.g., when you install libnetcdf-dev in Debian (apt-get install libnetcdf-dev), there is a /usr/include/netcdf.mod file that is included.
You can now use all netcdf routines in your Fortran code. E.g.,
program main
use netcdf
...
end
but you'll have link to the netcdf shared (or static) library, i.e.,
gfortran -I/usr/include/ main.f90 -lnetcdff
However, as user MSB mentioned the mod file can only be used by gfortran that comes with the distribution (apt-get install gfortran). If you want to use any other compiler (even a different version that you may have installed yourself) then you'll have to build netcdf yourself using that particular compiler.
So creating a library is not a bad solution.
I have a project where I have added a compile symbol (MYSYMBOL) in the project properties. When building from VS it works just fine and the application acts accordingly.
Other projects has various symbols defined this way.
When building from MSBUILD, MYSYBOL is for some strange reason ignored and the application acts as if it was never set.
I tried adding /p:"DefineConstants=MYSYMBOL" to the msbuild call, but then the build fails as it seems to replace the other symbols of each project with this one alone, so one assembly e.g. requires MYSYMBOL + OTHERSYMBOL but now only gets MYSYMBOL.
This is strange since it actually does use OTHERSYMBOL for those projects that have it, when building via msbuild.
Does anyone have a clue what could be causing MYSYMBOL on the project properties not to be used when building via msbuild?
Turned out that the build script has stated a set of compiler symbols on its own, overwriting the ones in the separate project settings which in turn caused this issue.
As far as I understand, you can't add one or more compiler symbols since anything you state replaced the symbols of the projects.
Ended up having to pass every symbol every project in the entire solution uses.
Too bad :(
You will want to add a new symbol to the list of DefineConstants (as opposed to overriding the entire list of DefineConstants). This will do what you want:
<PropertyGroup>
<DefineConstants>MYSYMBOL;$(DefineConstants)</DefineConstants>
</PropertyGroup>
I'm new to Objective-C but has a lot experience with Java and .NET.
I'm trying to add EGOPhotoViewer to my iOS 5 project in Xcode 4.2.1. But I get a lot of release, dealloc, retain etc. issues while compiling their code, since I'm using Automatic Reference Counting (I think!).
How can I create a class library, framework or what it is called in Objective C for their code, that I can add to my project?
EDIT:
I've done the approach from JeremyP by inserting the code with a new target. I compiled in the beginning, but after a while I get this compile error:
Undefined symbols for architecture i386:
"_OBJC_METACLASS_$_EGOPhotoViewController", referenced from:
_OBJC_METACLASS_$_PhotoViewController in PhotoViewController.o
"_OBJC_CLASS_$_EGOPhotoViewController", referenced from:
_OBJC_CLASS_$_PhotoViewController in PhotoViewController.o
ld: symbol(s) not found for architecture i386
clang: error: linker command failed with exit code 1 (use -v to see invocation)
Does anybody know why?
For your purpose, a regular static library as described by beryllium would do fine.
Just for unashamed plug purposes and for spreading the word, this document describes how to create versioned, documented frameworks using Xcode, GIT and DoxyGen.
Creating a Versioned Framework 1.23
The main purpose of creating such frameworks is to redistribute them. I personally find it extremely annoying to manually include libraries and headers I receive from third parties - especially if the libraries are delivered in separate versions for simulator and device. That guide is meant for classic middleware developers. I have written it to allow people like those folks from Google Analytics to finally provide something worth their brand.
This document gives you a step by step explanation, bundled with loads of screenshots.
Open Xcode -> File -> New -> New Project -> Framework & Library -> Next -> Type Name, Choose Folder -> Create
It will be a library called yourApp.a. You can find it in Derived Data folder
You can't create frameworks for iOS. You can however, create static libraries using beryllium's technique. You can also add a static library to your existing project using File / New / New Target... Obviously, once you create the target you can change the Objective-C automatic reference counting build setting to "no" for your new target.
I thought it was possible to turn ARC on and off at the source file level, but I can't figure out how.
I've created frameworks on multiple occasions using the following method:
http://db-in.com/blog/2011/07/universal-framework-iphone-ios-2-0/
I know this is a long shot but, I've been having trouble with a linker error that I specifically don't understand. Please refer to the picture below.
The project contains 4 targets. This error points specifically to one target that is a BSD/Shell helper tool written in c.
I'm sorry for being vague, as I don't fully understand what might be the problem. Any suggestions? Thank you.
Usually, this means that the source file that defines main() hasn’t been added to the corresponding target.
Another possible reason is that the source file that contains main() is being compiled for an architecture (e.g. i386 only) but the target/executable specifies a different architecture (e.g. x86_64 only or fat/universal).
One strategy to help with diagnosing this issue is running xcodebuild against your project+target to inspect the commands that are being issued to compile and link the target.
When all else fails, remove the target and add it again.
Did you #include the appropriate files?