I'm working on writing a kernel, and I have a few friends working with me on the project. We've been using DJGPP to compile the project for a while, but we're having some cross-platform compatibility issues with compiling this way that have left my main Partnet on the project unable to compile on Windows XP. (DJGPP's GCC is having issues with argument lists longer than 127 on windows XP, but not having issues with the same argument lists on Vista. So, for once, Vista works better than XP at something. o.O)
Anywho, rather than try to work out some dirty hack to make the darn thing compile with DJGPP, we've decided that we want to ditch DJGPP entirely and work with a different version of GCC for windows. The trouble is, MinGW (to my knowledge) doesn't let us use NASM syntax for the assembly portions of the code, and it would be a bit of a pain to convert it all to AT&T syntax at this point. Possible of course, since its fairly early in the project, but a pain.
So now you know the issue. My question is this: What GCC compiler distro for Windows will allow us to most easily port this project to itself? Ideally, we're looking for something that can do NASM assembler syntax, not have any reliance on externel dlls (this is a kernel here, it won't have access to them) and will work consistantly on multiple versions on Windows. What are your recommendations about the best way to go about doing this, and what version of GCC for windows do you recommend?
Note that if we are going to need to convert the project to AT&T syntax that's OK, I'd just like to not do that. We're actually using NASM to assemble the assembly bits of it, and that produces a valid .o file, but MinGW isn't able to link that in for some reason. I think the inline assembly bits (maybe 5 lines) are already AT&T syntax, as required by GCC.
Thanks!
You are probably passing the wrong object type to nasm with the -f option.
I'll bet you're passing -f coff.
You will need to pass -f win32.
Build a cross-compiler.
http://wiki.osdev.org/GCC_Cross-Compiler
This is what I did when transitioning from DJGPP for development on a Windows host. I recommend the Cygwin method, as it's slightly more stable than MSYS.
Once you've done that, configure NASM to build elf32 object files, and you're good to go.
Are you using NASM compiled for DOS or for Windows? I did not look, but it is possible that there is a difference. Also, if your NASM is too old, it might not be able to generate something MinGW can understand.
A quick Google search found a tutorial on compiling x264 under MinGW, where one of the steps is to compile NASM on MinGW.
Failing that, you could try (as suggested on a comment to another answer) using objcopy.
Related
I was wondering which compiler is better to use on Windows OS (8.1) in temrs of compatibility to c++11's (and later 14) functions, liberies and features (like lambdas) and is also comfortable to use (less bugs).
I am a university student hence I'm not looking at the subject product-wise (even though I do like to code a bit more than just projects for my studies).
I am currently using eclipse luna IDE if it matters.
Notice that compiler != IDE.
VC++ is one of the most populars on Windows and depending on its version it has a good support for C++11 features. Check the list on the msdn blog to find out if there's everything you need.
Gcc is also ported to Windows and you can install MinGW to use it (4.8.1.4 at the moment of writing this). It is pretty complete on C++11.
Clang is also available for the Windows platform and it is also complete on C++11 support (plus it has good diagnostic messages), but notice that you will have to use another linker since clang doesn't ship with one (although there is an ongoing effort to write it: http://lld.llvm.org/)
All the compilers I cited above are pretty stable but, based on my experience, if you're looking for latest and greatest C++11/14/17 features, you might just want to go for gcc or clang (VC++ is slower in adding support for newest features and the compiler is undergoing a huge update to modernize). Just keep in mind that these are compilers and not just IDEs, an IDE is a front-end supporting program that uses a compiler undercover to compile files.
To set up a C++11 compiler, I suggest installing MSYS2, it has a package manager (pacman) that can install fresh versions of GCC, GDB, Clang and many libraries like SDL, Lua etc. Very easy to use too.
As far as GCC vs CLang goes - I really tried hard to make CLang work (which is presumably faster and more friendly than GCC - produces better warnings, etc.), but failed. Issues were that CLang (which comes with MSYS2) is hard-coded to use GCC linker which produces some strange linker errors when using libstdc++ (std implementation from GCC). libc++ (a new implementation designed to work with CLang) didn't worked for me on Windows either.
So you either try build CLang from sources and hope that some configuration will work with C++11 library, OR just stick with GCC which works just fine out of the box.
As IDE, I suggest to take a look at CLion. It is very comfortable (infinitely more user-friendly and intuitive than Visual Studio, IMO). Just install it and point it to the mingw64 (or mingw32) folder of MSYS2, it will auto-detect everything for you.
It only works with CMake projects though.
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!)
I'm getting a segfault in my C program, and I thought I'd use Clangs help in figuring out why, as Valgrind isn't supported (yet).
I try to compile my program with -fsanitize=undefined to activiate runtime checks for undefined behaviour. All I'm getting is an error message which reads something like: "fsanitize doesn't support option 'undefined'". I've also tried using -fsanitize=address with the same result :/
Anyone know why this is?
It seems like -fsanitize is not supported by apple's CLang.
If you go here http://llvm.org/releases/download.html#3.4 you can get the prebuild binaries of clang, that do recognize this option.
However this is harder because then you have to use a Makefile,
IF by chance you use cmake, then you can just easily go to use makefiles.
OR replace the binaries in the Xcode.app/Contents/Developer/Toolchains/.../bin
but I don't know what can happen if you replace Apples binaries, do a backup before to be able to restore.
Honestly, I'm not myself confortable about replacing apple's binaries, because they probably added something in the clang to make it work with Xcode nicely.
Again, the GPL policy of GCC had this advantage that apple could not modify it.
-> another solution is to develop on linux,
The port to windows of CLang is on its way, but not ready yet, maybe in 3.5.
Best
so, C++11 has been around for a while and, given there already are compilers supporting it on most platforms, it would be nice to use it in some real software -- e.g. one that can be packaged in as-portable-as-possible package, preferably providing ./configure and so.
Because both Clang and GCC currently need -std=c++11 flag to compile c++11 source, and both sometimes require specific flags to work correctly (see for example How to compile C++11 with clang 3.2 on OSX lion? or C++11 Thread not working ), I'm quite afraid that the package won't work on some platforms that already support c++11 because of wrong invocation of compiler.
Q: Is there some standard how to correctly and portably compile c++11? E.g. autotools/autoconf check or some list of compiler/platform directives that describe all possible needed options? Or does the situation come from the fact that c++11 standard implementations are currently marked as "experimental" and the standard will eventually stabilize and become the default choice, not needing any usage of extra compiler flags?
Thanks
-exa
Well, if you`re trying to write portable code, i would recommend using cmake
a very powerful cross-platform, open-source build system.
Using cmake you should be able to identify the compilers available in your current machine and then generate your makefiles using the flags that you want in each case.
I have been using cmake for almost a year by now and it has significantly reduced the time consumed when trying to get a project compiling in different platforms.
I`m using CMake to generate Makefiles of C++11 projects. The only change in CMakeLists.txt I need to do is add the following:
ADD_DEFINITIONS("-std=gnu++11")
ADD_DEFINITIONS("-D_GLIBCXX_USE_C99_STDINT_TR1")
ADD_DEFINITIONS("-D_GLIBCXX_HAS_GTHREADS")
However, as I use Qt, I re-compile QtSDK with a new gcc version 4.8 and get a complete mingw system that use gcc in version 4.8.
Makings these changes, the project compile and run in Windows XP, Windows 7 and linux both 32 and 64 bits. I didn`t test it in OSX yet.
GCC is a very well respected multi-language compiler (from what I've gathered). One thing I've not been able to definitively find out is: Is it possible to use GCC on windows without anything extra like Cygwin or MinGW?
I've learned that if you use GCC on Cygwin, there is a dependency on a DLL. If you use GCC with MinGW, you eliminate that dependency but you still must have MinGW to use GCC.
Is it possible to build GCC and utilize it by itself, completely native to Windows? Like Microsoft's Compiler? After reading around, my guess is no. But I'd still like more info, if possible.
If not, why does GCC require environments like Cygwin or MinGW? I understand this now. It is because GCC requires a Unix/POSIX environment. Why it does, it still beyond me.
I did find this and it helps but doesn't really answer my question: Why does GCC-Windows depend on cygwin?
To refine my question, I guess what I'm trying to understand why GCC can't stand on it's own -- Where I have just "GCC.exe".
For MinGW, you need MinGW in the sense that MinGW provides the implementation of the gcc language system. I don't see how your question makes sense - it's like "Can I use VC++ without installing VC++?"
To clarify: MinGW is the GCC compiler executable(s), headers and support objects. There isn't anything else. There is a related but independant package called MSYS which provides some posix utilities, but you do not need this in any way in order to use the MinGW version of GCC.
What is exactly the problem with mingw? And what is native?
mingw used to generate pretty much standalone binaries, and maybe that is even more native than MSVC's, which require msvcrt, a component that needs to be installed sometimes.
So maybe you could explain what you tried with mingw, and what the exact problem is.
To disable mingw's extra dependency simply don't use exceptions (-fno-exceptions), I haven't used cygwin so not sure.
I don't think so. I've had to compile some command line apps for people in the past and always had to use cygwin.
I think the biggest reason being posix compatibility, which is what cygwin strives to bring to Win32.
Linaro used to provide that long time ago, a GCC that runs naively on Windows without MinGW or Cygwin. I am currently using that GCC 4.9 on a Windows 10 PC to compile UEFI and it is working like charm.
https://releases.linaro.org/archive/14.09/components/toolchain/binaries/gcc-linaro-arm-none-eabi-4.9-2014.09_win32.zip
simply install wsl on your computer.