TTLG|Jukebox|Thief|Bioshock|System Shock|Deus Ex|Mobile
Results 1 to 5 of 5

Thread: mingw32 is not reliable for building .osm

  1. #1
    Registered: Apr 2011

    mingw32 is not reliable for building .osm

    the custom .osm i have been building for my current mission is based on Telliamed's "OSM Developer's Toolkit" ( — my fork is on github — and built with gcc+mingw32 (from the tdmgcc32 package).

    a problem that i have encountered is that from time to time, my osm would simply fail to load before any of its code gets a chance to run. most of the time it would be fine, but sometimes dromed (or thief2) would just report "failed to load 'foo.osm'" on the exact same binary that worked fine the day before. and restarting windows would generally make it work again. i have been tearing my hair out over this for the last few days, and finally understand the reason.

    the .osm will work just fine when it gets loaded at its default base address, but if it was relocated (because another dll happened to occupy part of its default address space), then the OS will fail to load it, and tell dromed that it couldnt be loaded.

    debugging the LoadLibrary() call shows that an access violation happens while the OS is setting up the dll's thread-local storage (tls) info. it turns out that dlls on windows—at least, those that must be compatible with windows 2000, as newdark requires—may not have static tls info if they will ever be loaded dynamically with LoadLibrary().

    and although neither Telliamed's code nor mine in the osm uses tls at all, the libmingw32 library that is needed for building the dll with mingw32 does, and so is causing the problem to arise. it doesnt appear that there is any configuration option, or any way to avoid this except by not using mingw32—although perhaps building it from source would provide the option of disabling tls or using the dynamically-safe TlsAlloc() apis instead of the static tls info; i dont know, i havent looked into doing that yet.

    for the moment i am choosing a base address that i think is unlikely to have any conflict, and hoping for the best. thats not really a solid answer, and it could still end up with sporadic failures for some people or even never work at all, depending on what is going on in their windows setup.

    i am not happy with this as a solution, but for now it lets me carry on building what the mission needs instead of getting bogged down in awful c++ build shite. later down the line i may look into porting the code to msvc++ instead of gcc+mingw32; unfortunately doing that it is (for my osm at least) rather more painful than one might hope.

  2. #2
    Registered: Mar 2001
    Location: Ireland
    Ugh, this sounds really familiar. NVScript had similar issues.

    It's been years and I don't remember the particulars, but I believe I ended up asking someone who was more familiar with the whole C++ build process about this, and they helped me "solve" it by converting NVScript into an MSVC project, bypassing the entire problem.

  3. #3
    Registered: Apr 2011
    yes, moving over to msvc++ is my fallback plan. had a stab at converting it already, but it got messy: unfortunately for me some critical parts of my osm are in assembly, and converting that from gnu assembler to microsoft assembler style was giving me grief.

  4. #4
    Registered: Mar 2001
    Location: Ireland
    One tip for testing if the relocation works properly is to load the same .osm twice (e.g. copied to a different filename and loaded again.)

    If you have that relocation bug, then one should fail to load every single time, as the other is using the address.

  5. #5
    Registered: Apr 2011
    oh thats an excellent idea, thanks. even after moving it over to msvc++, i will still need to check that my assembly code gets fixed up properly during relocation, and that will be an easy way to test.

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts