I've noticed that the syscalls.c file for an STM32F407-DISC project (Made through the STM32CubeIDE) has __io_putchar() and __io_getchar() as externs.
But I can't locate any file within the project where these functions are actually defined.
This is what is present in the syscalls.c file:
extern int __io_putchar(int ch) __attribute__((weak));
extern int __io_getchar(void) __attribute__((weak));
Does anyone know what file these externs are pulling from?
Thanks in advance!
They are in the standard library. So there is no code in your project. You need to download (clone) the source code of the standard library implementation used by the STMCubeIDE toolchain.
Simply write your own ones and they will replace those with the weak linkages.
Related
I am writing a C++ (MFC in particular) class which uses an external .gif image file and produces another image file after some processing. It would be nice if the initial image could be embedded in the code somehow. I have read in MSDN about using multiple .rc files and the whole thing seems quite complicated.
I would like to know from people who have gone through this before how to handle this problem.
EDIT : Sorry I was not clear. The class I am writing should be standalone, so I could use it again. If I put the image in a resource file, then the class will not compile if used in a fresh project.
You cannot embedd MFC resources inside a class or similar C++ container. They can only be embedded in DLL or EXE files - in a separate section of the produced binary. Since you want your class to be reusable, you must put it in a DLL. Hence, you must tag your class with the AFX_EXT_CLASS keyword.
There are two solutions.
Solution #1:
Create an MFC DLL project (MFC Extension DLL). Call it MyLibrary or whatever.
Put all your standalone classes in this DLL.
Embed all necessary resources.
Let your classes load resources from the HINSTANCE of your DLL as described below.
There are several ways to retrieve the HINSTANCE of your DLL. If you ask me, the best solution is to grab it in DllMain. This is done automatically if you choose the MFC Extension DLL configuration:
static AFX_EXTENSION_MODULE MyLibDLL = { NULL, NULL }; // Make this variable global!
// Then access the hInstance as follows:
LoadResource(MyLibDLL.hModule, ...)
Solution #2:
Store your resource as a byte buffer. Or better, convert it to Base64 and store it as an ASCII string. But remember not to blow the stack! Keep your resources small or increase the stack size in your project settings. Example:
const char *encodedResource = "SGVsbG8gd29ybGQh";
char *data = decode(encodedResource);
foo(data);
In the solution explorer go to resource view, Right click and click Add Resource then click Import and add the gif file. Now you can use your Resource ID to access the gif file in your code.
Just adding the file to a resource doesn't embed the file in the actual resource file it just links to the file. If you open your .rc file you'll see it says something like:
IDB_GIF_MYIMAGE GIF "artwork\\mygif.gif"
During the compilation face the resource will be included in the EXE, which you reference using the resource id IDB_GIF_MYIMAGE. You can reference the same file in other projects without having to duplicate the file.
To embed an image (or any other type of binary data) into your class without using resource files, use the bin2c utility, for example you can download it from here: http://www.opensource.apple.com/source/libpcap/libpcap-16/libpcap/msdos/bin2c.c . Running this on a file will produce what is basically a static array with the bytes of the file as members of that array. Stuff this array into a .h file (or put it in the header of your class, or make it a static member...) and then you will have that file available in-memory without having to use LoadResource() and its brethren.
If you want to use this with CImage::Load(), you will have to write your own class that derives from IStream, and implement a few of the methods in a way so that they 'read' from memory. I don't know of any ways to let CImage decode an image from an in-memory representation of a gif file.
I think the best solution is just to document that to use the class you must also import to your project a certain .gif file and give it a certain expected identifier (e.g. IDB_MYCLASS_MYGIF). You can then use the preprocessor to detect if the resource has been correctly added, e.g.:
#ifndef IDB_MYCLASS_MYGIF
#error Make sure you import mygif.gif to the project. See docs for more info.
#endif
This will prevent the class compiling until the user imports the image properly. Alternatively you could just use #ifdefs to fall back to code which does not use the default image if it is not provided.
Have a look at the CRuntimeDialog class presented in http://www.codeproject.com/Articles/5371/ToDoList-6-5-4-Feature-Release-An-effective-and-fl . It provides a way to create a dialog from the string that makes up the resource definition.
Sorry in advance if this has been answered, I've searched repeatedly here and the in the apple docs, but haven't found out what is causing this problem. I have a iOS app that is driven by a 'layout' file that contains references to the content. I wanted to create a command line tool to optimize the content and modify the layout file if need. For example, by tiling an image and replacing it in the layout by the tiles.
I thought to create my first ever OSX tool and used the newest Xcode to create a CoreFoundation project, which gives me a main.c like this:
#include <CoreFoundation/CoreFoundation.h>
int main (int argc, const char * argv[])
{
CFShow(CFSTR("Hello, World!\n"));
return 0;
}
which builds fine. I thought to use some of the NS* classes to start working with the command line args, but as soon as I included the Foundation framework and added this line:
#include <Foundation/Foundation.h>
I started to get tons of build errors. I think I'm missing something basic, here, but I can't see it! Did I choose the wrong template? Is there a better one? Or, what's the problem with using Foundation here?
You need to set the file language to Objective C for it to compile. Either that or rename main.c in main.m
I have many constants in my application used by many classes of my project. These constants have to be set at compilation time (they are not modified later).
For now, I use #define statements at the top of each classe that requires the constant. The problem is that I have to repeat these statement in each classe which requires the constant.
I plan to define all these constants in my main.m or in another .h imported by main.m but I think it is not a good idea.
-> Is there a XCODE / IOS mechanic or file made for that purpose ?
-> If not, is it a good idea to define the constants in my main. ?
Thanks for you help
kheraud
You can write all constants in any .h file , then you can import that file in your projectname_Prefix.pch file .
then you don't need to import file in any other source file . its directly get imported .
you can save them in your *_Prefix.pch then they will apply for all classes without importing another class.
Generally the best way to handle shared constants is to declare them extern in one or more dedicated .h files, and then define them in corresponding implementation files. That way you'll be guaranteed to only have one copy of each constant in your binary, unlike with a #define.
You can provide target-wide compiler defines in Xcode by adding them to the Preprocessor Macros build setting. For example, this might let you create a free Lite version of your application by creating a target for it within your project, then adding a LITE define in the Preprocessor Macros.
See this question for more on this.
This is probably a totally noob question but I have missing links in my mind when thinking about linking libraries in iOS. I usually just add a new library that's been cross compiled and set the build and linker paths without really know what I'm doing. I'm hoping someone can help me fill in some gaps.
Let's take the OpenCV library for instance. I have this totally working btw because of a really well written tutorial( http://niw.at/articles/2009/03/14/using-opencv-on-iphone/en ), but I'm just wanting to know what is exactly going on.
What I'm thinking is happening is that when I build OpenCV for iOS is that your creating object code that gets placed in the .a files. This object code is just the implementation files( .m ) compiled. One reason you would want to do this is to make it hard to see the source code and so that you don't have to compile that source code every time.
The .h files won't be put in the library ( .a ). You include the .h in your source files and these header files communicate with the object code library ( .a ) in some way.
You also have to include the header files for your library in the Build Path and the Library itself in the Linker Path.
So, is the way I view linking libraries correct? If , not can someone correct me on this ?
Basically, you are correct.
Compiling the source code of a library produces one object file for each of the source files (in more than one, if compiled multiply times against different architectures). Then all the object files are archived (or packaged) into one .a file (or .lib on Windows). The code is not yet linked at this stage.
The .h files provide an interface for the functionality exposed by the library. They contain constants, function prototypes, possibly global declarations (e.g. extern int bad_global;), etc. -- basically, everything that is required to compile the code which is using the library.
.h files do not 'communicate' with object code in any way. They simply provide clues for the compiler. Consider this header file:
// library.h
extern int bad_global;
int public_func(int, const void*);
By including this file in your own code, you're simply telling the compiler to copy and paste these declarations into your source file. You could have written declarations for OpenCV library and not use the headers provided with it. In other words, you're asking the compiler to not issue errors about undefined symbols, saying "I have those symbols elsewhere, ok? Here are their declarations, now leave me alone!".
The header files need to be included in the search path in order for compiler to find them. You could simply include them via the full path, e.g. #include "path/to/file.h", or supply an -I option for your compiler, telling him where to look for additional headers, and use #include <file.h> instead.
When your code is compiled, the declarations in header files serve as an indication that symbols your code is using are defined somewhere. Note the difference between the words declaration and definition. Header files contain only declarations most of the time.
Now, when your code is compiled, it must be linked in order to produce the final executable. This is where the actual object code stored in the library comes into play. The linker will look at each symbol, function call, etc. in your object code and then try to find the corresponding definition for each such symbol. If it doesn't find one in the object code of your program, it will look the standard library and any other library you've provided it with.
Thus, it is important to understand that compilation and linkage are two separate stages. You could write any function prototypes at all and use them in your code, it will compile cleanly. However, when it comes to the linking stage, you have to provide implementation for symbols used in your code, or you won't get your executable.
Hope that makes sense!
The .a is the compiled version of the code.
The header files provided with a library are its public interface. They show what classes, methods, properties are available. They do not "communicate" with the binary code.
The compiler needs the headers to know that a symbol (a method name for example) is defined somewhere else. They are associated with the right "piece of code" in the library binary later during the "link" step.
I have some code written in C++ which I would like to use in my iPhone app. I added the source files to the XCode project, but I have problem with some parts of the source code, e.g. I have he following code:
#import <vector>
// (...) some other code
typedef std::vector<keypoint> keypointslist;
// (...) rest of the code
In the line with the typedef I'm getting:
Expected '=', ',', ';', 'asm' or 'attribute' before ':' token in
Exactly the same code was compiled with gcc on Linux machine, so I wonder why XCode has problem with it.
Any suggestions?
Are you sure, you told XCode to compile the file as C++ and not as C or Objective-C? Maybe you must use the file extension ".cpp".
It's called #include, not #import:
#include <vector>
+1 with Ludger,
youre adding that to an objective c app, you'll need to add a .cp/.mm/.cpp translation unit to the project to get that to compile - right click on project classes select add class make sure you add one from the cpp section.
If you include C++ code in a ".m" file you must rename the extension to ".mm" or ".M". this applies even if you reference a C++ class from an objective C one, the file must be renamed. Sometimes this renaming has a domino effect and so you end up with a lot of ".mm" files in your project.
Make sure you included <vector> header file before typedef. It looks like the compiler doesn't know std namespace.
You have to rename the ALL files that use the C++ code with .mm extension.
That includes your view controller files that could be importing the C++ class. eg. MyViewController.mm