Enabling/disabling SAFESEH in VC11?

Question

I created a new solution for zlib 1.2.7, set it up as a static library, added the necessary headers and source files from ./zlib/contrib/minizip and got it to compile just fine. I then linked it against libpng (also as a static lib), which also compiles fine. Then, I linked libpng to my graphics engine project (also a static library)... still no errors.

But as soon as I link my main project to my graphics engine, I get several LNK2026 errors regarding crc32.obj, deflate.obj, inflate.obj, d3dxplane.obj, d3dxvec4.obj and other zlib/directx related modules. It's telling me that they are coming from my graphics engine lib, so I've decided to fix this by adding /SAFESEH:NO to my linker flags for the corresponding projects.
NOTE: I should probably state that all projects are set to target x86, NOT x64.

The problem, however, is now I'm getting:
warning LNK4044: unrecognized option '/SAFESEH'; ignored which results in the same LINK2026 errors in my main project.
If I open up a visual studio command prompt and type LINK /? it confirms that /SAFESEH is a valid linker option. I get the same error when I use /SAFESEH (without the ':NO'), and if I omit it entirely then my main project simply refuses build.

What's going on here? How do I get around this?

Solution 1

by adding /SAFESH:NO to my linker flags

Well, you mis-spelled it. Maybe in your question, maybe in the linker settings, the kind of coincidence that tends to explain why something that should work doesn't work.

It is available without having to type it in, do favor doing it that way. Project + Properties, Linker, Advanced, scroll down the right panel, "Image has Safe Exception Handlers" setting. Use the combobox to select No.

Solution 2

A quick google shows this indicates you need to recompile the offending modules with appropriate compiler settings.

Note that this flag is only works for x86 targets. If you're targeting 64-bit, you'll get this error regardless.

Also, from http://msdn.microsoft.com/en-us/library/9a89h429(v=vs.80).aspx, which may be relevant:

The most common reason for the linker not to be able to produce an image is because one or more of the input files (modules) to the linker was not compatible with the safe exception handlers feature. A common reason for a module to not be compatible with safe exception handlers is because it was created with a compiler from a previous version of Visual C++.

It would be helpful if you provided version numbers of your compiler, and how your copy of zlib was built (did you build it yourself, and if so, with the same compiler?).

Comments

[RectangleEquals]

The first sentence in my question states that I did indeed build it myself in a new solution, and the title + tags indicate that I am using vc11. Everything is done with the same compiler version. I forgot to mention that all projects are set to x86, so I'll update my question for this.

[Nathan Ernst]

Also, did you link zlib with the /SAFESEH option set?

[RectangleEquals]

Yes, I tried that before posting my question. All projects give me the same set of errors. It's as if /SAFESEH does not exist in my linker anymore, even though it says it does.

[RectangleEquals]

That was a typo. It is correctly spelled as /SAFESEH in all projects. The only project which has that setting is my main project (the others say Librarian instead of Linker, and the option doesn't exist under Librarian -> "All Options"). I changed it to NO in my main project, and it compiled and ran without any errors... but I would rather change this at a deeper level by supporting it in my static libs, so that 3rd party devs won't be forced into disabling it in their own projects. Is this possible?

[user1703401]

Sure, rebuild all the .libs you use.

[RectangleEquals]

Zlib, libpng, and my engine are the only ones I use (besides d3d9.lib & d3dx9.lib, which of course is closed-source)... and like I said, there doesn't appear to be a setting called "Image has Safe Exception Handlers" in any of them. Therefore, rebuilding them doesn't resolve anything. And if it did, I would know because I've always rebuilt them before rebuilding my main project. So either I'm back to square one if I want a real solution, or I could just force other devs to disable the option in their projects.

[Björn Lindqvist]

Hans Passant's solution is the right one. I had the exact same symptoms and sure enough, I had written /safesh and not /safeseh.

[sonu gupta]

@RectangleEquals Are you able to solve this issue? even I am facing the same. I have checked the spelling of /SAFESEH in librarian also. All seems good, but still facing same as yours.