Closed nowhey2 closed 2 years ago
I'm able to currently build the master branches sc_enum / sc_qtriggerinfo without changes. Yes those fields come from the windows headers
If I had to guess kali likely ships with an outdated version of mingw. Mine is listed below
The table on this page shows gcc -> mingw version mappings, with the mingw verison mapping making the difference for header includes https://www.mingw-w64.org/downloads/
Can you validate that the mingw version is 8.0 or newer, and if not we've found why it's not compiling on your system.
Using built-in specs.
COLLECT_GCC=x86_64-w64-mingw32-gcc
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-w64-mingw32/10-win32/lto-wrapper
Target: x86_64-w64-mingw32
Configured with: ../../src/configure --build=x86_64-linux-gnu --prefix=/usr --includedir='/usr/include' --mandir='/usr/share/man' --infodir='/usr/share/info' --sysconfdir=/etc --localstatedir=/var --disable-option-checking --disable-silent-rules --libdir='/usr/lib/x86_64-linux-gnu' --libexecdir='/usr/lib/x86_64-linux-gnu' --disable-maintainer-mode --disable-dependency-tracking --prefix=/usr --enable-shared --enable-static --disable-multilib --with-system-zlib --libexecdir=/usr/lib --without-included-gettext --libdir=/usr/lib --enable-libstdcxx-time=yes --with-tune=generic --with-headers --enable-version-specific-runtime-libs --enable-fully-dynamic-string --enable-libgomp --enable-languages=c,c++,fortran,objc,obj-c++,ada --enable-lto --enable-threads=win32 --program-suffix=-win32 --program-prefix=x86_64-w64-mingw32- --target=x86_64-w64-mingw32 --with-as=/usr/bin/x86_64-w64-mingw32-as --with-ld=/usr/bin/x86_64-w64-mingw32-ld --enable-libatomic --enable-libstdcxx-filesystem-ts=yes --enable-dependency-tracking SED=/bin/sed
Thread model: win32
Supported LTO compression algorithms: zlib
gcc version 10-win32 20220324 (GCC) ```
Package: mingw-w64
Version: 10.0.0-2
Priority: optional
Section: devel
Maintainer: Stephen Kitt <skitt@debian.org>
Installed-Size: 48.1 kB
Depends: gcc-mingw-w64, g++-mingw-w64
Homepage: http://mingw-w64.sf.net
Tag: devel::buildtools, role::metapackage
Download-Size: 13.9 kB
APT-Manual-Installed: yes
APT-Sources: http://http.kali.org/kali kali-rolling/main amd64 Packages
Description: Development environment targeting 32- and 64-bit Windows
MinGW-w64 provides a development and runtime environment for 32- and
64-bit (x86 and x64) Windows applications using the Windows API and
the GNU Compiler Collection (gcc).
.
This metapackage provides the MinGW-w64 development environment,
including C and C++ compilers. Ada, Fortran, Objective-C and
Objective-C++ compilers are available respectively in the
gnat-mingw-w64, gfortran-mingw-w64, gobjc-mingw-w64 and
gojbc++-mingw-w64 packages.
Went on a wild goose chase, but now I fully understand what's going on.
So yes actually your version of mingw is newer then mine and now defines SEVICE_CONFIG_TRIGGER_INFO as you stated, and it's mine that's older and does not.
I'll look into a better way to fix this, thanks for pointing it out!
I just pushed a fix, feel free to re-open if it doesn't work for you.
Thanks again!
TY!
In doing some syncs with your repo today, I noticed that these two modules were failing to build with the errors all originating with this one (using KALI with mingw):
So trying to troubleshoot (I prefer providing solutions rather than just complaining :) )...in sc_enum I wound up moving the
#endif
on line 35 to line 18 and it compiles fine after doing that. But in looking at the revision history of the file, I noticed that the#endif
has always been there like that. So I investigated where the setting was coming from (it wasn't anywhere in your code that I could find) and changed the beginning of sc_enum to:Which gave:
Which tells me its coming from the windows.h include. I don't know what changed or if that was always there in windows.h (I assume not b/c it worked just fine for a long time until just now). Regardless, SEVICE_CONFIG_TRIGGER_INFO is already defined from windows.h but the structs are not, leading to the error. I am not sure if the proper fix is to define the struct regardless (which is what moving the
#endif
basically did, or if there was some other checks that should be done instead and instead am chosing to report the issue to you as the author.