I just installed gmp from https://gmplib.org/, on my MacBook, which I'm completely new to. (I'm quite new to C and mpi as well for that matter.)
Now I have a C code containing both the headers mpi.h and gmp.h. If I try to compile the code with mpicc, as I usually do when not using gmp, it complains about not finding 'gmp.h'. On the other hand, if I compile with gcc it complains about not finding 'mpi.h'. So, what should I do to be able to compile my code?
I need both the headers since I will need to work with huge numbers in a parallel environment. I.e. removing any one of them is really not an option.
I'm thankful for any help with this issue.
Related
So I have a raspberry pi zero and I followed along this really cool tutorial to have a starting point at programming it in bare metal c. Everything's been working good.
Now for what I want to do I need (unsigned) integers with a size of 256 or 512 bit, so I went looking for libraries. I found BigDigits and got it to work easily on my machine.
When I tried to compile it with the rest of my actual bare metal code though (without even including it or using it anywhere in my code) it compiled and linked without warnings or errors but my code doesn't work anymore, i.e. my raspberry pi doesn't do what it did before.
I'm still pretty new to bare-metal programming. I know that there might be system functions used by the library that are not implemented and might therefore not work correctly. But I'm not even calling any BigDigits function, nor am I including any of their headers.
So why does it compile and link but not work? And how could I make it work or are there any other options that would be easier to use in a bare-metal c environment for arbitrary precision? I actually always know at compile time what precision I need so I'd be happy to just have uint256_t types or something like that, but I couldn't find anything like that.
Thanks in advance!
Stuff like bignum libraries can be written in assembly or be included in C as external/linked (or maybe internal) assembly code like in Assembly big numbers calculator or http://x86asm.net/articles/working-with-big-numbers-using-x86-instructions/ however this has to be ported to ARM assembly (https://azeria-labs.com/arm-data-types-and-registers-part-2/). Inclusion into C is in https://www.devdungeon.com/content/how-mix-c-and-assembly and https://en.wikibooks.org/wiki/Embedded_Systems/Mixed_C_and_Assembly_Programming
https://web.sonoma.edu/users/f/farahman/sonoma/courses/es310/310_arm/lectures/Chapter_3_Instructions_ARM.pdf page 5
I know how to compile a C application without linking any library using GCC in bare metal embedded application just setting up the startup function(s) and eventually the assembly startup.s file.
Instead, I am not able to do the same thing in Windows (I am using MINGW32 GCC). Seems that linking with -nostdlib removes also everything needed to be executed before main, so I should write a specific startup but I did not find any doc about that.
The reason because I need to compile without C std lib is that I am writing a rduced C std lib for little 32 bits microcontrollers and I would like to test and unit test this library using GCC under Windows. So, if there is an alternative simplest way it is OK for me.
Thanks.
I found the solution adding -nostdlib and -lgcc together to ld (or gcc used as linker). In this way the C standard lib is not automatically linked to the application but everything needed to startup the application is linked.
I found also that the order of these switches matters, it may not work at all, signal missing at_exit() function or work without any error/warning depending by the order and position of the options.
I discovered another little complication using Eclipse based IDEs because there are some different approaches in the Settings menu so to write the options in the right order I needed to set them in different places.
After that I had a new problem: I did not think that unit test libraries require at least a function able to write to stdout or to a file.
I found that using "" and <> forces the compiler and linker to use the library modules I want by my library and the C standard library.
So, for instance:
#include "string.h" // points to my library include
#include <stdio.h> // points to C stdlib include
permits me to test all my library string functions using the C stdlib stdout functions.
It works both using GCC and GCC Cross Compilers.
I'm attempting to write a C program incorporating OPENFILENAME and of course I need the header file. So, following the instructions provided with tcc, I downloaded the header files MinGW uses for the Win32 API (and the library files) and put them in the appropriate directories as instructed. However, when I come to compile the program, I get the following error:
In file included from sw1.c:2:
c:/prg/tcc/include/winapi/commdlg.h:503: declaration list expected
This seems rather odd, given it's a standard header. So, I look up the line and it's typedef __AW(CHOOSECOLOR) CHOOSECOLOR,*LPCHOOSECOLOR;, which doesn't look very valid to me but then I'm not really a C expert and I've mainly been writing in Linux. I have no idea why it's going wrong though and no knowledge of how to fix it? Is it a bug in tcc?
As evidence that this should be possible, here is the appropriate passage from the tcc readme:
Header Files:
The system header files (except _mingw.h) are from the MinGW
distribution:
http://www.mingw.org/
From the windows headers, only a minimal set is included. If you need
more, get MinGW's "w32api" package.
I understand that this question is similar to Error when including Windows.h with TCC but my "windows.h" file does work - it's just this that doesn't.
Does anyone know how to solve this? I'm really at a loose end!
i noticed that mingw adds alot of code before calling main(), i assumed its for parsing command line parameters since one of those functions is called __getmainargs(), and also lots of strings are added to the final executable, such as mingwm.dll and some error strings (incase the app crashed) says mingw runtime error or something like that.
my question is: is there a way to remove all this stuff? i dont need all these things, i tried tcc (tiny c compiler) it did the job. but not cross platform like gcc (solaris/mac)
any ideas?
thanks.
Yes, you really do need all those things. They're the startup and teardown code for the C environment that your code runs in.
Other than non-hosted environments such as low-level embedded solutions, you'll find pretty much all C environments have something like that. Things like /lib/crt0.o under some UNIX-like operating systems or crt0.obj under Windows.
They are vital to successful running of your code. You can freely omit library functions that you don't use (printf, abs and so on) but the startup code is needed.
Some of the things that it may perform are initialisation of atexit structures, argument parsing, initialisation of structures for the C runtime library, initialisation of C/C++ pre-main values and so forth.
It's highly OS-specific and, if there are things you don't want to do, you'll probably have to get the source code for it and take them out, in essence providing your own cut-down replacement for the object file.
You can safely assume that your toolchain does not include code that is not needed and could safely be left out.
Make sure you compiled without debug information, and run strip on the resulting executable. Anything more intrusive than that requires intimate knowledge of your toolchain, and can result in rather strange behaviour that will be hard to debug - i.e., if you have to ask how it could be done, you shouldn't try to do it.
In my Turbo C++ program, I can't run any of the graphics program. When it compiles, it shows an error like:
undefined symbol _line, _closegraph,_ getmaxx etc...
Is it due to the settings of my c-program?
Is this an old program that was written for Turbo C++, and that you're trying to compile with a modern compiler? If so, it might be the case that the program uses compiler-specific extensions and libraries, that are simply not available in the compiler you're using now.
If that is the case, you must either
find an existing library for your current environment that emulates the old Turbo C++ one, or
find out exactly what each call is supposed to do, and change the code to use something that your environment supports.
It's compile error and not link error. Looks like "graphics.h" is missing.
Do
#include "graphics.h"
Those errors are typical of a missing library in your build. Try linking the appropriate libraries and rebuild the solution (most likely graphics.lib).
-John
If the problem is of compiling error then you may add the header file:
#include<graphics.h>
if the problem still persists then make sure you have added the header file:
#include<dos.h>