I've recently migrated from Windows 7 to Linux (Ubuntu 14.04) and want to compile a C program that I made. The program worked perfectly under Codeblocks 12.11 using GNU GCC compiler's basic settings. When compiling under linux under Codeblocks 13.12 using GNU GCC compiler's basic settings, I get the following error messages:
undefined reference to __mingw_vprintf
undefined reference to __chstk.ms
undefined reference to _fopen
... and so on with fscanf, malloc, etc...
I'm new to Linux and I am not used to C coding, or even programming in general. Does someone have an idea about what's going on?
you have three separate problem going on here.
(1) for _fopen, Microsoft has a nasty habit of renaming all the POSIX functions so they start with an underscore, while your Linux distribution is looking for the standard POSIX name, i.e. fopen. Welcome to the wonderfully frustrating world of cross-platform development :). On solution would be to add something along these lines:
#ifdef __WIN32
#define fopen _fopen
#endif
This in effect says, if compiling on a windows machine (which typically has __WIN32 defined as a preprocessor define; and if it is not you can always make sure that it is) replace every occurrence of fopen with _fopen. The preprocessor will do this for you.
(2) for __mingw_vprintf, I've never seen this function but from the name I would surmise that it is an implementation of vprintf specific to mingw. I personally would rewrite my code to stick with the standard C function vprintf. You can read the manual page for vprintf here; and the MSDN information can be found here. Again notice that many of the Microsoft provide functions have an underscore prepended to the name. You can do something like what you did in case (1) above.
N.B. Actually if I were to rewrite the program I would use C++ IO-streams, but I am sticking to a pure C answers.
(3) for __chstk.ms, again I've never seen this function. My suspicion is that it is something inserted into your code to perform stack checking to help prevent stack-based exploits. To the best of my knowledge there is no way you are going to get that to work on a Linux machine.
Related
I am writing Java bindings for a C library, and therefore working with JNI. Oracle specifies, reasonably, that native libraries for use with Java should be compiled with multithread-aware compilers.
The JNI docs give the specific example that for gcc, this multithread-awareness requirement should be met by defining one of the macros _REENTRANT or _POSIX_C_SOURCE. That seems odd to me. _REENTRANT and _POSIX_C_SOURCE are feature-test macros. GCC and POSIX documentation describe their effects in terms of defining symbols and making declarations visible, just as I would expect for any feature-test macro.
If I do not need the additional symbols or functions, then do these macros in fact do anything useful for me? Does one or both cause gcc to generate different code than it otherwise would? Do they maybe cause my code's calls to standard library functions to be linked to different implementations? Or is Oracle just talking out of its nether regions?
Edit:
Additionally, it occurs to me that reentrancy is a separate consideration from threading. Non-reentrancy can be an issue even for single-threaded programs, so Oracle's suggestion that defining _REENTRANT makes gcc multithread-aware now seems even more dubious.
The Oracle recommendation was written for Solaris, not for Linux.
On Solaris, if you compiled a .so without _REENTRANT and ended up loaded by a multi-threaded application then very bad things could happen (e.g. random data corruption of libc internals). This was because without the define you ended up with unlocked variants of some routines by default.
This was the case when I first read this documentation, which was maybe 15 years ago, the mention of the -mt flag for the sun studio compiler was added after I last read this document in any detail.
This is no longer the case - You always get the same routine now whether or not you compile with the _REENTRANT flag; it's now only a feature macro, and not a behaviour macro.
I am a student in Computer Science, and I am learning about logic programming with Prolog.
I have found an interesting Prolog interpreter, picoProlog (http://spivey.oriel.ox.ac.uk/corner/Logic_Programming).
To know more about Prolog, I am trying to compile their source code, but I failed.
In this web page, they said:
The interpreter source is written in a minimal dialect of Pascal, avoiding many features including pointers, but using macros to overcome some of Pascal's limitations, in a style inspired by Kernighan and Plauger's book Software tools in Pascal. It comes with a translator from the Pascal dialect into C that can be used to build the interpreter and also source for the macro processor that is needed.
To build the interpreter on a Linux machine, just extract the tar file and type make. The building happens in several stages:
First, the Pascal-to-C translator ptc is built from C source, including a lexer and parser written with lex and yacc. The file README gives some details of the very restricted Pascal subset accepted by this translator.
Next, ptc is used to build the macro processor ppp.
Finally, the picoProlog interpreter is built from the source code in the file pprolog.x by first expanding macros using ppp to obtain a file pprolog.p, then translating to C with ptc, and lastly compiling the C code.
Text and software copyright © J. M. Spivey, 1996, 2002, 2010.
They said about compiling on Linux only, so I don't know how to compile this source code in Windows machine. Can I compile it with Turbo Pascal 7.0 (without any requirement) on Windows XP? Can you remove some part of script for Pascal compiling only?
I found this question while googling, and though it's old, I thought it would be helpful to add a definitive answer from the author of the program.
It is indeed not too hard to get picoProlog to compile with the Free Pascal Compiler. I've incorporated Marco's suggestions into the source, fixed a small bug that was revealed, and added a workaround for an odd feature of Free Pascal. The results can be found on the GitHub page:
https://github.com/Spivoxity/pprolog
with instructions for building in the README.
Note: I built this with Free Pascal under Linux on x86_64, but haven't tested it on Windows. I can't see a reason why it wouldn't work.
Edit 18 Oct 2022 -- Replaced BitBucket with GitHub.
To avoid spending more time in getting the P2C/PTC bootstrapping to run while you are probably only interested in the interpreter and not its *nix bootstrapping, I think it is easier to forget the PTC stuff and focus getting the pascal parts to compile/work with FPC 2.6.x. (the below took 10 minutes), generating a standalone Windows EXE with 10-20 code line additions.
Start with ppp, hmm, that compiles (nand works!) out of the box:
D:\dls\prlg\pprolog>fpc ppp.p
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling ppp.p
Linking ppp.exe
394 lines compiled, 0.1 sec , 30352 bytes code, 1692 bytes data
The code does looks like it is meant to have its input piped in. We haul pprolog.x through it (ppp) and it (pprolog.pp) almost compiles. There are four problems, but all are fixable by adding some code to the top, and not changing original code (marked with MVDV: in the source)
Some range check errors because integer type is too small for the 1MB stackspace that is set up. This prohibits Turbo Pascal usage, but we can workaround it by defining integer as longint.
Seems it assumes that forward functions don't need their arguments repeated while in FPC they generally do, fixed.
In the final function of ("initialize") some non standard ptc library functions are used that borrow from C (argv, argc) instead of their typical pascal equivalents. Fixed.
(reported by original author after testing) ParseFactor has a right hand recursion that is substituted by reading
the result. Enable TP mode ( {$mode tp} above the uses line), or add () to disambiguate
After these, pprolog.pp compiles with FPC:
Free Pascal Compiler version 2.6.2 [2013/02/12] for i386
Copyright (c) 1993-2012 by Florian Klaempfl and others
Target OS: Win32 for i386
Compiling pprolog.pp
pprolog.pp(487,19) Warning: unreachable code
pprolog.pp(532,19) Note: Local variable "dummy" is assigned but never used
Linking pprolog.exe
2150 lines compiled, 0.1 sec , 84400 bytes code, 13932 bytes data
1 warning(s) issued
1 note(s) issued
Some notes:
UNTESTED
I don't know if I got the range of argv/argc exactly right. (0..argc-1 while paramcount is 1-based etc) Check if necessary.
The string system predates the TP String type and is convoluted (probably because of PTC, see README), I don't know if it will work.
I've put the resulting, compiling source code at http://www.stack.nl/~marcov/files/pprolog.pp
Good luck!
Given how many different variations of Pascal have existed, my gut feeling is it's easier to get hold of a Linux environment than to adjust the Pascal source code to fit the compiler you have. And this is only the first step.
Getting a Linux environment? Try a virtualbox - https://www.virtualbox.org
Hullo,
When one disasembly some win32 exe prog compiled by c compiler it
shows that some compilers links some 'hidden' routines in it -
i think even if c program is an empty one and has a 5 bytes or so.
I understand that such 5 bytes is enveloped in PE .exe format but
why to put some routines - it seem not necessary for me and even
somewhat annoys me. What is that? Can it be omitted? As i understand
c program (not speaking about c++ right now which i know has some
initial routines) should not need such complementary hidden functions..
Much tnx for answer, maybe even some extended info link, cause this
topic interests me much
//edit
ok here it is some disasembly Ive done way back then
(digital mars and old borland commandline (i have tested also)
both make much more code, (and Im specialli interested in bcc32)
but they do not include readable names/symbols in such dissassembly
so i will not post them here
thesse are somewhat readable - but i am not experienced in understending
what it is ;-)
https://dl.dropbox.com/u/42887985/prog_devcpp.htm
https://dl.dropbox.com/u/42887985/prog_lcc.htm
https://dl.dropbox.com/u/42887985/prog_mingw.htm
https://dl.dropbox.com/u/42887985/prog_pelles.htm
some explanatory comments whats that heere?
(I am afraid maybe there is some c++ sh*t here, I am
interested in pure c addons not c++ though,
but too tired now to assure that it was compiled in c
mode, extension of compiled empty-main prog was c
so I was thinking it will be output in c not c++)
tnx for longer explanations what it is
Since your win32 exe file is a dynamically linked object file, it will contain the necessary data needed by the dynamic linker to do its job, such as names of libraries to link to, and symbols that need resolving.
Even a program with an empty main() will link with the c-runtime and kernel32.dll libraries (and probably others? - a while since I last did Win32 dev).
You should also be aware that main() is only the entry point of your program - quite a bit has already gone on before this point such as retrieving and tokening the command-line, setting up the locale, creating stderr, stdin, and stdout and setting up the other mechanism required by the c-runtime library such a at_exit(). Similarly, when your main() returns, the runtime does some clean-up - and at the very least needs to call the kernel to tell it that you're done.
As to whether it's necessary? Yes, unless you fancy writing your own program prologue and epilogue each time. There are probably are ways of writing minimal, statically linked applications if you're sufficiently masochistic.
As for storage overhead, why are you getting so worked up? It's not enough to worry about.
There are several initialization functions that load whenever you run a program on Windows. These functions, among other things, call the main() function that you write - which is why you need either a main() or WinMain() function for your program to run. I'm not aware of other included functions though. Do you have some disassembly to show?
You don't have much detail to go on but I think most of what you're seeing is probably the routines of the specific C runtime library that your compiler works with.
For instance there will be code enabling it to run from the entry point 'main' which portable executable format understands to call the main(char ** args) that you wrote in your C program.
I use dev c++ for my c projects,because it's simple for me.I installed it with the mingw extension.Well,I included stdlib.h and made a call to mrand which according to manpages belongs to that header but I got a linker error.I looked in mingw's headers and found no declaration for mrand although the glibc has one in stdlib.Am I missing something?I thought mingw and gcc were the same.If they are different I suppose that there isn't a way to get gcc's full power.Right?Thank you.
mrand is not part of the standard C library, nor is it present in standard Linux manpages. Whatever compiler you previously used may have had it as a proprietary extension, but since you haven't mentioned which (it's not GCC or MSVC, at least), I can't tell what mrand is supposed to do, and so it's hard to suggest an alternative function to use.
Note that glibc does offer a mrand48(). Since this is a POSIX function, not a standard C function, it may or may not be present in other C libraries - but note that this is a function of the C library (glibc), not the compiler (gcc/mingw).
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.