Menu
▾
▴
mingw-users
|
From: Jacob H. <sho...@gm...> - 2015-03-15 01:11:15
|
Hello! I am having quite a bit of trouble with Mingw, and hopefully someone can help me. About a week ago, I set out to build CEGUI 8.4 in Windows 7. I am using Mingw (with MSYS). I did the standard cmake configuration and generation of the necessary files, but the build failed. "make install" complained that _wfindnext64i32 was not declared in the scope. At first, I contacted the CEGUI team on the forum. I give a lot more detail there (cmake output and cache), and you can find it here: http://cegui.org.uk/forum/viewtopic.php?f=10&t=6988 . We also did a fair amount of checking files and messing around with the code. Now, they asked me to do a pull request and make some more minor changes to the code. It /kind of/ fixed my wfindnext error. The version I have now includes files that normally aren't for Windows (types.h, stat.h, dirent.h, and fnmatch.h). So the new issue here is that "fnmatch.h" doesn't exist. From what I remember, this isn't included in Mingw, but this project needs it at this point. The code and our detailed troubleshooting can be found at the pull request and the forum. Keep in mind that all of this is to fix the original problem, wfindnext. The PR is here: https://bitbucket.org/cegui/cegui/pull-request/147/crash-on-build/diff The CEGUI developer hasn't really got a clue on what is wrong, and neither do I. Any help or information that you can give would be appreciated. Additionally, if you want me to copy what we said in the forum and PR for any reason, just let me know and I will do it. Thank you in advance! Cheers, Jacob |
|
From: Eli Z. <el...@gn...> - 2015-03-15 17:38:14
|
> Date: Sat, 14 Mar 2015 21:11:09 -0400 > From: Jacob Hartmann <sho...@gm...> > > So the new issue here is that "fnmatch.h" doesn't exist. From what I remember, > this isn't included in Mingw, but this project needs it at this point. The code > and our detailed troubleshooting can be found at the pull request and the > forum. Keep in mind that all of this is to fix the original problem, wfindnext. > > The PR is here: > https://bitbucket.org/cegui/cegui/pull-request/147/crash-on-build/diff > > The CEGUI developer hasn't really got a clue on what is wrong, and neither do > I. Any help or information that you can give would be appreciated. > Additionally, if you want me to copy what we said in the forum and PR for any > reason, just let me know and I will do it. Thank you in advance! Not sure what you expect, exactly. MinGW lacks fnmatch.h and the functions/macros declared there. If you really need them, you will have to roll your own, or steal sources from some freely available library. Does that answer your question? |
|
From: Greg J. <gv...@gm...> - 2015-03-15 22:10:14
|
Here are some things I've been using. MSC_VER case is for visual C
and isn't set under mingw. _WIN32 is set for both, not for cygwin.
#ifndef _MSC_VER
# include <libgen.h>
# include <sys/types.h>
#endif
#include <sys/stat.h>
#ifndef _MSC_VER
# include <unistd.h>
#endif
#include <climits> // PATH_MAX
#ifndef _WIN32
# include <fnmatch.h>
# include <glob.h> // glob in MinGW ok for mingw >=3.21 11/2014
#endif
#ifdef _WIN32
# include <shlwapi.h>
# include <windows.h>
#endif
#ifndef _MSC_VER
# include <dirent.h>
-----------------8< --------------
then in the directory scan:
#ifdef _WIN32
MultiByteToWideChar(CP_UTF8, 0,
(LPCSTR)entryStr.c_str(), -1,
tchrentry, MAX_PATH+1);
int match = 1 - PathMatchSpecW(tchrentry, tchrpat);
#else
int match = fnmatch( pat.c_str(), entryStr.c_str(), 0);
#endif
On Sat, Mar 14, 2015 at 6:11 PM, Jacob Hartmann <sho...@gm...>
wrote:
> Hello! I am having quite a bit of trouble with Mingw, and hopefully
> someone can help me.
>
> About a week ago, I set out to build CEGUI 8.4 in Windows 7. I am using
> Mingw (with MSYS). I did the standard cmake configuration and generation of
> the necessary files, but the build failed. "make install" complained that
> _wfindnext64i32 was not declared in the scope.
>
> At first, I contacted the CEGUI team on the forum. I give a lot more
> detail there (cmake output and cache), and you can find it here:
> http://cegui.org.uk/forum/viewtopic.php?f=10&t=6988 . We also did a fair
> amount of checking files and messing around with the code. Now, they asked
> me to do a pull request and make some more minor changes to the code. It
> /kind of/ fixed my wfindnext error.
>
> The version I have now includes files that normally aren't for Windows
> (types.h, stat.h, dirent.h, and fnmatch.h).
>
> So the new issue here is that "fnmatch.h" doesn't exist. From what I
> remember, this isn't included in Mingw, but this project needs it at this
> point. The code and our detailed troubleshooting can be found at the pull
> request and the forum. Keep in mind that all of this is to fix the original
> problem, wfindnext.
>
> The PR is here:
> https://bitbucket.org/cegui/cegui/pull-request/147/crash-on-build/diff
>
> The CEGUI developer hasn't really got a clue on what is wrong, and neither
> do I. Any help or information that you can give would be appreciated.
> Additionally, if you want me to copy what we said in the forum and PR for
> any reason, just let me know and I will do it. Thank you in advance!
>
> Cheers,
> Jacob
>
>
>
>
> ------------------------------------------------------------------------------
> Dive into the World of Parallel Programming The Go Parallel Website,
> sponsored
> by Intel and developed in partnership with Slashdot Media, is your hub for
> all
> things parallel software development, from weekly thought leadership blogs
> to
> news, videos, case studies, tutorials and more. Take a look and join the
> conversation now. http://goparallel.sourceforge.net/
> _______________________________________________
> MinGW-users mailing list
> Min...@li...
>
> This list observes the Etiquette found at
> http://www.mingw.org/Mailing_Lists.
> We ask that you be polite and do the same. Disregard for the list
> etiquette may cause your account to be moderated.
>
> _______________________________________________
> You may change your MinGW Account Options or unsubscribe at:
> https://lists.sourceforge.net/lists/listinfo/mingw-users
> Also: mailto:min...@li...?subject=unsubscribe
>
|
|
From: Eli Z. <el...@gn...> - 2015-03-16 03:34:40
|
> Date: Sun, 15 Mar 2015 15:10:06 -0700 > From: Greg Jung <gv...@gm...> > > #ifdef _WIN32 > MultiByteToWideChar(CP_UTF8, 0, > (LPCSTR)entryStr.c_str(), -1, > tchrentry, MAX_PATH+1); > int match = 1 - PathMatchSpecW(tchrentry, tchrpat); > #else > int match = fnmatch( pat.c_str(), entryStr.c_str(), 0); > #endif This only supports Windows-style wildcards, Unix-style wildcards like "*.[ch]" won't be supported. Not sure if that matters for the application in question. |
|
From: Jacob H. <sho...@gm...> - 2015-03-16 18:09:35
|
On Sun, Mar 15, 2015 at 11:34 PM, Eli Zaretskii <el...@gn...> wrote: > > Date: Sun, 15 Mar 2015 15:10:06 -0700 > > From: Greg Jung <gv...@gm...> > > > > #ifdef _WIN32 > > MultiByteToWideChar(CP_UTF8, 0, > > (LPCSTR)entryStr.c_str(), -1, > > tchrentry, MAX_PATH+1); > > int match = 1 - PathMatchSpecW(tchrentry, tchrpat); > > #else > > int match = fnmatch( pat.c_str(), entryStr.c_str(), 0); > > #endif > > This only supports Windows-style wildcards, Unix-style wildcards like > "*.[ch]" won't be supported. Not sure if that matters for the > application in question. > > > ------------------------------------------------------------------------------ > Dive into the World of Parallel Programming The Go Parallel Website, > sponsored > by Intel and developed in partnership with Slashdot Media, is your hub for > all > things parallel software development, from weekly thought leadership blogs > to > news, videos, case studies, tutorials and more. Take a look and join the > conversation now. http://goparallel.sourceforge.net/ > _______________________________________________ > MinGW-users mailing list > Min...@li... > > This list observes the Etiquette found at > http://www.mingw.org/Mailing_Lists. > We ask that you be polite and do the same. Disregard for the list > etiquette may cause your account to be moderated. > > _______________________________________________ > You may change your MinGW Account Options or unsubscribe at: > https://lists.sourceforge.net/lists/listinfo/mingw-users > Also: mailto:min...@li...?subject=unsubscribe > Right, so I added the bit about MultiByteToWideChar, and added some of the includes that Greg had. Additionally, I reverted back to having it deal with the Windows bit, and ignoring what would compile on Linux. As a result, I am back to my original problem, which is this pesky error: DefaultResourceProvider.cpp:216:33: error: '_wfindnext64i32' was not declared in this scope |
|
From: Keith M. <kei...@us...> - 2015-03-16 21:57:17
|
On 16/03/15 18:09, Jacob Hartmann wrote: > I am back to my original problem, which is this pesky error: > > DefaultResourceProvider.cpp:216:33: error: '_wfindnext64i32' was not > declared in this scope _wfindfirst64i32() and _wfindnext64i32() first appeared in MSVCR80.DLL, and to this day, are firmly associated with this non-free MSVC DLL, and its descendants; they have never, at least up to Win7, never been added to the system-standard MSVCRT.DLL, upon which MinGW relies[*]. If you want your application to work with a standard MinGW setup, then you should not be explicitly referring to this, (or to any other variant), of _wfindnext(); you should use the generic form. Also, you need to be aware that, in MSVCRT.DLL, the generic form continues to use the __time32_t representation of time_t, (irrespective of the insanity of _USE_32BIT_TIME_T), whereas _wfindnext64i32() uses the __time64_t representation, (coupled with 32-bit file size). [*] Sure, it is *possible* to configure MinGW to work with MSVCR80.DLL and its later derivatives, but I am not going to encourage it. -- Regards, Keith. |
