Libraries built with Mingw-w64 require those dll:
libwinpthread-1.dll
libstdc++-6.dll
libgcc_s_seh-1.dll
I wonder what's up with that, what each dll does? Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Why mingw requires to always bring those dll with your exe?
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler. It's so bloated though, 9 gb for installation.
Especially libgcc_s_seh, is that structured exception handling? I thought mingw couldn't work with seh.
Newer versions of GCC (4.8+ if I'm correct) should support SEH on MinGW.
I wonder what's up with that, what each dll does?
They provide the runtime and standard library.
libwinpthread: PThreads implementation on Windows (Threading)
libstdc++: C++ Standard Library (C/C++ library functions etc.)
libgcc_s_seh: Exception handling (SEH)
Why mingw requires to always bring those dll with your exe?
Because your program uses them. If you write a program without threads, standard library and exception and any OS interaction you wont need them.
These DLL's bring everything you need to run your program. Btw. this is not a MinGW only thing, and happens on other systems / compilers too. Often you just don't note this because the OS already ships the libraries, eg. MSVC libraries are very likely on a Windows machine. Dynamic linking always requires some sort of library files, that are .dll on Windows and .so on Linux.
If you have it available on your system use ldd <your application> to see what libraries are dynamically linked.
You can install these MinGW libraries into the system libraries or somewhere where the OS can find it. This enables your programs to use it and you no longer have to ship it with every application (what avoids duplication).
On the other side another option is to static link them. Unlike dynamic linking, you don't need any DLL; on the downside is a increase of you applications size (as now the three libraries are baked into the exe now).
I wonder if I'm just wasting my time by not just using visual studio as a windows compiler.
This depends on your situation. But probably my answer will give you some more insight.
Related
I have source code for a linux application. It seems I can compile it on windows with CygWin. My question is, after compilation, can I run it on Windows?
Depends totally on what APIs you use. If you stick to C standard library things, like <stdio.h>, <stdlib.h>, etc. then yes, you can just compile and run on either OS. Or for C++ apps, there is the Standard C++ Library, which any OS / development environment should provide.
If you use any OS-specific APIs, then of course it will not be compatible with another OS. There are libraries however, like APR that try to abstract out the OS-specific bits.
From a casual glance at the code you've linked to, it appears to not use any OS-specific APIs. However:
Note that this code requires the Gnu Scientific Library, http://www.gnu.org/software/gsl/
you'll need to get that library installed as well.
The simple answer is yes; if you can compile a Linux application with Cygwin, then the compiled application will run on windows. Cygwin provides windows implementations of many unix system functions and libraries.
Cygwin/mingw(http://www.mingw.org/) should have most of the tools you need to build the binary. Once the build succeeds, you can run the binary (only) on windows.
For a cross-platform software project that builds on Linux and Windows we have distinct ways to handle third-party libraries. On Linux we build and link against the versions distributed with the CentOS/RHEL distribution, which means we link against release builds, whereas on Windows we maintain our own third-party library "packages" and on Windows we build two versions of every library - a release version that links msvcr100 and msvcp100 and a debug version that links msvcr100d and msvcp100d.
My question is simply whether it is necessary to build the debug version of the third-party dependencies on Windows or can we simply use /nodefaultlib:msvcr100 when building debug builds of our own software.
A follow up question: Where can I learn about good practices in this regard. I've read the MSDN pages about the msvc runtime, but there is very little there in terms of recommendations.
EDIT:
Let me rephrase the question more concisely. With VS2010, what is the problem with using /nodefaultlib:msvcr100 to link an executable build with /MDd when linking with libraries that are compiled with /MD.
My motivation for this is to avoid to have to build both release and debug version of third party libraries that I use. Also I want my debug build to run faster.
From the document for /MD, /MT, /LD (Use Run-Time Library):
MD: Causes your application to use the multithread- and DLL-specific version of the run-time library. Defines _MT and _DLL and causes the compiler to place the library name MSVCRT.lib into the .obj file.
Applications compiled with this option are statically linked to MSVCRT.lib. This library provides a layer of code that allows the linker to resolve external references. The actual working code is contained in MSVCR100.DLL, which must be available at run time to applications linked with MSVCRT.lib
/MDd: Defines _DEBUG, _MT, and _DLL and causes your application to use the debug multithread- and DLL-specific version of the run-time library. It also causes the compiler to place the library name MSVCRTD.lib into the .obj file.
So there is no documentation for any difference done to the generated code other than _DEBUG being defined.
You only use the Debug build of the CRT to debug your app. It contains lots of asserts to help you catch mistakes in your code. You never ship the debug build of your project, always the Release build. Nor can you, the license forbids shipping msvcr100d.dll. So building your project correctly automatically avoids the dependency on the debug version of the CRT.
The /nodefaultlib linker option was intended to allow linking your program with a custom CRT implementation. Quite rare but some programmers care a lot about building small programs and the standard CRT isn't exactly small.
Some programmers use the /nodefaultlib has a hack around a link problem. Induced when they link code that was built with Debug configuration settings with code built with Release configuration settings. Or link code that has incompatible CRT choices, /MD vs /MT. This can work, no guarantee, but of course only sweeps the real problem under the floor mat.
So no, it is not the proper choice, fixing the core problem should be your goal. Ensure that all your .obj and .lib files are built with the same compiler options and you won't have this problem. If that means that you have to pester a library owner for a proper build then pester first, hack around it only when you've discovered that you don't want to have a dependency on that .lib anymore but don't yet have the time to find an alternative.
In my DirectShow application I have a third party DLL (a 32bit DirectShow filter) that I don't have source for that links against the 32bit Windows version of Intel Threading Building Blocks (tbb.dll).
If I want to use Threading Building Blocks in my own DLL in the same process (e.g. another 32bit DirectShow filter) does this force me to use the same version of Visual Studio that the author of this third party DLL used?
EDIT - I've realised that the version independent _mt library is probably the best one to use in this scenario. What happens if third party vendors haven't built for this _mt dll?
In my own Threading Building blocks installation I notice that there are different versions of tbb.dll for different versions of Visual Studio - 2005, 2008, 2010 and 'MT' (not sure what that is yet). One obvious reason for this is that the different versions of tbb.dll link against different versions of the Visual Studio runtime library DLLs. Is it possible to tell which version of tbb.dll is required by inspection or do I have to grub around looking for strings in the binary indicating the compiler version used (the third party DLL appears to be linking the visual studio runtimes statically)?
As far as I can tell tbb.dll doesn't use manifests and side by side versioning and is given the same name for different compiler versions. A last resort would be to rename the different tbb.dlls and hack the import library or imports to reference the renamed dlls but I'd really rather avoid this. Is there a clean way to redirect the imports with linker options?
As these DLLs are well behaved DirectShow filters they won't be passing Visual Studio runtime or TBB objects between them which would clearly be dangerous. Their interaction will be limited to calling each other via standard COM DirectShow calls.
If you are not using TBB, the question is only about Visual Studio versions, then you don't have to worry: Visual C++ Runtime DLLs have different names across versions, e.g. MSVCR70.DLL, MSVCR90.DLL etc. And, as you already discovered, /MT switch will compile/link a static version of runtime and will embed the stuff into your DLL without having to worry about sharing right DLL with a peer DLL.
Is there anyway to write dlls in linux?
Do I have to install windows to write dlls in linux? Right now one of my courses requires me to write a dll for this.
You should take a look into 'shared libraries'
http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
Lots of folks are getting near the right answer but not providing it: gcc can generate win32 PE/COFF files without problem, and of course can always build as a cross compiler on any platform it can target. The binutils port targets windows .exe and .dll files natively, and there's a "dlltool" utility for handling the edge cases where Unix and Windows linkage metaphors are different.
Additionally, the "mingw32" project provides a set of link libraries and header files for building C applications against the win32 API. These likewise install just fine on any Unix.
Here's a site I turned up after a quick google with instructions for building the toolchain.
Not really. Building any kind of executable intended for OS "A" while using OS "B" is a process commonly known as cross-compilation. In this partciluar case, you would need a cross-compiler running on Linux, but targetting Windows. I don't know any vendor selling such a product.
Let's say I have an application which I compiled under cygwin, and I want to distribute that application without having the user to install cygwin. Would it be enough to package the executable and the cygwin DLL?
Things have changed. The Cygwin libraries are now under the Lesser GPL (v3), which makes it possible to bundle them with applications that fall under a wide range of licenses, from FOSS to proprietary.
What stands in the way is that the POSIX emulation in Cygwin takes things a little too far from the perspective of native Windows applications.
This is where my Cygnal project comes in. Cygnal stands for CYGwin Native Application Library: it is a drop-in compatible fork of Cygwin which changes, or in some cases simply re-configures, the behaviors of certain functionality in order to conform with native conventions of the Windows platform.
A basic "Hello, World" Cygwin program requires two libraries. A GCC run-time called cyggcc_s-1.dll and the Cygwin DLL cygwin1.dll. The Cygnal project provides a replacement for the latter. (A 32 bit build is available for download).
One glaring area of incompatibility between the Cygwin POSIX view of the world and Windows is path handling. The Cygwin view of the filesystem is through a fake / root directory, and its own internal "mount table" which provides spaces like /cygdrive, /proc and /dev. Cygnal does away with all that. Paths are Win32 paths. The current working directory behaves like the Windows current working directory. Drives are associated with current directories, and drive relative paths like D:foo.txt work under Cygnal. Under Cygnal, /dev and /proc are still available: they are accessed as the special prefixes dev:/ and proc:/. It is not permitted to chdir into these: that would not be native! Under Cygnal, if you chdir to D:\wherever then your current drive is the D drive, and the paths /foo or \foo refer to D:\foo. Cygwin's master POSIX root directory is gone.
Yet, with Cygnal, you can continue to use the POSIX functionality, making it possible to develop cross-platform programs that have less code that is switched based on platform, compared to maintaining a port using MinGW or Microsoft Visual C/C++.
For example: you can write a Win32 console application using VT100 codes and termios. The same code will run on Unixes. No need to use the Win32 console API on Windows and VT100/termios on a POSIX system.
Another example: for threading, you can just use POSIX threads. pthread_create to start a thread, pthread_mutex_lock to lock a mutex and so on. Your program doesn't need a portability abstraction for threads which translates to Win32 or POSIX; you just use the POSIX and that's it.
The uname function in Cygnal reports the sysname with a CYGNAL prefix rather than CYGWIN. By means of this, your program can tell that it's running on Cygnal rather than Cygwin (or any other POSIX platform). Thus you can make any necessary adjustments: for instance, if your program needs /dev/null, on Cygnal it can look for dev:/null instead.
Does your application actually need any Cygwin provided Posix emulation? If not, you can compile it with the -mno-cygwin flag and it won't depend on cygwin at all, but will be a native Windows application. Often, you only need a real shell (bash) to configure and build your application, but you don't actually need the Posix functionality of Cygwin.
Another alternative is MSYS + MinGW, which is a light-weight fork of Cygwin. This provides a compilation environment which produces native Windows apps by default.
A third option would be to use the MinGW compilers from Cygwin itself. They should be available via the normal Cygwin package manager. Then you would configure the project for a cross-compile using the MinGW compilers.
Normally, yes. Be sure to install the Cygwin DLL in a public location though (Windows\System32), this DLL behaves very badly when multiple versions of it are loaded on the same machine.
You could try to compile everything as static. That should allow you to run everything without the need of the the libs (since they are already in your binary).
But this will also mean that it might not work an all platforms if cygwin would need a different or newer dll.