Thank you!
When do you consider releasing 1.1 or something similar with new
improvements from trunk but stable?
On Thu, Jul 29, 2010 at 7:10 PM, Ozkan Sezer wrote:
>
> On Thu, Jul 29, 2010 at 6:54 PM, Ozkan Sezer wrote:
> > On Thu, Jul 29, 2010 at 6:32 PM, Alon Bar-Lev wrote:
> >> Hello,
> >>
On 7/30/2010 09:50, Dongsheng Song wrote:
> On Wed, Jul 28, 2010 at 21:42, JonY wrote:
>> On 7/28/2010 20:32, Dongsheng Song wrote:
>>>
>>> 于 2010-7-28 16:02, Kai Tietz 写道:
2010/7/28 Dongsheng Song:
>
> 于 2010-7-28 15:43, Kai Tietz 写道:
>>
>> 2010/7/28 Dongsheng Song:
On Fri, Jul 30, 2010 at 3:57 AM, Earnie wrote:
> NightStrike wrote:
>> On Thu, Jul 29, 2010 at 3:20 PM, Earnie wrote:
>>
>>> NightStrike wrote:
>>>
On a long term scale, it'd be nice to compile msys natively for
win64. That's a long way off, though.
>>> I have no way t
On Wed, Jul 28, 2010 at 21:42, JonY wrote:
> On 7/28/2010 20:32, Dongsheng Song wrote:
>>
>> 于 2010-7-28 16:02, Kai Tietz 写道:
>>>
>>> 2010/7/28 Dongsheng Song:
于 2010-7-28 15:43, Kai Tietz 写道:
>
> 2010/7/28 Dongsheng Song:
>>
>> Hi Kai,
>>
>> When we cross build g
It seems that Borland C++ defined ENOFILE, and MinGW add the alias of ENOENT.
On Thu, Jul 29, 2010 at 23:43, Ozkan Sezer wrote:
> On Thu, Jul 29, 2010 at 6:28 PM, Kai Tietz wrote:
>> 2010/7/29 Dongsheng Song :
>>> Thanks, when I build libassuan, I found ENOFILE not defined yet (within
>>> errno
On 7/30/2010 08:57, Luis Lavena wrote:
> On Thu, Jul 29, 2010 at 9:33 PM, JonY wrote:
>> On 7/30/2010 05:59, Luis Lavena wrote:
>>>
>>> Earnie: where specifically is uname source code? I can take a look to
>>> Windows API and since I have a x64 OS can check different results and
>>> let you know.
On Thu, Jul 29, 2010 at 9:33 PM, JonY wrote:
> On 7/30/2010 05:59, Luis Lavena wrote:
>>
>> Earnie: where specifically is uname source code? I can take a look to
>> Windows API and since I have a x64 OS can check different results and
>> let you know.
>>
>> If I can add proper identification of x8
On 7/29/2010 23:39, NightStrike wrote:
> On Tue, Jul 27, 2010 at 5:01 AM, JonY wrote:
>> On 7/27/2010 15:20, Dongsheng Song wrote:
>>> Hi Jonathan,
>>>
>>> Here is the patch:
>>>
>>> Index: Makefile.in
>>> ===
>>> --- Makefile.in(
On 7/30/2010 05:59, Luis Lavena wrote:
> On Thu, Jul 29, 2010 at 4:57 PM, Earnie wrote:
>> NightStrike wrote:
>>> On Thu, Jul 29, 2010 at 3:20 PM, Earnie
>>> wrote:
>>>
NightStrike wrote:
>On a long term scale, it'd be nice to compile msys natively for
>win64. That's
On Thu, Jul 29, 2010 at 4:57 PM, Earnie wrote:
> NightStrike wrote:
>> On Thu, Jul 29, 2010 at 3:20 PM, Earnie wrote:
>>
>>> NightStrike wrote:
>>>
On a long term scale, it'd be nice to compile msys natively for
win64. That's a long way off, though.
>>> I have no way t
NightStrike wrote:
> On Thu, Jul 29, 2010 at 3:20 PM, Earnie wrote:
>
>> NightStrike wrote:
>>
>>> On a long term scale, it'd be nice to compile msys natively for
>>> win64. That's a long way off, though.
>>>
>>>
>> I have no way to even begin to try it. First though one
On Thu, Jul 29, 2010 at 3:20 PM, Earnie wrote:
> NightStrike wrote:
>> On a long term scale, it'd be nice to compile msys natively for
>> win64. That's a long way off, though.
>>
>
> I have no way to even begin to try it. First though one would need to
> bootstrap GCC 64 bits with the MSYS
NightStrike wrote:
> On a long term scale, it'd be nice to compile msys natively for
> win64. That's a long way off, though.
>
I have no way to even begin to try it. First though one would need to
bootstrap GCC 64 bits with the MSYS runtime while at the same time
bootstrapping MSYS runtim
Luis Lavena wrote:
> On Thu, Jul 29, 2010 at 12:04 PM, Earnie wrote:
>
>> I don't have a 64 bit windows machine to test on. What does uname -m give
>> for the value?
>>
>>
> Windows 7 x64, using cmd.exe in 64bits mode (doesn't matter as sh is
> 32bits and triggers WOW)
>
> C:\Users\Luis
On Thu, Jul 29, 2010 at 3:11 PM, Earnie wrote:
> NightStrike wrote:
>> Again, the vendor tag is extremely important, and it cannot go away at
>> this time. There are 3 viable triplets for a reason:
>>
>> x86_64-w64-mingw*
>> i686-w64-mingw*
>> i686-pc-mingw*
>>
>>
> I can agree with this as long
NightStrike wrote:
> Again, the vendor tag is extremely important, and it cannot go away at
> this time. There are 3 viable triplets for a reason:
>
> x86_64-w64-mingw*
> i686-w64-mingw*
> i686-pc-mingw*
>
>
I can agree with this as long as the 32 goes away as you state could
easily be done i
Hello,
2010/7/29 NightStrike :
> On Thu, Jul 29, 2010 at 11:04 AM, Earnie wrote:
>> Luis Lavena wrote:
>>> On Wed, Jul 28, 2010 at 1:54 PM, Earnie
>>> wrote:
>>> The suggested target triplet for 64bits is x86_64-pc-mingw32
>>>
>>> Notice the "pc" part, which indicates vendor "pc" (mingw.org)
On Thu, Jul 29, 2010 at 6:54 PM, Ozkan Sezer wrote:
> On Thu, Jul 29, 2010 at 6:32 PM, Alon Bar-Lev wrote:
>> Hello,
>>
>> Is there any reason why we have pdh in 64bit but not for 32bit?
>
> I guess this is with v1.0 runtime and not from the trunk?
> If that is the case, the v1.0 branch still lac
On Thu, Jul 29, 2010 at 12:49 PM, NightStrike wrote:
>>
>> @NightStrike: 'windows' sounds good, but as mentioned above, will be
>> almost impossible to bring this now.
>
> I can dream, can't I? :)
>
Yes, sorry for that, didn't wanted to kill your dream :-)
>> The changes to implement just 'mingw
On Thu, Jul 29, 2010 at 6:32 PM, Alon Bar-Lev wrote:
> Hello,
>
> Is there any reason why we have pdh in 64bit but not for 32bit?
I guess this is with v1.0 runtime and not from the trunk?
If that is the case, the v1.0 branch still lacks mose import
libraries for 32 bit (because initially the proj
On Thu, Jul 29, 2010 at 11:44 AM, Luis Lavena wrote:
> Windows 7 x64, using cmd.exe in 64bits mode (doesn't matter as sh is
> 32bits and triggers WOW)
>
> C:\Users\Luis>sh -c "uname -m"
> i686
>
> C:\Users\Luis>sh -c "uname -p"
> unknown
>
> C:\Users\Luis>sh -c "uname -s"
> MINGW32_NT-6.1
>
> I th
On Thu, Jul 29, 2010 at 12:04 PM, Earnie wrote:
>
> Misinformation abounds and we cannot keep up with what others say. For
> instance from *-*-mingw32 the description adds "provides a subset of POSIX"
> which is simply false. We have never proclaimed to provide a subset of
> POSIX. We have proc
On Thu, Jul 29, 2010 at 6:28 PM, Kai Tietz wrote:
> 2010/7/29 Dongsheng Song :
>> Thanks, when I build libassuan, I found ENOFILE not defined yet (within
>> errno.h)
>>
>> #define ENOFILE 2 /* No such file or directory */
>> #define ENOENT 2
>>
>> When I add ENOFILE definit
Sorry I missed this. 1) You're very welcome. Feel free to idle in
our IRC channel to show support :) and.. 2) I hope your endeavor
worked out. If you have any other issues, don't hesitate to ask.
On Mon, May 31, 2010 at 10:53 PM, Rajdeep wrote:
> Hi,
>
> My ultimate goal is to port GSL to Pyt
On Tue, Jul 27, 2010 at 5:01 AM, JonY wrote:
> On 7/27/2010 15:20, Dongsheng Song wrote:
>> Hi Jonathan,
>>
>> Here is the patch:
>>
>> Index: Makefile.in
>> ===
>> --- Makefile.in (revision 2968)
>> +++ Makefile.in (working cop
Hello,
Is there any reason why we have pdh in 64bit but not for 32bit?
Thanks!
--
The Palm PDK Hot Apps Program offers developers who use the
Plug-In Development Kit to bring their C/C++ apps to Palm for a share
of $1 Mi
2010/7/29 Dongsheng Song :
> Thanks, when I build libassuan, I found ENOFILE not defined yet (within
> errno.h)
>
> #define ENOFILE 2 /* No such file or directory */
> #define ENOENT 2
>
> When I add ENOFILE definition, I can build GnuPG 2 success.
>
> I don't know whether E
On Thu, Jul 29, 2010 at 11:04 AM, Earnie wrote:
> Luis Lavena wrote:
>> On Wed, Jul 28, 2010 at 1:54 PM, Earnie
>> wrote:
>> The suggested target triplet for 64bits is x86_64-pc-mingw32
>>
>> Notice the "pc" part, which indicates vendor "pc" (mingw.org) vs.
>> w64 (mingw-w64 project).
>>
>
>
Thanks, when I build libassuan, I found ENOFILE not defined yet (within errno.h)
#define ENOFILE 2 /* No such file or directory */
#define ENOENT 2
When I add ENOFILE definition, I can build GnuPG 2 success.
I don't know whether ENOFILE should defined.
On Thu, Jul 29, 201
Luis Lavena wrote:
> On Wed, Jul 28, 2010 at 1:54 PM, Earnie
> wrote:
> >
> >>> My personal preference for a config.guess return string would
> >>> be x86_64-w64-mingw.
> >>>
> >>
> >> I believe this was already established as "x86_64-w64-mingw32" ?
> >>
> >
> > The problem with the -mingw32 her
2010/7/29 Dongsheng Song :
> Hi,
>
> When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
> mingw-w64 not supported,
> Is there any plan to support sigset_t in sys/types.h ?
>
> #ifndef _SIGSET_T_
> #define _SIGSET_T_
> typedef int _sigset_t;
>
> #ifndef _NO_OLDNAMES
> typedef
Hi,
When I compile GnuPG 2, I found w32pth[1] use data type sigset_t which
mingw-w64 not supported,
Is there any plan to support sigset_t in sys/types.h ?
#ifndef _SIGSET_T_
#define _SIGSET_T_
typedef int _sigset_t;
#ifndef _NO_OLDNAMES
typedef _sigset_t sigset_t;
#endif
#endif /* Not
32 matches
Mail list logo
