I've downloaded a toolkit (namely IRTK from Imperial college) and I have compiled and installed it using CMake.
As part of the installation it has copied all of the relevant header files into /usr/local/include
I want to use classes from this toolkit so I include a relevant header file from /usr/local/include, for example irtkFileVTKToImage.h, however this class inherits from a superclass, irtkFileToImage and the include of the superclass occurs in irtkFileVTKToImage.cc not in irtkFileVTKToImage.h.
This means when I try to include the class I get a compilation error
error: unknown class name 'irtkFileToImage'
What should I do to be able to use these header files. I didn't write the tool kit so going through and adding all of the includes to the header files could take me a long time, is there some easier way to do this?
------ UPDATE ------
As a work around I've included the entirety of the toolkits source in my project and now my code compiles fine. Not ideal but at least it works
My guess is that you should compile and use the toolkit as a library, this way you will only have to include the headers of the final classes you want to use in your own code. It would be easier than trying to just use bits of it, knowing that there's a lot of dependancies.
Related
This question already has answers here:
AFNetworking.h file not found
(5 answers)
Closed 1 year ago.
#import <AFNetworking/AFNetworking.h>
I imported AFNetworking.h file to .m file but an error occurred like this:
'AFNetworking/AFNetworking.h' file not found
I deleted pods folder and Podfile.lock, and reinstalled Podfile but didn't solved. What should I do? (I opened the workspace file.)
Linking !== Copying.
there is C style #include ... and Objective-C style #import ...
both work almost the same..
where #import reads the header but does not include again if done once. As this can and does fail sometime (usually because mixing C,C++,Objc,Objc++ in different dialects) we often use #define rules to make sure the enclosed code is read once for sure and not again, which in turn works also when code is included and declared with #include. It would be included but not compiled twice.
#ifndef SOME_HumanReadableFlag_h
#define SOME_HumanReadableFlag_h
// ... your header code here..
#interface XyzObject : FromInheritedClass
#end
#endif
Now why does it matter?
It might happen that a #define rule enclosing the header files content hides the header from the viewpoint of other classes.. This can & does happen often when classes are not properly written with the end developers structure in mind. It might work on the workbench of the developer but not for everyone else implementing it.
Your error clearly tells "File not found .."
So first see what both import/include rules differentiate in general
#import <LibFrameworkName/LibFrameworkName.h>
means you have to link the framework or library, even if you developed one on your own in that project. The rule is relative to your project, LibFrameworkName is a Framework/Lib. Where if found somewhere #include <LibFrameworkName/LibFrameworkName.h> is not correct unless you want to c-style include this framework header into your binarys header, 2) tells you a bit about why..
#import "LibFrameworkName/LibFrameworkName.h"
means you have to copy/offer this header into your project with a subfolder with name LibFrameworkName. Once somewhere declared properly Xcode might find and apply the headers even if declared with the wrong rule later on in that specific class, you should also get a warning in the IDE then. In case of AFNetworking you dont want to copy System SDK Frameworks into your project, also not into third party frameworks unless you know what you do. This rule is relative to the files place in project structure, meaning here it would try to look out for some folder with name LibFrameworkName below the file that carries this rule.
what it says: because the Framework is not linked, the compiler tries to find it with the given name ignoring < & > so as if it where like 2) a file with that folder name, then will not find it and throws the error or warning.
To force the precompiler to parse thru some specific folders we use sometime the header search path to explicit tell where to find it. Widely used and mostly troublesome because it also hides wrongly defined rules to the developer as Xcode skips the still existing wrong import rules in code assuming it knows this headers already. Or it throws warnings while everything is actually fine. Other developers experience trouble then, the file structure and header list don't match at all. So keep in mind, when you can avoid making use of header search path lists, go for it. It also will and should not fix your issue.
'<AFNetworking/AFNetworking.h>' File not found means a Framework module is not known to your project. This header is part of a Framework.
Solution: You have to go to your Projects Settings and scroll down to Frameworks and Libraries, hit [+] below this list. It should open the dialog presenting all SDK from your choosen Project Target and all known Pods or known frameworks of your own project when you developed some. Search for the Framework or Lib by name, click it, hit "Add".. done..
From there - there are some options to get used to it..
Because Linking does not mean Copying into your Resources at compile time by default. Usually Xcode knows it does not have to copy System SDK into a projects Framework Folder, all macUsers have those Frameworks preinstalled on their system of course in the right version.. Linking against some specific folder like ${SOMEFLAGWHEREEVERTHISPOINTSTO}/AFNetworking/AFNetworking.framework/Headers is actually wrong unless someone wanted to overrule the systems framework header and maybe also binary.
So AFNetworking should not appear under Build Phases > Copy Bundle Ressources list but after the process above is done it will appear under Link Binary with Libraries, it might also be placed in Dependencies when Xcode needs to know for some Library/Framework it must have this to compile. Last mentioned option is because you could have a framework that adapts at runtime when some framework is missing or not available. So this Entry helps Xcode to figure out in which sorting it has to compile your stuff.
finding ${PODS_CONFIGURATION_BUILD_DIR}/AFNetworking/AFNetworking.framework/Headers in Header Search Paths there must be something wrong i guess.. because the framework is very likely not copied into the Pods folder. It should be relative to your SDKs folder that come with Xcode. The Linking process told above should fix that and you can erase that entry from your header search path then.
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'm trying to use YGuard to obfuscate some parts of my program which contain encryption methods and other sensitive information (which I'll further protect in other ways once I figure this out).
Because the program is quite complex and contains quite many libraries it obviously gives a series of warning and finally fails with:
WARNING: Method initialize_ffi_type is native but com/sun/jna/Native is not kept/exposed.
WARNING: Method getAPIChecksum is native but com/sun/jna/Native is not kept/exposed.
[...]
yGuard was unable to resolve a class (java.lang.ClassNotFoundException: com.sun.tools.javac.parser.Parser$Factory)
Now whatever that means I'd like to
exclude libraries which being all open source have nothing to hide so far
obfuscate just the methods and variables of some Class or some package and leave the rest untouched.
So far in YGuard it seems I have to specify what I don't want to be obfuscated, however I have far too many classes, I'd like instead to do the opposite: Specify what I'd like to obfuscate and proceed increasing the number of Classes and packages I want obfuscated.
Thanks
It is the normal practice for obfuscators to specify what should be kept and not the other way around.
However, you can define library classpaths with the externalclasses rule (link). Classes that are defined in this path are neither obfuscated nor shrinked. The second error you are getting (ClassNotFoundException) indicates that you have not specified all libraries that your project depends on.
In order to obfuscate your code now, what you could do is:
Pack the code that you want to be obfuscated in one jar and define everything else as a library
use a patternset in your keep rule (link) to define everything to be kept except the classes that you want to have obfuscated.
Let's say I'm trying to use one and only one 3rd-party library in an xcode project - a pretty typical scenario, seemingly harmless.
I plug in the path location of my include files to the project's "header file search path" setting. I haven't even modified any code to make use of the code in the library yet.
It turns out that the project couldn't compile.
Xcode complained something like "Cannot find interface declaration for NSObject", which is pretty absurd. By examining the Build Result, the complained error comes from a header file of the 3rd-party library - it looks something like
So it is indicated in the Build Result that xcode is mistaken that Foundation.h is referring to the assert.h of that 3rd-party library instead of the iOS' built-in assert.h (4th sub-item)
Is there a way to fix the collision of the file names of #import include files?
(Needless to say, I'm new to obj-c -___-)
I would like to know, which code is compiled when i build the project in Objective-C - every single line of code in my project, or only those, that are called from the main.c and then from the ones that are called from them?
I mean, does the compiler separate the project to the simply connected domains and compiles the one that is linked to the main, or it just compiles it all?
Thank you, guys!
The compiler does not perform semantical analysis on your code. It compiles exactly what you tell it to compile -- Xcode generally invokes the compiler in a way that it compiles every file into your application. However, it's unnecessary to compile/link the files from which no classes/functions are used; although not compiling files from which you use classes/functions results in a linkage error (that is, the compiler won't be able to find some symbols in the binary file while putting together the object code for the final executable).
All files in your project get compiled, except for the header files that are not included from any of the .m files, or headers the inclusion of which is suppressed conditionally.
A Xcode project consists of one or more targets.
For each target you can define, what *.m-files get compiled
if you add a new file to the project, you can specify to what target it will be added. (actually this is a place, where I often see, that the main target is not selected — beware)