MinGW and missing DLL’s

Posted on by

UGH

Stuff like this drives me crazy.  Once upon a time everything was statically linked, there were no DLL’s, and all exe’s had a lot of the same code in them, and people realized that the majority of a hard disk could literally contain the same thing over and over.  Not to mention that if you were to fix some bug in say, LIBC you would have to re-compile everything.  So we entered the brave new world of dynamic linking where we now live in the proverbial DLL hell, that although we did save space, we have things where slight variations in the same DLL can break things in unforeseen ways.  People have tried various things such as weak linking, Side by side assemblies, Frameworks, and all kinds of things to try to keep things together.

Honestly it’s just easier to go back, and statically link things, and just re-build as needed.

common culprits of MinGW based stuff always include:

  • libwinpthread-1.dll
  • libgcc_s_dw2-1.dll
  • libstdc++-6.dll

ugh.

The hard one is the pthread library.  If you try to link it statically it’ll try to link everything else statically and not every DLL can link statically (SDL* keep reading).  But GCC / Binutils does have the option to turn various features on and off through the link string

-static-libstdc++ -static-libgcc -Wl,-Bstatic -lstdc++ -lpthread -Wl,-Bdynamic

As you can see, everything after “-Wl,-Bstatic” will be linked statically, while everything after “-Wl,-Bdynamic” will go back to being dynamically linked.

Ok, that is great but what about SDL, you may ask.  Well sure it’s a DLL, but even DLL’s come from somewhere.  Download the source, build it yourself and you can directly link the objects that make up the DLL.  In version 1.2.15 they live in the .libs directory.

SDL-1.2.15\build\.libs\*.o

And on Windows, if you get weird errors like:

SDL_dx5events.o: In function `DX5_DInputInit’:
SDL-1.2.15/./src/video/windx5/SDL_dx5events.c:183: undefined reference to `IID_IDirectInputDevice2A’

Just add the -ldxguid library and you can link this too.  I’m sure once upon a time people may not have had DirectX 5 or higher, but this isn’t 1997.

And please at least test your programs with no path, so that way you are aware of what is needed for re-distribution.

set path=.
D:\dosbox-code-0-4068\dosbox\trunk\src>dosbox.exe

DOSBox SVN

It gets so old when people never test.  And people freak out trying to download DLL’s from weird sites, and you know that never ends well.

Oh yeah, and a static version of DOSBox is 4MB.

4,033,550 dosbox.exe

I know that was massive a long long time ago, but today?

12 thoughts on “MinGW and missing DLL’s”

  1. I’ve noticed as well issues with dynamic linking and old OS compatibility whereas with static link then compatibility is better since the unused functionality is stripped.

    In the case of DOSBox since the 3rd party libraries it depends on are rarely updated then it’s not really an issue to use static.

    I’ve also noticed people not using the original mingw but offshoots like TDM or other peoples builds of mingw instead of downloading straight from the mingw site. This introduces compatibility issues and weirdness due to what people have or have not included or how they have compiled.

    neozeed,
    If you’re bored I was wondering if you could review these guides I put together:
    http://www.vogons.org/viewtopic.php?f=31&t=55706&p=631518#p631518

    Would be interested in your perspective.

    Haven’t updated since before Thanksgiving since I’ve been busy but about to get back to working on them again.

    • I really wonder about SDL, directX and 9x… Do threads even really work?

      Primarily it’s libgcc, libg++, and the pthread abstraction that wreack havok. It would probably be better to just do a native Windows build with Direct Draw to be honest.

      I’ve already been bit with people using arch specific builds of these that turn out to be very specific…it is a strength and pain having source as anyone can and will make changes and binaries.. myself included.

  2. This is why I use Linux on my desktop – I care more about building random bits of software than I do about running Microsoft Office or games. Either I use pre-built packages from my distribution, which are built for the libraries I already have, or I built the software myself, and the configure script or whatever knows where to find all the libraries instead of me needing to tell it where I decided to install the libraries I built, or downloaded from some random site.

    Of course neozeed I imagine you wouldn’t know what to do with all your spare time if it was so easy for you to compile things 🙂

    Also, it is weird to see DosFreak without all the eyes and horns!

    • See and it’s exactly this that got me off of Linux. How many libc do I need? Isn’t it great when someone decides to remove stuff from said libc and break shit left and right, with the ‘fix’ either to pre-pend symbols to the dynalinker or rebuild libc myself so it doesn’t collide.

      Not to mention the utter fantasy it is to take anything a.out and run it today, meanwhile SQL 4.21 from NT 3.1 runs on Windows 10.

      Sorry, Linux suffers from the same catastrophic problems.

      • SQL Server 4.21 came out in 1993, so that’s pretty impressive, but what broke my faith in Windows software always working on Windows was that Visual C++ 6.0, which came out in 1998, stopped working when Windows 8.1 came out. I see that since I hit that roadblock people have figured out that the solution is renaming MSDEV.EXE to something else!!

        I think I’ve only got one libc, and it’s pretty rare that I want to run old binaries – normally I can just recompile the old software for the new distribution, which is what I think is the nice thing.

        I see it’s definitely hard to run a.out binaries! I managed to build the kernel module for the a.out format, but then I need the dynamic loader, and I found an old one but it just segfaulted. I also had to change some setting in SELinux that it said I really shouldn’t change, but then earlier today I ran across MS KB891667 which said I need to turn off DEP, so I guess Windows isn’t perfect in that regard either.

        I think if I was going to run this old a.out version of DOOM I’d prefer to just run it under the old version of Slackware I used to run it under anyway to get the full experience 🙂

        • Ah the binary hook fixes. It’s the insanity that made SimCity run, and eventually broke other stuff.

          Ever since the MSDN crowd ousted the architecture group it’s been chaos for everything they touched (Windows 8).

          The too late dance to phones and tablets was just that. It’s amazing how Linux succeed in user space by jettisoning as much as the user could see.

  3. I ran into the same problem with binaries compiled with Cygwin. Its pretty annoying, but at least it isn’t as bad as MSVCRT hell when dealing with VS.NET compiled binaries in various versions of Windows.

    • Cygwin is the worst when it comes to this. Older cygwin1.dll will forkbomb machines without warning.

      It was after first messing with dynamips that I had a forkbomb crash that I’ve done so much to steer clear of Cygwin. And it absolutely was the reason I did that re-build of dynamips on MinGW. Although now with the Linux subsystem on Windows it’s kind of mooit also inspired me to rebuild the early GCC/Binutils/GAS on MinGW so I can build early a.out kernels.

      It’ll be interesting to see how effective Google is at jettisoning Linux from it’s #2 spot of poularity, mobile devices. I suspect Linux will reign Supreme on the server space for quite some time. Not until we have a generation that hates Unix.

      • What is the story with Cygwin and fork bombing? I’ve used Cygwin extensively since Windows 95 and don’t recall anything of the sort, although I haven’t built anything myself on it for about 10 years. The one problem I do have with it is ironically the opposite – occasionally it will fail to fork a process when required, bringing down our software.

        And forking is just so slow on Cygwin, enough that I’d go for mingw to avoid it if I was starting over now, but back when I started using Cygwin my porting skills wouldn’t have been sufficient.

        • So lucky to have it prevent the fork… I used to use it religiously,. But it was only for stuff like syslog, tftp and other network crap (SNMP tools). And it was me just being too much of a wimp to just not port BSD syslog and friends directly to Windows.

          I’ve had catastrophic blowups with cdrtools and super old GCC / DJGPP cross tools. It really wasn’t until I did the x68000 GCC re-port, along with the Linux kernel that it’s obvious in retrospect that GCC is the 3 key programs and the one that forks and breaks stuff is the driver, gcc.c so the obvious fix is to use the DOS port version of GCC as it doesn’t fork and runs the other programs one at a time. The other two, cccp and cc1 just parse text files. There is less than no magic there. The rest of the chain is binary, gas and binutils but again they already run on the i386 and only do one thing, all I did was tell them to open binary files in binary mode.

          As always, in retrospect it’s damned obvious.

Leave a Reply