I just seem to hit one error after another when dealing with larger projects in Xcode. This time, GCC is complaining of a duplicate definition for a struct-printing function - one where it is actually defined (in a different file), and one where it is used (in the driver).
The specific error I'm getting is this:
ld: duplicate symbol _fprintConfiguration in
/.../bits.build/Objects-normal/x86_64/Block.o and
/.../bits.build/Objects-normal/x86_64/bits.o
where Block.o contains the definition and bits.o contains the driver.
I've done some research on this already, but it seems that every problem exists with people actually defining it twice by virtue of #include, but in all my files I only use #import. Isn't the #import directive supposed to 'intelligently' include files? Are there any other reasons I could be getting this error? Are there any other solutions I can try?
Thanks for your help :)
The problem is that you're including the same definition in multiple translation units (both Block.o and bits.o). To fix this, declare the function inline or move the definition to a (single) source (non-header) file.
This is orthogonal to the question of #include vs. #import. That's about including the same code multiple times in the same translation unit.
Related
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 have a multi-platform project, running on Windows, Linux and iOS right now, but I have stumbled upon a undesirable problem with Objective-C.
I have, unfortunately, chose the name exp for one of my types (expressions, pretty reasonable given the number of occurrences in my code), but Objective-C somehow includes the math.h header by default, creating a name-clash.
I tried to comment out everything in the .pch (the prefix file included by default before every source file), and exp is still flagged as redefinition.
Does anybody know how to not include math.h in a source file inside Objective-C project?
Objective-C does not have a formal specification, but it inherits features from C. In C, programs should not use identifiers from the standard headers, even if they do not include those headers. So, you should not use “exp” for your own identifiers.
If you insist upon using “exp”, you might be able to work around the issue with a preprocessor statement:
#define exp MyExp
This will allow you to write “exp” in your source code as if it were one of your identifiers. Since the preprocessor will change it to “MyExp”, the compiler will see “MyExp” as the identifier and will not complain.
This will cause a number of problems, such as the identifier showing up as “MyExp” in object code information and in debugging tools and causing inability to use exp from math.h in the future.
We are looking for an elegant solution to this dilemma that does NOT involve manually changing code to prefix it. This seems to generally be the only way people deal with that.
For example the NSData+Base64 category might be in two separate libraries. But if these two are added to one app there must be some sort of intelligent way to choose one version.
Is there a way to make symbols in a library (.a) unique so that the linker would only take one (preferable the never version) of a class that is contained in both libraries.
I found that there is no easy way like I was looking for. You can manually hack libraries and add a prefix. You can also use compatibility aliasing, but that works only with source code.
In my IOS project i'm use multiple statics frameworks than use minizip in her code.
when i compile i have an error for a duplicate symbol.
if this error is due to a class, it's really simple (rename class, repair the error )
But in my case, the duplicate symbole provide from the "minizip" files ( like ioapi.c, zip.c unzip.c ) they are load in the frameworks.
How can it's possible to work correctly in this case ?
Thanks for your help.
This is the downside of Objective-C's single name-space.
If you can get an any of the header files, remove or rename them.
If you cannot get at them, you'll need to get the sources and rename/rebuid them, or use another library.
#Pixman: Look closely at the files you have (most recently) imported into your project.
I found a situation where two versions of the same files (i.e., ioapi.c, ioapi.h, mztools.c, mztools.h, unzip.c, unzip.h, zip.c, zip.h) were integrated into the project (at different levels) - therefore producing duplicate symbols.
These duplicated files already existed (in support of another file decompression need) so I removed the second copy of these files from the project, and the problem with duplicate symbols went away (as you would expect).
One way to see if duplicate file (and likely symbol) names exist in your project is to look at the Compiled Sources option available under the Build Phases portion of the project.
The added value with this view is that the path to each file is visible, and you can use this to figure out which (of the duplicate) files you want to remove.
I'm producing a hex file to run on an ARM processor which I want to keep below 32K. It's currently a lot larger than that and I wondered if someone might have some advice on what's the best approach to slim it down?
Here's what I've done so far
So I've run 'size' on it to determine how big the hex file is.
Then 'size' again to see how big each of the object files are that link to create the hex files. It seems the majority of the size comes from external libraries.
Then I used 'readelf' to see which functions take up the most memory.
I searched through the code to see if I could eliminate calls to those functions.
Here's where I get stuck, there's some functions which I don't call directly (e.g. _vfprintf) and I can't find what calls it so I can remove the call (as I think I don't need it).
So what are the next steps?
Response to answers:
As I can see there are functions being called which take up a lot of memory. I cannot however find what is calling it.
I want to omit those functions (if possible) but I can't find what's calling them! Could be called from any number of library functions I guess.
The linker is working as desired, I think, it only includes the relevant library files. How do you know if only the relevant functions are being included? Can you set a flag or something for that?
I'm using GCC
General list:
Make sure that you have the compiler and linker debug options disabled
Compile and link with all size options turned on (-Os in gcc)
Run strip on the executable
Generate a map file and check your function sizes. You can either get your linker to generate your map file (-M when using ld), or you can use objdump on the final executable (note that this will only work on an unstripped executable!) This won't actually fix the problem, but it will let you know of the worst offenders.
Use nm to investigate the symbols that are called from each of your object files. This should help in finding who's calling functions that you don't want called.
In the original question was a sub-question about including only relevant functions. gcc will include all functions within every object file that is used. To put that another way, if you have an object file that contains 10 functions, all 10 functions are included in your executable even if one 1 is actually called.
The standard libraries (eg. libc) will split functions into many separate object files, which are then archived. The executable is then linked against the archive.
By splitting into many object files the linker is able to include only the functions that are actually called. (this assumes that you're statically linking)
There is no reason why you can't do the same trick. Of course, you could argue that if the functions aren't called the you can probably remove them yourself.
If you're statically linking against other libraries you can run the tools listed above over them too to make sure that they're following similar rules.
Another optimization that might save you work is -ffunction-sections, -Wl,--gc-sections, assuming you're using GCC. A good toolchain will not need to be told that, though.
Explanation: GNU ld links sections, and GCC emits one section per translation unit unless you tell it otherwise. But in C++, the nodes in the dependecy graph are objects and functions.
On deeply embedded projects I always try to avoid using any standard library functions. Even simple functions like "strtol()" blow up the binary size. If possible just simply avoid those calls.
In most deeply embedded projects you don't need a versatile "printf()" or dynamic memory allocation (many controllers have 32kb or less RAM).
Instead of just using "printf()" I use a very simple custom "printf()", this function can only print numbers in hexadecimal or decimal format not more. Most data structures are preallocated at compile time.
Andrew EdgeCombe has a great list, but if you really want to scrape every last byte, sstrip is a good tool that is missing from the list and and can shave off a few more kB.
For example, when run on strip itself, it can shave off ~2kB.
From an old README (see the comments at the top of this indirect source file):
sstrip is a small utility that removes the contents at the end of an
ELF file that are not part of the program's memory image.
Most ELF executables are built with both a program header table and a
section header table. However, only the former is required in order
for the OS to load, link and execute a program. sstrip attempts to
extract the ELF header, the program header table, and its contents,
leaving everything else in the bit bucket. It can only remove parts of
the file that occur at the end, after the parts to be saved. However,
this almost always includes the section header table, and occasionally
a few random sections that are not used when running a program.
Note that due to some of the information that it removes, a sstrip'd executable is rumoured to have issues with some tools. This is discussed more in the comments of the source.
Also... for an entertaining/crazy read on how to make the smallest possible executable, this article is worth a read.
Just to double-check and document for future reference, but do you use Thumb instructions? They're 16 bit versions of the normal instructions. Sometimes you might need 2 16 bit instructions, so it won't save 50% in code space.
A decent linker should take just the functions needed. However, you might need compiler & linke settings to package functions for individual linking.
Ok so in the end I just reduced the project to it's simplest form, then slowly added files one by one until the function that I wanted to remove appeared in the 'readelf' file. Then when I had the file I commented everything out and slowly add things back in until the function popped up again. So in the end I found out what called it and removed all those calls...Now it works as desired...sweet!
Must be a better way to do it though.
To answer this specific need:
•I want to omit those functions (if possible) but I can't find what's
calling them!! Could be called from any number of library functions I
guess.
If you want to analyze your code base to see who calls what, by whom a given function is being called and things like that, there is a great tool out there called "Understand C" provided by SciTools.
https://scitools.com/
I have used it very often in the past to perform static code analysis. It can really help to determine library dependency tree. It allows to easily browse up and down the calling tree among other things.
They provide a limited time evaluation, then you must purchase a license.
You could look at something like executable compression.