Im getting several warnings saying I have inconsistent dll linkages despite me classifying the header of my dll like so:
#ifdef MY_ENGINE_EXPORTS
#define ENGINE __declspec(dllexport)
#else
#define ENGINE __declspec(dllimport)
#endif
It works fine to get rid of the errors when I add MY_ENGINE_EXPORTS to the preprocessor definitions but I was under the impression that this should be done automatically on build/export. Am I wording it wrong? I included an underscore because the project is 2 words e.g "my engine". I've tried it as both MY_ENGINE_EXPORTS and MYENGINE_EXPORTS but neither seems to work.
As I say I can just add it to preprocessor definitions but it's bugging me why it doesn't behave as it should.
I figured it was a predefined macro that the environment created for dll projects
Yes, that does happen when you use the Win32 Project template to get the DLL project started. The wizard will automatically add the PROJECTNAME_EXPORTS preprocessor definition for you.
The wrinkle is that it cannot use a space in the symbol so it cannot use "MY PROJECT_EXPORTS". It will drop the space and make it MYPROJECT_EXPORTS. Which doesn't match with the one you used, MY_PROJECT_EXPORTS. Nothing a quick Edit + Replace can't fix of course.
Related
I'm working on a CMake-based project that contains both C++ and CUDA source files, and has some headers meant to be included by both languages.
For these header files, I'd like to see the result of highlighting and syntax checking as close as possible to what NVCC, the CUDA compiler, would see, so for example, I'd like to have the preprocessor symbol __CUDACC__ be defined.
It's important to me that CMake does not have such a symbol defined, because it's really an internal symbol of the NVCC toolchain that I need for syntax-checking purposes.
I've tried "Tools->C++->Additional preprocessor directives" and it seems to have no effect. I've also tried a file named CMakeLists.txt.config which seems to have no effect either.
I'd love a suggestion for this.
To reiterate, I'm looking for a way to set a define (CPP symbol) visible to to the syntax-checking system only.
After further digging I found an attribute specific to the Clang analyzer that is defined during the analysis performed for syntax checking but not during compilation.
Note that this is purely because my project compiles with GCC, while QT Creator's syntax checking runs through Clang.
// GCC and NVCC don't have __has_feature(), so we provide a fallback
#ifndef __has_feature
# define __has_feature(x) 0
#endif
#if __has_feature(attribute_analyzer_noreturn)
# define IN_CLANG_ANALYZER 1
#else
# define IN_CLANG_ANALYZER 0
#endif
This allows a clumsy hack as follows, which may or may not be useful, depending on one's needs. Pretty much the idea is that much like you'd
have Clang observe your code even if you compile with GCC, this achieves
something similar for files inteded to be used with NVCC.
#if IN_CLANG_ANALYZER and !defined(__CUDACC__)
# define __CUDACC__
# include <cuda_device_runtime_api.h>
# include <optix_device.h>
#endif
However the substantial problem remains that when compiling with Clang, all the above falls flat on its face, because clang++, the compiler, also defines the same feature as enabled.
What's needed to fix this is some kind of macro defined in the analyzer but not in Clang, and so far I've found none like this.
At first I had hoped __clang_analyzer__ would fit this need,
but according to my version of Qt Creator (6.0.2) the macro is not defined
during syntax checking, so we're back to square one.
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 have a Config.h file which includes various preprocessor conditionals based on the environment. The project has 2 targets. Via the preprocessor arguments, if the environment is the first target we may have BASE_URL = #"https://firsttarget.com/", whereas if the environment is the second target we may have BASE_URL = #"https://secondtarget.com/".
For legal purposes, if someone were to recompile the assembly, and go hunting to strings etc... we cannot have somebody finding the string #"https://firsttarget.com/" if they were looking into the binary for the second target app.
So my question is... are strings behind preprocessor conditionals removed during Archive if they are not relevant?
Sections in code between #ifdef and #endif (or #else) are not seen by the compiler unless the symbol given on the ifdef line is defined. You can easily show this by writing something that won't compile in such a section. And since the compiler doesn't see that code there is no way the value of that define can end up in the binary.
To see exactly what the compiler will work with you can select an implementation file in Xcode and chose "Product > Perform Action > Preprocess" from the menu. This will show you exactly what the compiler will work with. Of course there will also be the content from all the system .h files that are imported, so your code most likely is at the very end. Your #define lines will be stripped too, so to really check which strings will be used you need to chose a file that actually uses those macros.
And finally you can do the same thing an attacker might do - use the strings utility on the compiled binary and see what's in there. In Xcode build your app and select the "Show in Finder" option for your app bundle from the products group. There select "Show package contents" to open app your actual app bundle. The actual binary is in there with the same name as your bundle but no file extension. Then open a terminal window, type "strings " (that is the word strings followed by a space) and drag the binary on top of this. Then confirm with return. You will get a long list of every readable string from the binary (including every selector).
I know there are a lot of questions on this topic, and I've looked through a fair number of them. However I am still having problems.
I started writing a test program for a prototype PCB, and now that it's grown to nearly 1000 lines I'm trying to break it up into libraries that I can use for particular functions.
I thought this would be very simple. Make .c and .h files for each library that I need. I.e. I would have OLED.h and OLED.c for functions that control an OLED display. Copy the appropriate functions/definitions into each file. Then copy these files into the solution in Atmel Studio. I put them into the src folder under the project name.
However, this doesn't work! I get an exceedingly long list of errors. All of the things that are defined in the .h file are apparently undefined as far as the compiler is concerned. I also get many error messages of the type "unknown type name int16_t/uint16_t/uint8_t/etc..." That part is really baffling to me. Why should it matter that functions are in an external library, now the compiler doesn't understand what those data types mean?
So, this is probably a stupid problem to have. I don't want Atmel Studio to control my libraries by wrapping them up in some "library project" or somethig, I want to put them in a folder of my choosing and add them when I need them. I've searched for answers to this problem and I find long tutorials about changing the compiler settings for the project, the linker settings, etc... I tried this tutorial and still no dice: http://www.engblaze.com/tutorial-using-avr-studio-5-with-arduino-projects/#setup
I also can't find a way to add something by right clicking the project and clicking "Add." It wants me to find .a files. The "Add Library" dialog box in Atmel Studio is awful, it seems.
Surely it can't be that convoluted to just add a library to an existing project and have it function normally?! I've used PICs in the past and coming to Atmel I've found horrible documentation and a weird super-slick super-fly whizz bang interface that can't leave well enough alone and obfuscates simple function. What can I do to add these libraries?
UPDATE: Seemed to answer my own question. Turns out I needed to include all of the libraries to recognize data types and whatnot into the .c file. I somehow assumed this only had to be done in the main file but obviously I was mistaken. Adding asf.h seems to work well as it includes all of the MCU specific port definitions/names and all of that. All good for now!
Adding library files to a solution should be simple. Go to the Solution Explorer, right-click on your solution, and go to "Add->Existing Item". If you want to add a pre-existing library and keep it in a separate folder from your solution, click the arrow next to "Add" and choose "Add as link". That saves many headaches due to having a duplicate copy of your library in your solution folder, and files not staying up-to-date.
You are right in saying that you need to include the necessary header files in the .c files where they are used.
The compiler compiles each C file separately, and then links them together at the end, so you got the error unknown typename int_* because the compiler had not seen the relevant header in the context of compiling that C file.
You also seem to be in some confusion as to the difference between definition and declaration.
A function is:
Declared in the header file. This means there is a function prototype, e.g. int some_func(char some_var); which tells the compiler that the function exists, but does not tell it what it is. This is necessary because the compiler only looks at one C file at a time, so needs to be told that other functions exist.
Defined in the C file.This is the actual function body, i.e. int some_func(char some_var) { do_stuff(some_var); }. After compilation of each individual C file in isolation, the linker is called to put all the pieces together and give you your final binary, which you flash to the device.
A function can be (and must be) defined only once, but may be declared many times - even in the same file, so long as the declarations are not conflicting.
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)