Closed. This question needs details or clarity. It is not currently accepting answers.
Want to improve this question? Add details and clarify the problem by editing this post.
Closed 5 years ago.
Improve this question
What kind of software or programming language that I've to learn for creating single executable program without any .dll or other formats independently?
Any suggestion I would appreciate!
It is operating system specific (and not defined by the language itself). Read more about linkers.
You may want to use C++11 (or C++14) and instruct your C++ compiler to statically link your executable. So you should read the documentation of your compiler; with GCC you could pass -static to the g++ command.
You may also want to use the Go language. The usual compiler for Go is trying to generate statically linked executables.
BTW, a statically linked executable still have dependencies, e.g. to its operating system kernel (and perhaps utilities and some system files) : obviously, a statically linked executable for Windows won't run on Linux.
(for instance, on Linux, any program using the standard system(3) function silently depends upon /bin/sh....)
In practice, I generally would not recommend statically linking the C standard library, but YMMV.
Of course, you need some source code editor to write your code (I prefer GNU emacs). Some people are using IDEs, but I prefer to run explicitly the compilation command (perhaps using some build automation tool like GNU make).
(notice that DevC++ or CodeBlocks is an IDE, not a compiler)
NB: I recommend reading Operating Systems : Three Easy Pieces (freely downloadable, each chapter has its own PDF file) to understand more about operating systems.
A truly independent "executable" is an image that you flash onto an embedded device. Your image may (but doesn't need to) bundle a library such as FreeRTOS that functions as a sort of mini-OS. Other than actual hardware, your program will be entirely self-sufficient.
Otherwise, you are at least beholden to having an operating system in place, with access to the "runtime" support library for your language (although this can often be statically linked) and possibly third party libraries on top of that (which may often be statically linked too).
Sometimes when trying to be self-contained, you go so far in the other direction that actually your "program" is not executable at all, but just a script to be passed through a Python or Go or JavaScript or VBScript interpreter. This is in fact the opposite of self-contained, though it is nice and portable if implementations of that language exist on all your target platforms.
Code that runs on a VM (Java, .NET) is a sort of half-way house between these.
Visual Studio:
Project->'project' Properties
Configuration Properties -> C++ -> Code Generation
Runtime Library -> Multithreaded [debug]
Don't use Multithreaded [debug] DLL
Also, set [debug] for Debug build and NOT [debug] for Release build. You can switch between build types with the 'Configuration' dropdown in the upper left corner.
Related
When I'm stepping into debugged program, it says that it can't find crt/crt_c.c file. I have sources of gcc 6.3.0 downloaded, but where is crt_c.c in there?
Also how can I find source code for printf and rand in there? I'd like to step through them in debugger.
Ide is codeblocks, if that's important.
Edit: I'm trying to do so because I'm trying to decrease size of my executable. Going straight into freestanding leaves me with a lot of missing functions, so I intend to study and replace them one by one. I'm trying to do that to make my program a little smaller and faster, and to be able to study assembly output a bit easier.
Also, forgot to mention, I'm on windows, msys2. But answer is still helpful.
How can I find source code for printf and rand in there?
They (printf, rand, etc....) are part of your C standard library which (on Linux) is outside of the GCC compiler. But crt0 is provided by GCC (however, is often not compiled with debug information) and some C files there are generated in the build tree during compilation of GCC.
(on Windows, most of the C standard library is proprietary -inside some DLL provided by MicroSoft- and you are probably forbidden to look into the implementation or to reverse-engineer it; AFAIK EU laws might mention some exception related to interoperability¸ but then you need to consult a lawyer and I am not a lawyer)
Look into GNU glibc (or perhaps musl-libc) if you want to study its source code. libc is generally using system calls (listed in syscalls(2)) provided by the Linux kernel.
I'd like to step through them in debugger.
In practice you won't be able to do that easily, because the libc is provided by your distribution and has generally been compiled without debug information in DWARF format.
Some Linux distributions provide a debuggable variant of libc, perhaps as some libc6-dbg package.
(your question lacks motivation and smells like some XY problem)
I intend to study and replace them one by one.
This is very unrealistic (particularly on Windows, whose system call interface is not well documented) and could take you many years (or perhaps more than a lifetime). Do you have that much time?
Read also Operating Systems: Three Easy Pieces and look into OsDev wiki.
I'm trying to do so because I'm trying to decrease size of my executable.
Wrong approach. A debugger needs debug info (e.g. in DWARF) which will increase the size of the executable (but could later be stripped). BTW standard C functions are in some common shared library (or DLL on Windows) which is used by many processes.
I'm on windows, msys2.
Bad choice. Windows is proprietary. Linux is made of free software (more than ten billions lines of source code, if you consider all useful packages inside a typical Linux distribution), whose source code you could study (even if it would take several lifetimes).
In a tutorial I've encountered a new concept (for me), that I never thought is possible. Actually, I thought that compilation is an entirely pre-run-time process. This is the phrase from tutorial: "Compile time occurs before link time (when the output of one or more compiled files are joined together) and runtime (when a program is executed). In some programming languages it may be necessary for some compilation and linking to occur at runtime".
My questions are:
Is pre-run-time compilation and linking processes absolutely different from run-time compilation and linking? If yes, please explain the main differences.
How are code sections that need to be compiled(linked) during run-time marked and where is that information kept? (This may be different from language to language, if possible, please give a specific example).
Thank you very much for your time!
Runtime compilation
The best (most well known) example I'm personally aware of is the just in time compilation used by Java. As you might know Java code is being compiled into bytecode which can be interpreted by the Java Virtual Machine. It's therefore different from let's say C++ which is first fully (preprocessed) compiled (and linked) into an executable which can be ran directly by the OS without any virtual machine.
The Java bytecode is instead interpreted by the VM, which maps them to processor specific instructions. That being said the JVM does JIT, which takes that bytecode and compiles it (during runtime) into machine code. Here we arrive at your second question. Even in Java it can depend on which JVM you are using but basically there are pieces of code called hotspots, the pieces of code that are run frequently and which might be compiled so the application's performance improves. This is done during runtime because the normal compiler does not have (or well might not have) all the necessary data to make a proper judgement which pieces of code are in fact ran frequently. Therefore JIT requires some kind of runtime statistics gathering, which is done parallel to the program execution and is done by the JVM. What kind of statistics are gathered, what can be optimised (compiled in runtime) etc. depends on the implementation (you obviously cannot do everything a normal compiler would do due to memory and time constraints - guess this partly answers the first question? you don't compile everything and usually only a limited set of optimisations are supported in runtime compilation). You can try looking for such info but from my experience usually it's very badly documented and hard to find (at least when it comes to official sources, not presentations/blogs etc.)
Runtime linking
Linker is a different pair of shoes. We cannot use the Java example anymore since it doesn't really have a linker like C or C++ (instead it has a classloader which takes care of loading files and putting it all together).
Usually linking is performed by a linker after the compilation step (static linking), this has pros (no dependencies) and cons (higher memory imprint as we cannot use a shared library, when the library number changes you need to recompile your sources).
Runtime linking (dynamic/late linking) is actually performed by the OS and it's the OS linker's job to first load shared libraries and then attach them to a running process. Furthermore there are also different types of dynamic linking: explicit and implicit. This has the benefit of not having to recompile the source when the version number changes since it's dynamic and library sharing but also drawbacks, what if you have different programs that use the same library but require different versions (look for DLL hell). So yes those two concepts are also quite different.
Again how it's all done, how it's decided what and how should be linked, is OS specific, for instance Microsoft has the dynamic-link library concept.
If I build a DLL with Rust language, does it require libgcc*.dll to be present on run time?
On one hand:
I've seen a post somewhere on the Internet, claiming that yes it does;
rustc.exe has libgcc_s_dw2-1.dll in its directory, and cargo.exe won't run without the dll when downloaded from the http://crates.io website;
On the other hand:
I've seen articles about building toy OS kernels in Rust, so they most certainly don't require libgcc dynamic library to be present.
So, I'm confused. What's the definite answer?
Rust provides two main toolchains for Windows: x86_64-pc-windows-gnu and x86_64-pc-windows-msvc.
The -gnu toolchain includes an msys environment and uses GCC's ld.exe to link object files. This toolchain requires libgcc*.dll to be present at runtime. The main advantage of this toolchain is that it allows you to link against other msys provided libraries which can make it easier to link with certain C\C++ libraries that are difficult to under the normal Windows environment.
The -msvc toolchain uses the standard, native Windows development tools (either a Windows SDK install or a Visual Studio install). This toolchain does not use libgcc*.dll at either compile or runtime. Since this toolchain uses the normal windows linker, you are free to link against any normal Windows native libraries.
If you need to target 32-bit Windows, i686- variants of both of these toolchains are available.
NOTE: below answer summarizes situation as of Sep'2014; I'm not aware if it's still current, or if things have changed to better or worse since then. But I strongly suspect things have changed, given that 2 years have already passed since then. It would be cool if somebody tried to ask steveklabnik about it again, then update below info, or write a new, fresher answer!
Quick & raw transcript of a Rust IRC chat with steveklabnik, who gave me a kind of answer:
Hi; I have a question: if I build a DLL with Rust, does it require libgcc*.dll to be present on run time? (on Windows)
I believe that if you use the standard library, then it does require it;
IIRC we depend on one symbol from it;
but I am unsure.
How can I avoid using the standard library, or those parts of it that do? (and/or do you know which symbol exactly?)
It involves #[no_std] at your crate root; I think the unsafe guide has more.
Running nm -D | grep gcc shows me __gc_personality_v0, and then there is this: What is __gxx_personality_v0 for?,
so it looks like our stack unwinding implementation depends on that.
I seem to recall I've seen some RFCs to the effect of splitting standard library, too; are there parts I can use without pulling libgcc in?
Yes, libcore doesn't require any of that.
You give up libstd.
Also, quoting parts of the unsafe guide:
The core library (libcore) has very few dependencies and is much more portable than the standard library (libstd) itself. Additionally, the core library has most of the necessary functionality for writing idiomatic and effective Rust code. (...)
Further libraries, such as liballoc, add functionality to libcore which make other platform-specific assumptions, but continue to be more portable than the standard library itself.
And fragment of the current docs for unwind module:
Currently Rust uses unwind runtime provided by libgcc.
(The transcript was edited slightly for readability. Still, I'll happily delete this answer if anyone provides something better formatted and more thorough!)
Are there any free, GCC-compatible suites for Windows that generate standalone executables without external dependencies?
Here are a few that do not fit the bill, ordered by undesirability, least to most:
MinGW (MSVCRT.DLL)
Cygwin (Cygwin runtime DLLs)
DJGPP (NTVDM.EXE; not present on x64 platforms)
Right now I'm leaning towards (and using, albeit tentatively,) MinGW, as it does seem to be the "cleanest" approach. I still am not thrilled with the MSVCRT.DLL dependency, especially as I can and do have to deal with customers running pre-Win2K. (Windows 2000 was the first edition to ship with MSVCRT.DLL) Distributing MSVCRT with the application is not an option.
P.S.: I am aware that there is an attempt to create an MSVCRT replacement for MinGW, but it is still unstable/beta, and has limited functionality; not something I'd feel comfortable using for production applications.
P.P.S.: Answers to the effect of "MSCVRT is usually there anyway," or "Just package the redist" are not constructive answers. The question specifically asks how to AVOID dependencies, not ensure their presence.
To avoid MSVCRT with MinGW, use the following flags for the linker:
-nostdlib -Wl,--exclude-libs,msvcrt.a -Wl,-eWinMain
Notice that you have to declare a function named WinMain (you can also choose another name for it) which will be your main. You also can't use any of the standard functions like strlen, printf and friends. Instead, you must use the WinAPI equivalents like lstrcmp, wsprintf, etc.
You can see an example of this using SCons at:
https://sourceforge.net/p/nsis/code/6160/tree/NSIS/trunk/SCons/Config/gnu
I've used this for my project that also requires Windows 9x compatibility. This also has the nice side effect of having smaller executables. From your comments above, it seems you're looking for that too. If that's the case, there are even more tricks you can use in the file I linked above.
Microsoft has a table matching CRT functions to WinAPI at the following KB99456:
Win32 Equivalents for C Run-Time Functions (Web Archive)
More information on getting rid of CRT (although for VC, it can still help) at:
http://www.catch22.net/tuts/win32/reducing-executable-size
This question already has answers here:
Closed 12 years ago.
Possible Duplicate:
An executable Python app
So I have taken a little online python course and I now have an understanding of simple programming. We made our own scrabble game, for example. However what i dont understand is how these .py .c .class or whatever get to an exe form?
I never as an end user have to open .py files ever, with windows it is always .exe, but how are these made? Are they batch files that merely execute the file? But what about dlls?
I guess my question is in any language how is the finished code executed on the machine. When i run a java program i dont have to fiddle with class files i just click an exe.
EDIT......
What i mean isnt how to make python an exe, but how does software get to thatstage full stop. I know interpreted languages go to the interpreter, i guess you use an intermediate language to make an exe which runs the code.
Generally the code would be compiled into an executable, which may or may not internally contain everything it needs to run. (If it doesn't, then it could come packaged in an installer which distributes what it needs.)
Specific to Python, a quick Google search turned up this. For interpreted languages, since there is really no "compile" step, you'd need some tool to "convert [language] to windows exe" to accomplish what you're asking.
Most software you run on Windows is not written in an interpreted language like Python, and comes with an installer ('setup.exe') which was generated by some software that creates installers for your code. The purpose of the installer is to both install your program and all the files it may depend on that you have installed as a developer but your end users don't.
See these related questions:
How can I create a directly-executable cross-platform GUI app using Python?
py2exe - generate single executable file
very simply and speaking generically, you would either compile or interpret you source code. An exe or dll would be the result of compilation (JITs as another item to learn about).
You should also learn about "server side" and "client side" code. A web based application would run server side code which may generate html (and perhaps javascript) and send that down to the client side browser.
There are many ways to deploy exe's, dlls etc - simply copy them to the target machine, or use an installer or via a browser plug in environment.
When you use a compiled language that generates native code, the compiler is responsible to generate an executable file based on your source code.
If the language is interpreted, running the program usually means launching the interpreter and passing it the main file of the program. Some languages offer tools to package the interpreter and the sources into an executable.
If the language is compiled but generates intermediate code, you need to run the virtual machine, like an interpreted language. However, if you use .NET on Windows, the compiler generates an executable that loads the virtual machine automatically.