Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

fixed header collisions when windows.h included #69

Closed
wants to merge 1 commit into from

Conversation

stevemk14ebr
Copy link

@stevemk14ebr stevemk14ebr commented Jul 6, 2018

On windows if winnt.h is already included then all the defs in nt-headers collide and give > 100 errors. Here are the minimal windows changes needed to fix this. This will probably break linux, so probably best to do an ifdef on the platform being compiled. This was how i chose to fix it because i already use windows.h, there's probably a better option but that is up to you all.

Your build docs for windows should also not us DCMAKE flag instead use config

build all from command line:

cmake -G "Visual Studio 15 2017"
cmake --build . // for debug
cmake --build . --config Release // for release

if building from .sln then just use -G and set the config mode using visual studio gui.

@CLAassistant
Copy link

CLAassistant commented Jul 6, 2018

CLA assistant check
All committers have signed the CLA.

@alessandrogario
Copy link
Member

Hey @stevemk14ebr!
Thanks for signing the CLA! Before we merge though we have to have a look at the CI errors that Travis found

@ghost
Copy link

ghost commented Sep 11, 2018

@stevemk14ebr, all the constants that appear to be colliding are actually a part of the peparse namespace.

Since Linux doesn't have the Windows.h header file, pe-parse has to explicitly declare them somewhere.

Would you happen have a using namespace peparse; declared in your project? Removing that would likely fix the issue.

@woodruffw
Copy link
Member

Closing per @jacwil's advice.

@woodruffw woodruffw closed this Sep 21, 2018
@woodruffw
Copy link
Member

I think I closed this prematurely -- namespaces won't help with the macros introduced by Windows.h, and it looks like IMAGE_FILE_* are some of those macros.

@woodruffw woodruffw reopened this Oct 27, 2019
@woodruffw
Copy link
Member

Actually, closing since we don't want this approach. Will open a tracking issue.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

None yet

4 participants