Make it a statically linked library. Problem solved.

Or you can just use a dummy func that you call at the beginning of your main to force the dll to be loaded ?

Or better, load yourself the dll with dlopen equivalent like on unix/linux. See here for various and cross platform dll loading.

AFAIK there is no other way.

Gully, I can link statically if I want, but I don't want to force that on my users. The user shouldn't need to do anything to make it work.

Peter, the library is created on demand. It's a singleton. Allegro5System.cpp is part of the A5 backend DLL.

If it was destroyed and created again that would explain it, but I would know if that was the case. Simply referencing a variable in a DLL changes the behavior of the program.

I set a breakpoint in RegisterSystemCreator, and it isn't even called if I don't include the line about EAGLE_ASSERT(ALLEGRO5_REGISTERED).

Gully, assuming the dlls are on the path and that there are no versioning problems, everything should still work exactly the same.

Static linking isn't an option either, as symbols are usually stripped from the executable, and ALLEGRO5_REGISTERED would be removed from the exe. I tried it, it crashes in the same place. RegisterSystemCreator hasn't run.

Peter,
I most certainly did NOT opt-in to delayed dll loading. I know for a fact that it is doing it though, because when I run my program through GDB and try to set a breakpoint in RegisterSystemCreator it never runs, static linking or not. When I reference ALLEGRO5_REGISTERED though, it must be forced to load the dll.

If I get how everything works right, I see something wrong in your code, although I'm not sure if it's the cause of your specific problem:

You call Allegro5System::RegisterSystem() for initializing a global variable. At this point, EagleLibrary's static member variables (create, eagle_lib, destroy) may not have been initialized yet (the order at which global stuff in different transaction units is initialized is undefined, and ALLEGRO5_REGISTERED and EagleLibrary are in different cpp files), so when this function calls EagleLibrary::Eagle(), the 'create' member variable may still be unitialized and most probably not 0 so the condition fails and eagle_lib points to a random chunk of memory. When you try to access it, it crashes.

The call to EAGLE_ASSERT may make the compiler change the order in which everything is initialized so it works (you're lucky). I'd say in general it's better to just never call static member functions when initializing globals because it can cause a lot of headaches.

You should never ever have this kind of dependency on initializing order of global variables (and remember: static member functions are also global variables, they're not specifically initialized before or after non member function globals). You can only be sure that variables in the same transaction unit will be initialized in the order they're defined.

Another thing, while your way is not wrong, you don't really need your create and destroy variables. Just initialize eagle_lib to null. Check if it's null in your Eagle() function instead. In the function that should destroy it also set it back to null (you don't even need to check if it's already null, since delete null is a valid operation that does nothing).

const int ALLEGRO5_REGISTERED = Allegro5System::RegisterSystem();

If ALLEGRO5_REGISTERED isn't actually referenced anywhere, the compiler/linker can remove it since it's unused. As a result, Allegro5System::RegisterSystem() would never be called to initialize the variable since it doesn't exist anymore. With the EAGLE_ASSERT line, the variable is referenced and kept, so it's correctly initialized, but when uncommented, it's unused and removed, taking all initialization side-effects with it.

On Windows, declare a DllMain function, and it will automatically be called when the DLL it's in is loaded into a process, is about to be unloaded from a process, or when a thread is started/ended in a process (do a search for it to see what parameters it takes).

Otherwise with GCC or Clang, you can mark a plain old static function with __attribute__((constructor)) and it will be called automatically when loaded (similarly __attribute__((destructor)) for when unloading).

For static-linking, GCC and Clang's attribute should still work. For MSVC, you need to do some silly section function pointer placement. This is essentially what I do in OpenAL Soft:

static void my_init_func(void)
{
    ...
}

#pragma section(".CRT$XCU",read)
__declspec(allocate(".CRT$XCU")) void (__cdecl* my_init_func_ptr)(void) = my_init_func;

I forget exactly where I learned that from or the exact details, so you may need to search around if you need more info.