Re: [Mingw-w64-public] Using MinGW-w64
On 12/5/2013 12:58, wynfield wrote: > # I then tried to compile it, but it failed as soon below. > > $ /bin/i686-w64-mingw32-gcc.exe hello.c >i686-w64-mingw32-gcc: error: spawn: No such file or directory > > Don't do that, just use i686-w64-mingw32-gcc, or /usr/bin/i686-w64-mingw32-gcc, but not /bin/i686-w64-mingw32-gcc. signature.asc Description: OpenPGP digital signature -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [patch winuser.h]: Windows 8 API ... winapi-family ... sorting out some strange stuff
Hi, thanks for the review. 2013/12/4 JonY : > On 12/5/2013 04:17, Kai Tietz wrote: >> Hi, >> >> could somebody of you please review http://pastebin.com/w91sSRk0 >> >> Thanks, >> Kai >> > > Is this correct? CONST to const > > -POINT CONST *pptDst; > -SIZE CONST *psize; > +const POINT *pptDst; > +const SIZE *psize; > > What is this part about? Nothing special. In general is the way of writing 'const ' to be preferred over the form of ' const'. This is a clarification. > - WINUSERAPI WINBOOL WINAPI UpdateLayeredWindowIndirect(HWND > hWnd,UPDATELAYEREDWINDOWINFO CONST *pULWInfo); > +#if _WIN32_WINNT < 0x0502 > + typedef > +#endif > + WINUSERAPI WINBOOL WINAPI UpdateLayeredWindowIndirect (HWND hWnd, const > UPDATELAYEREDWINDOWINFO *pULWInfo); > +#endif > +#endif WINVER? In the line above I see _WIN32_WINNT here ... well, the use of those both makros is a mix ... I used those referenced, but I agree that I didn't found a good master plan, when MS uses which one. Well, WINVER is defined by some headers itself as default, but _WIN32_WIN32 is just defined in the sdk-headers ... > Suddenly WINVER? I also see a lot of changes initially to put #if inside > brackets, > why stop there? The brackets are superflous. So I removed them from lines, which I touched. We don't write Lisp ;) > +#if WINVER >= 0x0600 > + WINUSERAPI WINBOOL WINAPI AddClipboardFormatListener (HWND hwnd); > + WINUSERAPI WINBOOL WINAPI RemoveClipboardFormatListener (HWND hwnd); > + WINUSERAPI WINBOOL WINAPI GetUpdatedClipboardFormats (PUINT lpuiFormats, > UINT cFormats, PUINT pcFormatsOut); > #endif > +#endif > > These kind of mean differently They are right AFAICS. What's the comment here about? Those clipboard-functions are available beginning from Vista. > -#if (_WIN32_WINNT < 0x0600) > -#define SM_CMETRICS 90 > +#if WINVER <= 0x501 > +#define SM_CMETRICS 91 > +#elif WINVER == 0x600 > +#define SM_CMETRICS 93 > +#else > +#define SM_CMETRICS 97 > #endif This is actual a bug fix. We handled that wrong in the past. See code above it to see the obvious cause for this change. > CreateDesktopA/W removed?? > > -WINUSERAPI HDESK WINAPI CreateDesktopExA( > - LPCSTR lpszDesktop, > - LPCSTR lpszDevice, > - DEVMODE *pDevmode, > - DWORD dwFlags, > - ACCESS_MASK dwDesiredAccess, > - LPSECURITY_ATTRIBUTES lpsa, > - ULONG ulHeapSize, > - PVOID pvoid > -); It isn't removed, just moved to different place in header. As I wrote, I corected, consolidated, and verified header. You can find CreateDesktopA/W next to its extended variant, next to the other ...Desktop functions. Cheers, Kai -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Learning to use MinGW-w64
>From: JonY
>Date: Thu, 05 Dec 2013 17:23:48 +0800
>Subject: Re: [Mingw-w64-public] Using MinGW-w64
>On 12/5/2013 12:58, wynfield wrote:
>> # I then tried to compile it, but it failed as soon below.
>>
>> $ /bin/i686-w64-mingw32-gcc.exe hello.c
>>i686-w64-mingw32-gcc: error: spawn: No such file or directory
>>
>>
>Don't do that, just use i686-w64-mingw32-gcc, or
>/usr/bin/i686-w64-mingw32-gcc, but not /bin/i686-w64-mingw32-gcc.
I followed JonY's instruction and invoked the compiler simply as
i686-w64-mingw32-gcc.
I does get to the compiler now. Thank you.
Next I'm getting a linking error as follows from this example code on MinGW-w64
site.
#define _UNICODE
#define UNICODE
#include
int _tmain(int argc, _TCHAR **argv)
{
_tprintf(__T("Hello\n"));
return 0;
}
Note: I am assuming the example given is oomplete and that covers
what
normal stdio.h and stdlib.h do.
$ i686-w64-mingw32-gcc hello.c
/usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
In function `main':
/usr/src/debug/mingw64-i686-runtime-3.0.0-1/crt/crt0_c.c:18: undefined
reference to `WinMain@16'
collect2: error: ld returned 1 exit status
[ undefined reference to `WinMain@16' ]
Advice on solving this is appreciated.
Thank you.
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Learning to use MinGW-w64
I am not sure what is the status now, but couple of years ago, GCC could
not compile programs with UNICODE version of WinMain. If it still
persist, you will need to declare the entry point as
int main(int argc, char **argv)
You can get the UNICODE command line arguments later by calling
GetCommandLine API.
Pavel
On Thu, 2013-12-05 at 22:41 +0900, wynfi...@gmail.com wrote:
>
> >From: JonY
> >Date: Thu, 05 Dec 2013 17:23:48 +0800
> >Subject: Re: [Mingw-w64-public] Using MinGW-w64
> >On 12/5/2013 12:58, wynfield wrote:
> >> # I then tried to compile it, but it failed as soon below.
> >>
> >> $ /bin/i686-w64-mingw32-gcc.exe hello.c
> >>i686-w64-mingw32-gcc: error: spawn: No such file or directory
> >>
> >>
> >Don't do that, just use i686-w64-mingw32-gcc, or
> >/usr/bin/i686-w64-mingw32-gcc, but not /bin/i686-w64-mingw32-gcc.
>
>
> I followed JonY's instruction and invoked the compiler simply as
> i686-w64-mingw32-gcc.
> I does get to the compiler now. Thank you.
>
> Next I'm getting a linking error as follows from this example code on
> MinGW-w64 site.
>
>
> #define _UNICODE
> #define UNICODE
>
> #include
>
> int _tmain(int argc, _TCHAR **argv)
> {
> _tprintf(__T("Hello\n"));
> return 0;
> }
>
> Note: I am assuming the example given is oomplete and that covers
> what
> normal stdio.h and stdlib.h do.
>
>
> $ i686-w64-mingw32-gcc hello.c
>
> /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
> In function `main':
> /usr/src/debug/mingw64-i686-runtime-3.0.0-1/crt/crt0_c.c:18: undefined
> reference to `WinMain@16'
> collect2: error: ld returned 1 exit status
>
>
> [ undefined reference to `WinMain@16' ]
>
>
> Advice on solving this is appreciated.
> Thank you.
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Learning to use MinGW-w64
2013/12/5 Pavel
> I am not sure what is the status now, but couple of years ago, GCC could
> not compile programs with UNICODE version of WinMain. If it still
> persist, you will need to declare the entry point as
>
> int main(int argc, char **argv)
>
> You can get the UNICODE command line arguments later by calling
> GetCommandLine API.
>
MinGW-w64 GCC supports the -municode switch, which I believe is what is
needed here:
> i686-w64-mingw32-gcc hello.c -municode
But I can't test this right now.
Anyways, using _tmain and the whole TCHAR business is silly. Don't use it
in any real code, please. Instead either use char encoded as UTF-8
internally, converting when you call the Windows API, or use wchar_t
directly. Just my 2c ;-)
Ruben
> Pavel
>
> On Thu, 2013-12-05 at 22:41 +0900, wynfi...@gmail.com wrote:
> >
> > >From: JonY
> > >Date: Thu, 05 Dec 2013 17:23:48 +0800
> > >Subject: Re: [Mingw-w64-public] Using MinGW-w64
> > >On 12/5/2013 12:58, wynfield wrote:
> > >> # I then tried to compile it, but it failed as soon below.
> > >>
> > >> $ /bin/i686-w64-mingw32-gcc.exe hello.c
> > >>i686-w64-mingw32-gcc: error: spawn: No such file or directory
> > >>
> > >>
> > >Don't do that, just use i686-w64-mingw32-gcc, or
> > >/usr/bin/i686-w64-mingw32-gcc, but not /bin/i686-w64-mingw32-gcc.
> >
> >
> > I followed JonY's instruction and invoked the compiler simply as
> i686-w64-mingw32-gcc.
> > I does get to the compiler now. Thank you.
> >
> > Next I'm getting a linking error as follows from this example code on
> MinGW-w64 site.
> >
> >
> > #define _UNICODE
> > #define UNICODE
> >
> > #include
> >
> > int _tmain(int argc, _TCHAR **argv)
> > {
> > _tprintf(__T("Hello\n"));
> > return 0;
> > }
> >
> > Note: I am assuming the example given is oomplete and that
> covers what
> > normal stdio.h and stdlib.h do.
> >
> >
> > $ i686-w64-mingw32-gcc hello.c
> >
> >
> /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
> In function `main':
> > /usr/src/debug/mingw64-i686-runtime-3.0.0-1/crt/crt0_c.c:18: undefined
> reference to `WinMain@16'
> > collect2: error: ld returned 1 exit status
> >
> >
> > [ undefined reference to `WinMain@16' ]
> >
> >
> > Advice on solving this is appreciated.
> > Thank you.
> >
> >
> --
> > Sponsored by Intel(R) XDK
> > Develop, test and display web and hybrid apps with a single code base.
> > Download it for free now!
> >
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> > ___
> > Mingw-w64-public mailing list
> > Mingw-w64-public@lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
>
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Learning to use MinGW-w64
I believe it is possible, but you have to explicitly tell it with the gcc
option -municode.
Martin
> I am not sure what is the status now, but couple of years ago, GCC could
> not compile programs with UNICODE version of WinMain. If it still
> persist, you will need to declare the entry point as
>
> int main(int argc, char **argv)
>
> You can get the UNICODE command line arguments later by calling
> GetCommandLine API.
>
> Pavel
>
> On Thu, 2013-12-05 at 22:41 +0900, wynfi...@gmail.com wrote:
>>
>> >From: JonY
>> >Date: Thu, 05 Dec 2013 17:23:48 +0800
>> >Subject: Re: [Mingw-w64-public] Using MinGW-w64
>> >On 12/5/2013 12:58, wynfield wrote:
>> >> # I then tried to compile it, but it failed as soon below.
>> >>
>> >> $ /bin/i686-w64-mingw32-gcc.exe hello.c
>> >>i686-w64-mingw32-gcc: error: spawn: No such file or directory
>> >>
>> >>
>> >Don't do that, just use i686-w64-mingw32-gcc, or
>> >/usr/bin/i686-w64-mingw32-gcc, but not /bin/i686-w64-mingw32-gcc.
>>
>>
>> I followed JonY's instruction and invoked the compiler simply as
>> i686-w64-mingw32-gcc.
>> I does get to the compiler now. Thank you.
>>
>> Next I'm getting a linking error as follows from this example code on
>> MinGW-w64 site.
>>
>>
>> #define _UNICODE
>> #define UNICODE
>>
>> #include
>>
>> int _tmain(int argc, _TCHAR **argv)
>> {
>> _tprintf(__T("Hello\n"));
>> return 0;
>> }
>>
>> Note: I am assuming the example given is oomplete and that
>> covers what
>> normal stdio.h and stdlib.h do.
>>
>>
>> $ i686-w64-mingw32-gcc hello.c
>>
>> /usr/i686-w64-mingw32/sys-root/mingw/lib/../lib/libmingw32.a(lib32_libmingw32_a-crt0_c.o):
>> In function `main':
>> /usr/src/debug/mingw64-i686-runtime-3.0.0-1/crt/crt0_c.c:18: undefined
>> reference to `WinMain@16'
>> collect2: error: ld returned 1 exit status
>>
>>
>> [ undefined reference to `WinMain@16' ]
>>
>>
>> Advice on solving this is appreciated.
>> Thank you.
>>
>> --
>> Sponsored by Intel(R) XDK
>> Develop, test and display web and hybrid apps with a single code base.
>> Download it for free now!
>> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
>> ___
>> Mingw-w64-public mailing list
>> Mingw-w64-public@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
>
>
> --
> Sponsored by Intel(R) XDK
> Develop, test and display web and hybrid apps with a single code base.
> Download it for free now!
> http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Sponsored by Intel(R) XDK
Develop, test and display web and hybrid apps with a single code base.
Download it for free now!
http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [patch winnt.h]: Adjust DECLSPEC_DEPRECATED for widl
Hi, following patch makes sure that DECLSPEC_DEPRECATED isn't defined to declspec for widl-mode. Also it undefines DEPRECATE_SUPPORTED macro in widl-mode. Ok for apply? Kai Index: winnt.h === --- winnt.h (Revision 6390) +++ winnt.h (Arbeitskopie) @@ -226,9 +226,14 @@ #endif /* FORCEINLINE */ #ifndef DECLSPEC_DEPRECATED +#if !defined (__WIDL__) #define DECLSPEC_DEPRECATED __declspec(deprecated) #define DEPRECATE_SUPPORTED +#else +#define DECLSPEC_DEPRECATED +#undef DEPRECATE_SUPPORTED #endif +#endif #define DECLSPEC_DEPRECATED_DDK #define PRAGMA_DEPRECATED_DDK 0 -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain
I came up with a patch that fixes the issue for me. The patch replaces the global critical section with a spinlock. Critical sections require explicit initialization before use, which in this case is not possible: register_frame_ctor (from libgcc), which runs BEFORE enter_global_cs, tries to lock a mutex, which requires a spinlock, which needs to be initialized in static_spin_init, which tries to enter the global critical section, which is not initialized. The result is a segfault somewhere in ntdll. register_frame_ctor has constructor priority of 0, so setting the priority of global_spin_ctor wouldn't cut it. I'm not sure what is the official way to send patches, so I'm posting it here. spinlock-remove-ctor.patch Description: Binary data -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain
2013/12/5 Fanael Linithien : > I came up with a patch that fixes the issue for me. > > The patch replaces the global critical section with a spinlock. > Critical sections require explicit initialization before use, which in > this case is not possible: register_frame_ctor (from libgcc), which > runs BEFORE enter_global_cs, tries to lock a mutex, which requires a > spinlock, which needs to be initialized in static_spin_init, which > tries to enter the global critical section, which is not initialized. > The result is a segfault somewhere in ntdll. > > register_frame_ctor has constructor priority of 0, so setting the > priority of global_spin_ctor wouldn't cut it. > > > I'm not sure what is the official way to send patches, so I'm posting it here. Nice catch. This describes at least the runtime-failure we got reported. Did you tested regressions for this patch? The only thing about using memory-based spinlocking is that we might introduce race-condtion. So we should at least verify for this. Kai -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Winpthreads library issue with dwarf toolchain
A few thoughts: 1) Shouldn't global_lock be __LONG32? 2) Would it make sense for the exchange on global_lock to be done as a single operation (ie InterlockedCompareExchange)? dw On 12/5/2013 10:45 AM, Fanael Linithien wrote: I came up with a patch that fixes the issue for me. The patch replaces the global critical section with a spinlock. Critical sections require explicit initialization before use, which in this case is not possible: register_frame_ctor (from libgcc), which runs BEFORE enter_global_cs, tries to lock a mutex, which requires a spinlock, which needs to be initialized in static_spin_init, which tries to enter the global critical section, which is not initialized. The result is a segfault somewhere in ntdll. register_frame_ctor has constructor priority of 0, so setting the priority of global_spin_ctor wouldn't cut it. I'm not sure what is the official way to send patches, so I'm posting it here. -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Behavior
I understand that on cygwin /bin and /usr/bin both point to the same directory. Given that and that the ming2-w64 gcc program is shown to be the exact same length and have the same md5sums, I assumed that they were all equal. -rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc -rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc.exe -rwxr-xr-x 2 692765 Dec 1 /usr/bin/i686-w64-mingw32-gcc -rwxr-xr-x 2 692765 Dec 1 /usr/bin/i686-w64-mingw32-gcc.exe But the gcc in /usr/bin/ works nand the one in /bin does not. What magic causes the different behavior? -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Behavior
06 дек. 2013 г., в 8:48, wynfi...@gmail.com написал(а): > > I understand that on cygwin /bin and /usr/bin both point to the same > directory. No. On cygwin this is two different directories. They are the same on MSYS. Regards, Alexey. > Given that and that the ming2-w64 gcc program is shown to be the exact same > length and have the same md5sums, I assumed that they were all equal. > > -rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc > -rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc.exe > -rwxr-xr-x 2 692765 Dec 1 /usr/bin/i686-w64-mingw32-gcc > -rwxr-xr-x 2 692765 Dec 1 /usr/bin/i686-w64-mingw32-gcc.exe > > But the gcc in /usr/bin/ works nand the one in /bin does not. > > What magic causes the different behavior? > > -- > Sponsored by Intel(R) XDK > Develop, test and display web and hybrid apps with a single code base. > Download it for free now! > http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Behavior
On 2013-12-05 22:48, wynfield wrote: > I understand that on cygwin /bin and /usr/bin both point to the same > directory. Correct. > Given that and that the ming2-w64 gcc program is shown to be the exact same > length and have the same md5sums, I assumed that they were all equal. > > -rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc > -rwxr-xr-x 2 692765 Dec 1 /bin/i686-w64-mingw32-gcc.exe > -rwxr-xr-x 2 692765 Dec 1 /usr/bin/i686-w64-mingw32-gcc > -rwxr-xr-x 2 692765 Dec 1 /usr/bin/i686-w64-mingw32-gcc.exe > > But the gcc in /usr/bin/ works nand the one in /bin does not. > What magic causes the different behavior? These frontends call to the backends (cc1, etc. in $libexecdir) relative to themselves (e.g. ../libexec/gcc/$target/$version/cc1). The problem with using /bin/$target-gcc is that there is no /libexec directory, just a /usr/libexec. If gcc is configured with --libexecdir=/usr/lib (as it was previously), then this is not an issue, as /lib == /usr/lib as well. But where are you seeing gcc referenced under /bin instead of /usr/bin? Yaakov Cygwin Ports -- Sponsored by Intel(R) XDK Develop, test and display web and hybrid apps with a single code base. Download it for free now! http://pubads.g.doubleclick.net/gampad/clk?id=111408631&iu=/4140/ostg.clktrk ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
