sf::Ftp linker error...

[slotdev]

Hi

I get this:

error LNK2019: unresolved external symbol "public: class sf::Ftp::Response __thiscall sf::Ftp::CreateDirectoryA

Previous threads from a long time ago suggest its to do with the order of Windows header files. I've tried to work around this, and no luck. Either I can get it to compile, but fail on linking, or it just won't compile (with header order the other way).

Any ideas on a work-around?

Thanks
Ed

[eXpl0it3r]

You should always give more information, based on that we can't figure out what the problem is, because we've no idea when it happens (compiling SFML or compiling your appliction), we don't know in which context it happens (SFML example or your own code) and we don't know which SFML version you're refering to (1.6 or 2.0).

For SFML 2 it makes sense that this symbole isn't found because there doesn't exist a CreateDirectoryA function in sf::Ftp. There's only a createDirectory() function (see doc).

[Nexus]

CreateDirectory might be a macro in a Windows header. Don't include <Windows.h> unless really necessary. And switch to SFML 2 when possible.

[slotdev]

Hi

Sorry....

Yes CreateDirectory is a macro in WinDef.h, which is included from Windows.h somewhere along the way.
It happens when compiling my application. I have a library which is my game engine, and other assorted things, and when the whole program gets linked, then it falls over.

I do use SFML 2.0 but an older build (pre camelCase conversion) - we are updating soon
I'll have to see what happens then, but as it stands, the linker doesn't know which function to use - the Windows API one or the SFML one.

I have to support this legacy code for a while (probably 6 months) so I do need a solution. Not including windows.h sadly isn't one I have other code that depends on it.

Thanks

[Nexus]

Not including windows.h sadly isn't one I have other code that depends on it.

I don't mean you shouldn't use the Windows API at all, but you should abstract it better from the rest of the code. For example, limit the #include <Windows.h> to a .cpp file in which global functions encapsulate the functionality. These functions are declared in a corresponding header file to interact with the other code parts. Avoid to mix SFML and WinAPI functionality in the same file.

Clear interfaces and separate, local dependencies are generally a good idea (concerning maintenance and bugfixing), they do not only solve your macro problem.