search for: image_file_machine_unknown

Right now, we have: In COFF.h: class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; In windows.h: #define IMAGE_FILE_MACHINE_UNKNOWN 0 * If you first include COFF.h and then windows.h, COFF::IMAGE_FILE_MACHINE_UNKNOWN will be preprocessed into COFF:0. * If you first include Windows.h and then COFF.h, COFF.h won't work because it's enum will...

On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first include Windows.h and then COFF.h, COF...

...fter including Windows.h. On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> > wrote: > > Right now, we have: > In COFF.h: > class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, > ... }; }; > In windows.h: > #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > * If you first include COFF.h and then windows.h, > COFF::IMAGE_FILE_MACHINE_UNKNOWN > will be preprocessed into > COFF:0. > > * If you first include Windows.h and then COFF.h,...

Hello, I noticed that if include\llvm\Support is included alongside Windows.h, there will be many define conflict leading to compilation errors, such as: COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; and winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 Of course I could try to avoid to include both (but it's rather difficult and would require lot of refactoring -- we have this clash currently in LLDB MinGW32 port). I was wondering if instead it was possible...

...gile Bello <virgile.bello at gmail.com>wrote: > >> Hello, >> >> I noticed that if include\llvm\Support is included alongside Windows.h, >> there will be many define conflict leading to compilation errors, such as: >> >> COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, >> ... }; >> >> and >> >> winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> Of course I could try to avoid to include both (but it's rather difficult >> and would require lot of refactoring -- we have this clash curren...

...ndows.h. > > > On Thu, Aug 29, 2013 at 11:08 AM, Nick Kledzik <kledzik at apple.com> wrote: > > On Aug 28, 2013, at 7:05 PM, Virgile Bello <virgile.bello at gmail.com> wrote: >> Right now, we have: >> In COFF.h: >> class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; >> In windows.h: >> #define IMAGE_FILE_MACHINE_UNKNOWN 0 >> >> * If you first include COFF.h and then windows.h, >> COFF::IMAGE_FILE_MACHINE_UNKNOWN >> will be preprocessed into >> COFF:0. >> >> * If you first in...

...ug 29, 2013 at 11:08 AM, Nick Kledzik<kledzik at apple.com> wrote: >> >> On Aug 28, 2013, at 7:05 PM, Virgile Bello<virgile.bello at gmail.com> wrote: >> >>> Right now, we have: >>> In COFF.h: >>> class COFF { enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... }; }; >>> In windows.h: >>> #define IMAGE_FILE_MACHINE_UNKNOWN 0 >>> >>> * If you first include COFF.h and then windows.h, >>> COFF::IMAGE_FILE_MACHINE_UNKNOWN >>> will be preprocessed into >>> COFF:0. >&g...

...Aug 27, 2013 at 5:41 PM, Virgile Bello <virgile.bello at gmail.com>wrote: > Hello, > > I noticed that if include\llvm\Support is included alongside Windows.h, > there will be many define conflict leading to compilation errors, such as: > > COFF.h (enum): enum MachineTypes { IMAGE_FILE_MACHINE_UNKNOWN = 0x0, ... > }; > > and > > winnt.h (same but define): #define IMAGE_FILE_MACHINE_UNKNOWN 0 > > Of course I could try to avoid to include both (but it's rather difficult > and would require lot of refactoring -- we have this clash currently in > LLDB MinGW32 port)....

On Aug 27, 2013, at 5:56 PM, Virgile Bello <virgile.bello at gmail.com> wrote: > Yes of course I understand it was done on purpose. > It's just that it makes it impossible to include COFF.h and Windows.h side by side (which probably wasn't necessary until now). I too am in the camp that it is a feature to use the standard names. For instance doing a search it google or

...;& Private == E.Private); } }; enum class DebugType { None = 0x0, CV = 0x1, /// CodeView PData = 0x2, /// Procedure Data Fixup = 0x4, /// Relocation Table }; struct Configuration { enum ManifestKind { SideBySide, Embed, No }; llvm::COFF::MachineTypes Machine = llvm::COFF::IMAGE_FILE_MACHINE_UNKNOWN; bool Verbose = false; llvm::COFF::WindowsSubsystem Subsystem = llvm::COFF::IMAGE_SUBSYSTEM_UNKNOWN; SymbolBody *Entry = nullptr; bool NoEntry = false; std::string OutputFile; bool DoGC = true; bool DoICF = true; bool Relocatable = true; bool Force = false; bool Debug = false;...