Author Topic: Some comments on the Makefile  (Read 2081 times)

0 Members and 1 Guest are viewing this topic.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4900
  • Total likes: 217
  • Helpful: 108
  • Languages: EN, NO
Some comments on the Makefile
« on: February 15, 2015, 11:32:17 AM »
When OSTYPE is mingw, PNG_STATIC and ZLIB_STATIC are defined. The curious thing is that PNG isn't linked at all, it's only used by Makeobj, while zlib is actually linked dynamically (if dynamic link library is available, which it is in the zlib zip provided by mingw). In fact, a few lines down, only libgcc and libstdc++ is set up to link statically. Which leads to another thing: libgcc is linked statically into sim.exe, but dynamically into zlib1.dll and libbz2-2.dll, which I remember having read somewhere is a Bad Thing. Adding -static to force static linking of everything causes some problems when linking with SDL, at least the SDL link libraries I have.

So the question is, should the Makefile go for as much static linking as possible (I don't think statically linking with SDL is practical, and maybe not legal either) or embrace dynamic linking? There is some risk of DLL-hell with the latter, if not all builds use the same versions of GCC, zlib and bzip2.

Offline TurfIt

Re: Some comments on the Makefile
« Reply #1 on: February 15, 2015, 08:58:32 PM »
The static linking behaviour with MinGW seems to depend on what vintage of MinGW installation you're using, and how you installed/configured your libraries. Currently I need pthreadGC2.dll, SDL.dll, and irritatingly libgcc_s_dw2-1.dll. I gave up trying to figure out why it suddenly decided to need the later. In the past I've seen it call for libglib, and even libgthread, but never zlib1.dll or libbz2-2.dll.

With zlib, the simutrans makefile is asking for plain libz.a ( -lz ) which is the static version. If you want the dll you'd need to change to libz.dll.a. Not sure how you're ending up with dynamic here. (installing zlib from "./configure ; make ; make install"  right?)

The bzip2 makefile only creates a static version of the library. There's a second makefile for a shared linux version, but no ability to make a .dll at all. How'd you end up with one? (Maybe there's a new version floating around? I'm using bzip2-1.0.6 which is the latest I can find (www.bzip.org). Of course I'm stuck with a few years old MinGW since the new ones refuse to build (link) bzip2 at all... )

In general, I say static whenever feasible. Why'd you want to subject yourself to potential .dll hell?

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4900
  • Total likes: 217
  • Helpful: 108
  • Languages: EN, NO
Re: Some comments on the Makefile
« Reply #2 on: February 15, 2015, 09:19:06 PM »
With zlib, the simutrans makefile is asking for plain libz.a ( -lz ) which is the static version. If you want the dll you'd need to change to libz.dll.a.

No. If dynamic linking is allowed (-static not specified), GCC will look for x.dll.a first, then x.a (unless static linking is forbidden possibly).

With zlib, the simutrans makefile is asking for plain libz.a ( -lz ) which is the static version. If you want the dll you'd need to change to libz.dll.a. Not sure how you're ending up with dynamic here. (installing zlib from "./configure ; make ; make install"  right?)

I never build zlib. It came from mingw. Same with bzip2. Both dynamically link with libgcc, because the executable and all libraries must share the same implementation, which means libgcc must be linked dynamically if anything else is linked dynamically. This is true for other libraries as well, not just libgcc.

To force linking with libz.a and not libz.dll.a when both are present, one can use -l:libz.a instead of -lz.

In general, I say static whenever feasible. Why'd you want to subject yourself to potential .dll hell?

Well, there are several advantages with DLLs, or they never would have been made to begin with. ABI incompatibilites between MSVC and mingw, as well as between different versions of mingw kill some of those advantages, though. You can't be sure the DLL you already have works, or that you can just download a newer DLL from any source to fix vulnerabilities or bugs.

Offline TurfIt

Re: Some comments on the Makefile
« Reply #3 on: February 15, 2015, 09:37:45 PM »
Looks like the zlib windows makefile builds both the static and dynamic, but only installs the static unless you specify the dynamic too. Explains why I get a static link here - only got the static lib installed.... Not sure what ZLIB_STATIC is supposed to do - the simutrans makefile is the only occurrence of this string...


I never build zlib. It came from mingw. Same with bzip2.
That must be new. Those libs have never came with any installation I've done. But wouldn't you want to get them from the source rather than whatever molestations the MinGW people might have done to them?


or that you can just download a newer DLL from any source to fix vulnerabilities or bugs.
That sounds like a huge vulnerability in itself... sticking in an executable from any old source. Cringe.
And if the program wasn't built against the specific .dll version, who knows what it'll do.

Offline Ters

  • Coder/patcher
  • Devotee
  • *
  • Posts: 4900
  • Total likes: 217
  • Helpful: 108
  • Languages: EN, NO
Re: Some comments on the Makefile
« Reply #4 on: February 16, 2015, 06:41:22 AM »
That must be new. Those libs have never came with any installation I've done. But wouldn't you want to get them from the source rather than whatever molestations the MinGW people might have done to them?

Mingw (and Cygwin before and alongside them) have probably done many molestations to GCC, make, bash, and the list goes on, to make them work on Windows. In my experience, many projects fail to provide a build system that actually works with mingw. Thet assume that Windows builds, if supported at all, is done with Microsoft Visual Studio. When there is a ready build solution available, I go for that without hesitation. Furthermore, with mingw-get, it's very easy to upgrade (not that there have been many updates lately).

That sounds like a huge vulnerability in itself... sticking in an executable from any old source. Cringe.
And if the program wasn't built against the specific .dll version, who knows what it'll do.

With any source, I meant not us. That it should be possible to go to the zlib or mingw homepage and download the latest release, then just drop that DLL into the simutrans directory, or even into c:\windows\system (actual name will be different) to patch everything in one go. But with the mentioned ABI incompatibilities, you get DLL hell. Linux seems to have found a solution, though, with a versioned file name scheme and several symlinks.