Re: [Mingw-w64-public] cannot execute binary file: Exec format error
On Sat, Oct 25, 2014 at 1:47 PM, Mark Cianfaglione
wrote:
> Hi
>
> I'm using MSYS2 and Mingw-w64 on a Windows 7 64 bit system and I've got
> a situation where I've compiles a program that uses GTK3 but I get a
> "cannot execute binary file: Exec format error" when I try to execute
> it.
>
> I thought perhaps that my makefile was borked so I made a simple "hello
> world" using gtk3 and compiled it with the makefile and it works.
>
> I have a couple of other libraries that I'm linking to (libxls, xlslib,
> mariadb) but the code compiles with no major issues (a few gtk
> deprecation warnings) but otherwise it compiles cleanly.
>
> No I do have several large arrays of structs that I've got as global
> variables but I've got the exact same code running on a Linux x86_64
> system without any issues.
>
> I'm compiling the code base (including the libxls and xlslib) on the
> same machine in the same manner. Only the mariadb dll is not. But I
> believe it's all in 64 bits. (is there a way of checking this?)
>
>From the MSYS2 shell enter
file /path/to/mariadb.dll
Have you tried using our GTK3 and mariadb packages (and/or PKGBUILDs)?
pacman -S mingw-w64-{x86_64,i686}-gtk3 mingw-w64-{x86_64,i686}-libmariadbclient
> What can cause the above error?
I really recommend building everything using the same (i.e. the MSYS2
provided) version of GCC and also using our packages where available.
Seems we don't have libxls/xlslib and would appreciate a contribution
of those:
https://sourceforge.net/p/msys2/wiki/Contributing%20to%20MSYS2/
>
> Any help would be appreciated.
>
> Mark
>
>
>
>
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] netioapi.h inconsistence
On 10/25/14, Alexey Pavlov wrote: > Hi! > > Some users report about inconsistency in netioapi header. They have > issues with using it on WinXP. See: > > https://github.com/Alexpux/MINGW-packages/issues/279 > > Regards, > Alexey. Looked at glib-2.42.0 source, its configury has a check for if_nametoindex (configure.ac line 1033), and gio/gsocket.c line 1932 creates its function only if HAVE_IF_NAMETOINDEX is not defined. It seems like the check doesn't seem to find the function, despite the fact that the header has its prototype and iphlpapi.def (both lib32 and lib64 versions) have the symbol. Seeing config.log may help why configury fails finding it. -- O.S. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] cannot execute binary file: Exec format error
Hi I'm using MSYS2 and Mingw-w64 on a Windows 7 64 bit system and I've got a situation where I've compiles a program that uses GTK3 but I get a "cannot execute binary file: Exec format error" when I try to execute it. I thought perhaps that my makefile was borked so I made a simple "hello world" using gtk3 and compiled it with the makefile and it works. I have a couple of other libraries that I'm linking to (libxls, xlslib, mariadb) but the code compiles with no major issues (a few gtk deprecation warnings) but otherwise it compiles cleanly. No I do have several large arrays of structs that I've got as global variables but I've got the exact same code running on a Linux x86_64 system without any issues. I'm compiling the code base (including the libxls and xlslib) on the same machine in the same manner. Only the mariadb dll is not. But I believe it's all in 64 bits. (is there a way of checking this?) What can cause the above error? Any help would be appreciated. Mark -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] netioapi.h inconsistence
Hi! Some users report about inconsistency in netioapi header. They have issues with using it on WinXP. See: https://github.com/Alexpux/MINGW-packages/issues/279 Regards, Alexey. -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Slow pseudo-relocations
2014-10-25 2:53 GMT+02:00 dw :
>
>> Ups, that was unintended to send an empty mail :)
>
> I did wonder. I assumed it was just a ping.
>
>> So, here is a patch.
>
> Your patch does not look right. You have added the new checks using "||"?
Hmm, might be a typo.
>> It would be great if somebody could verify that the reported
>> issue is solved by it.
>
> Yes, this is the hard part. Vadim seems to be able to produce this with
> no problem, but I'm having no luck getting it to happen at all.
>
> BTW, what is __MINGW64_VERSION_MAJOR for? Is there a time when it might
> not be defined in pseudo-reloc? If it is defined, we end up checking
> the page attributes twice.
This macro is for testing for mingw-w64's feature-set. So it should
be ok to test for it to verify that we use our startup. You might
want to combine it with an __MINGW32___ check, so that we are sure we
are using our headers/crt in context of native Windows, and not in
context of cygwin.
(you can check also for !defined (__CYGWIN__) if you prefer).
> FWIW, my patch (which I haven't been able to test either) looks like
> this (removes the duplicate check):
Yes, it is more per formant for sure. Please commit it, as Vladimir
tested it already.
Kai
> --- mingw-w64-crt/crt/pseudo-reloc.c
> ---
> index 4e7f31b..7709208 100644
> @@ -206,7 +206,8 @@ mark_section_writable (LPVOID addr)
> return;
> }
>
> - if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE)
> + if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE
> + && b.Protect != PAGE_EXECUTE_WRITECOPY && b.Protect !=
> PAGE_WRITECOPY)
> {
> if (!VirtualProtect (b.BaseAddress, b.RegionSize,
> PAGE_EXECUTE_READWRITE,
> @@ -259,16 +260,17 @@ restore_modified_sections (void)
> static void
> __write_memory (void *addr, const void *src, size_t len)
> {
> - MEMORY_BASIC_INFORMATION b;
> - DWORD oldprot;
> - int call_unprotect = 0;
> -
> if (!len)
> return;
>
> #ifdef __MINGW64_VERSION_MAJOR
So make out out if instead '#if defined (__MINGW64_VERSION_MAJOR) &&
defined (__MINGW32__)'
> + /* Mark the section writable once, and unset it in
> + * restore_modified_sections */
> mark_section_writable ((LPVOID) addr);
> -#endif
> +#else
> + MEMORY_BASIC_INFORMATION b;
> + DWORD oldprot = 0;
> + int call_unprotect = 0;
>
> if (!VirtualQuery (addr, &b, sizeof(b)))
> {
> @@ -277,18 +279,25 @@ __write_memory (void *addr, const void *src,
> size_t len)
> }
>
> /* Temporarily allow write access to read-only protected memory. */
> - if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE)
> + if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE
> + && b.Protect != PAGE_WRITECOPY && b.Protect !=
> PAGE_EXECUTE_WRITECOPY)
> {
> call_unprotect = 1;
> VirtualProtect (b.BaseAddress, b.RegionSize, PAGE_EXECUTE_READWRITE,
> &oldprot);
> }
> +#endif
>
> /* write the data. */
> memcpy (addr, src, len);
> +
> +#ifndef __MINGW64_VERSION_MAJOR
s.a.
> /* Restore original protection. */
> - if (call_unprotect && b.Protect != PAGE_EXECUTE_READWRITE &&
> b.Protect != PAGE_READWRITE)
> + if (call_unprotect
> + && b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE
> + && b.Protect != PAGE_WRITECOPY && b.Protect !=
> PAGE_EXECUTE_WRITECOPY)
> VirtualProtect (b.BaseAddress, b.RegionSize, oldprot, &oldprot);
> +#endif
> }
>
> #define RP_VERSION_V1 0
>
> --
>
>
>
> --
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Slow pseudo-relocations
So things are clear, dw please apply your patch. It is indeed better
to change flags - if possible - just once.
Thanks,
Kai
2014-10-25 6:01 GMT+02:00 Vadim Chugunov :
> I've tried both patches (fixed conditions in Kai's) and both eliminate
> extraneous calls to VirtualProtect. However Kai's patch did not seem to
> affect startup performance at all. DW's patch, on the other hand, also
> gets rid of VirtualQuery', and that cuts down the startup time of my test
> example by 40%.
> Thanks!
>
> Vadim
>
>
> On Fri, Oct 24, 2014 at 5:53 PM, dw wrote:
>>
>>
>> > Ups, that was unintended to send an empty mail :)
>>
>> I did wonder. I assumed it was just a ping.
>>
>> > So, here is a patch.
>>
>> Your patch does not look right. You have added the new checks using "||"?
>>
>> > It would be great if somebody could verify that the reported
>> > issue is solved by it.
>>
>> Yes, this is the hard part. Vadim seems to be able to produce this with
>> no problem, but I'm having no luck getting it to happen at all.
>>
>> BTW, what is __MINGW64_VERSION_MAJOR for? Is there a time when it might
>> not be defined in pseudo-reloc? If it is defined, we end up checking
>> the page attributes twice.
>>
>> FWIW, my patch (which I haven't been able to test either) looks like
>> this (removes the duplicate check):
>>
>> --- mingw-w64-crt/crt/pseudo-reloc.c
>> ---
>> index 4e7f31b..7709208 100644
>> @@ -206,7 +206,8 @@ mark_section_writable (LPVOID addr)
>> return;
>> }
>>
>> - if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE)
>> + if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE
>> + && b.Protect != PAGE_EXECUTE_WRITECOPY && b.Protect !=
>> PAGE_WRITECOPY)
>> {
>> if (!VirtualProtect (b.BaseAddress, b.RegionSize,
>> PAGE_EXECUTE_READWRITE,
>> @@ -259,16 +260,17 @@ restore_modified_sections (void)
>> static void
>> __write_memory (void *addr, const void *src, size_t len)
>> {
>> - MEMORY_BASIC_INFORMATION b;
>> - DWORD oldprot;
>> - int call_unprotect = 0;
>> -
>> if (!len)
>> return;
>>
>> #ifdef __MINGW64_VERSION_MAJOR
>> + /* Mark the section writable once, and unset it in
>> + * restore_modified_sections */
>> mark_section_writable ((LPVOID) addr);
>> -#endif
>> +#else
>> + MEMORY_BASIC_INFORMATION b;
>> + DWORD oldprot = 0;
>> + int call_unprotect = 0;
>>
>> if (!VirtualQuery (addr, &b, sizeof(b)))
>> {
>> @@ -277,18 +279,25 @@ __write_memory (void *addr, const void *src,
>> size_t len)
>> }
>>
>> /* Temporarily allow write access to read-only protected memory. */
>> - if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE)
>> + if (b.Protect != PAGE_EXECUTE_READWRITE && b.Protect != PAGE_READWRITE
>> + && b.Protect != PAGE_WRITECOPY && b.Protect !=
>> PAGE_EXECUTE_WRITECOPY)
>> {
>> call_unprotect = 1;
>> VirtualProtect (b.BaseAddress, b.RegionSize,
>> PAGE_EXECUTE_READWRITE,
>> &oldprot);
>> }
>> +#endif
>>
>> /* write the data. */
>> memcpy (addr, src, len);
>> +
>> +#ifndef __MINGW64_VERSION_MAJOR
>> /* Restore original protection. */
>> - if (call_unprotect && b.Protect != PAGE_EXECUTE_READWRITE &&
>> b.Protect != PAGE_READWRITE)
>> + if (call_unprotect
>> + && b.Protect != PAGE_EXECUTE_READWRITE && b.Protect !=
>> PAGE_READWRITE
>> + && b.Protect != PAGE_WRITECOPY && b.Protect !=
>> PAGE_EXECUTE_WRITECOPY)
>> VirtualProtect (b.BaseAddress, b.RegionSize, oldprot, &oldprot);
>> +#endif
>> }
>>
>> #define RP_VERSION_V1 0
>>
>>
>> --
>>
>>
>>
>>
>> --
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> --
>
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
