Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c
On 7/30/10 7:53 PM, Chris Sutcliffe wrote: > I just tried with the latest Cygwin snapshot (20100726): > > $ x86_64-w64-mingw32-dllwrap.exe --version > GNU x86_64-w64-mingw32-dllwrap (GNU Binutils) 2.20.51.20100726 > Copyright 2010 Free Software Foundation, Inc. > This program is free software; you may redistribute it under the terms of > the GNU General Public License version 3 or (at your option) any later > version. > This program has absolutely no warranty. > > I am still getting the same results. Is there something I'm missing? Doing a little more digging, it seems like it's not dllwrap at all, it's gcc: x86_64-w64-mingw32-gcc -Wl,--enable-stdcall-fixup -ozip32z64.dll -s -shared windll.o windllrc.o api.o zipl.o cryptl.o ttyiol.o zipfilel.o zipupl.o fileiol.o utill.o crc32l.o globalsl.o deflatel.o treesl.o zbz2errl.o win32l.o win32zpl.o win32i64l.o ntl.o -luser32 -ladvapi32 zipfilel.o:zipfile.c:(.text+0x15b1): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x508): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x59a): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x5b7): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x61b): undefined reference to `__p___mb_cur_max' fileiol.o:fileio.c:(.text+0x64c): more undefined references to `__p___mb_cur_max' follow Yet as previously mentioned, mb_cur_max is exported my libmsvcrt.a. I'm stumped. Chris -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
On Fri, Jul 30, 2010 at 10:50 AM, Chiheng Xu wrote: > > Is 64-bits MSYS or Cygwin necessary? > > MSYS may be not necessary at all. > > If Cygwin merge the changes done in MSYS, and provide a Win32_Path > mode(translating all Unix paths to Win32 paths at fork/exec or spawn) > and MinGW transform itself to use binary mode(linking with binmode.o > instead of txtmode.o) and slightly patch uname.exe in coreutils, > Cygwin has the potential to replace MSYS and provide many tools > missing in MSYS, like tcl/tk, expect, dejagnu necessary for the > testing of GCC/GDB/BINUTILS. > What I want to say is that, transform Cygwin to be universal POSIX command line environment for Windows. Cygwin's default mode is "Unix path mode", so it can't not launch native Win32 executable(like MinGW gcc) that require paths in their argv[] to be Win32 path. So Cygwin need to provide an optional "Win32 path mode", like MSYS do. But ordinary Win32 executable is linked with txtmode.o, which is not compatible with Cygwin's binary mode. So MinGW also need slightly transform itself to linked with binmode.o. Cygwin has an CYGWIN environment variable, can set the mode of cygwin1.dll . I believe Cygwin maintainer will accept to add an "Win32 path mode". -- Chiheng Xu Wuhan,China -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Issues compiling Info-zip's zip 3.1c
Hi Kai, On 7/16/10 8:42 AM, Kai Tietz wrote: > Hello Chris, > >> I'm trying to compile Info-zip's zip 3.1c during the linking stage of >> the 'dll' target. The command I use to build the dll is: >> >> make -f win32/makefile.gcc CC=x86_64-w64-mingw32-gcc >> RC=x86_64-w64-mingw32-windres NOASM=1 dll >> >> which compiles the object files fine, however, when linking: >> >> zipfilel.o:zipfile.c:(.text+0x15b1): undefined reference to >> `__p___mb_cur_max' >> fileiol.o:fileio.c:(.text+0x508): undefined reference to `__p___mb_cur_max' >> fileiol.o:fileio.c:(.text+0x59a): undefined reference to `__p___mb_cur_max' >> fileiol.o:fileio.c:(.text+0x5b7): undefined reference to `__p___mb_cur_max' >> fileiol.o:fileio.c:(.text+0x61b): undefined reference to `__p___mb_cur_max' >> fileiol.o:fileio.c:(.text+0x64c): more undefined references to >> `__p___mb_cur_max' follow >> >> which confuses me, given that mb_cur_max is exported by many libraries: >> >> $ grep -ri mb_cur_max * >> Binary file libcrtdll.a matches >> Binary file libmingwex.a matches >> Binary file libmsvcr80.a matches >> Binary file libmsvcrt.a matches >> Binary file libwcrtdll.a matches >> Binary file libwmsvcrt.a matches >> Binary file libwmsvcrt20.a matches >> Binary file libwmsvcrt40.a matches > This issue is caused by a recent fixed bug in binutils' dllwrap tool. > Please use a new binutils version (head) version. Then your problem > should be solved. I just tried with the latest Cygwin snapshot (20100726): $ x86_64-w64-mingw32-dllwrap.exe --version GNU x86_64-w64-mingw32-dllwrap (GNU Binutils) 2.20.51.20100726 Copyright 2010 Free Software Foundation, Inc. This program is free software; you may redistribute it under the terms of the GNU General Public License version 3 or (at your option) any later version. This program has absolutely no warranty. I am still getting the same results. Is there something I'm missing? Thank you, Chris -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
On Fri, Jul 30, 2010 at 8:35 AM, Earnie wrote: > Instructions have been provided for building MSYS runtime dependent > applications in the mingw.org wiki. I understand why you might want > expect and dejagnu to be available. But are you going to be able to > test a 64bit version of GCC with a 32bit version of expect and dejagnu? Right now, we test it in 32-bit cygwin. So, yes. -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Custom toolchain build with gcc-4.4.5 (2010-07-11)
On Sun, Jul 11, 2010 at 10:06 PM, Ozkan Sezer wrote: > I updated my custom w32/w64 native and cross-compiler build with gcc-4.4 > with several backports and fixes from mainstream, and put them under the > mingw-w64 sf.net file release system under the subdirectories: > - Toolchain sources -> Personal Builds, > - Toolchains targetting Win32 -> Personal Builds and > - Toolchains targetting Win64 -> Personal Builds > I uploaded runtime + header updates for these builds: sezero_20100711_w32_runtime_update_3045.zip (for w32 targets) sezero_20100711_w64_runtime_update_3045.zip (for w64 targets) ... upgrading the mingw-w64 revision to 3045: Several header fixes and added GUIDs. Dependencies for the DDK headers added. A few 32 bit import library fixes. Change into your toolchain directory, then unzip the update package allow overwriting old files. If one needs to use ddk headers with this, take this: http://mingw-w64.svn.sourceforge.net/viewvc/mingw-w64/experimental/ddk_test/include/ddk/ ... which is a local copy of the r/os ddk headers rev. 48300. -- Ozkan PS: dllwrap users for win64 targets: Remember to use the sezero_20100711_w64_dllwrap_update.zip update package for correct dllwrap operation. > Build July 11, 2010: > > Changes since 2010-07-02 build: > --- > - Updated mingw-w64 crt and headers to svn rev. 2823: A couple of header > updates and import library fixes. > - Binutils updated to fix a symbol quotation problem. > - GCC updated to 4.4.5-prerelease rev. 162041 to catch up with several > upstream fixes. > - Added fixes for GCC PR/44703 and PR/43888. Added a symbol quotation fix > for the aligncomm problem from trunk. > - Make CVS snapshot updated to catch up with several upstream fixes. > > Full ChangeLog: > --- > - See attached file ChangeLog. > > Changes in included software from mainline versions: > --- > - See attached file ChangeLog.sezero. > > Known problems: > --- > - Wolfgang Glas previously reported that the "dllwrap" tool is broken. I > haven't tested myself to confirm the breakage and not done anything in > this build to fix it yet, either. > - The /include path "problem" of the native builds is not > looked into, yet. Maybe in the future builds. > > Compatibility Notice: ** No leading underscore ** > --- > Unlike the other builds from mingw-w64 up to 2010-04-27, these new win64 > targetting toolchains do *not* prepend an undersocore to the symbols and > follows the MSVC x64 convention. Therefore, any of the link libraries > from previous toolchains are incompatible with the ones created by these > new builds. > > > Included software versions: > --- > > Common in both cross- and native-toolchains: > > - gcc : svn rev. 162041 (4.4.5 prerelease with many patches) > - binutils : 2.20.51 (cvs, 2010-07-11 / 09:25 GMT) with patches. > - mingw-w64-crt : svn revision 2823 (2010-07-08) > - mingw-w64-headers : svn revision 2820 (2010-07-08) with a few of patches > - glext headers: 2010-06-17 (from the Khronos Group) > - pthreads-win32: 2.9.0 (CVS 2010-02-28 20:00 GMT) with w64 patch applied. > > In native-toolchains only: > > - gmp : 4.3.2 (with w64 patch applied) > - mpfr: 2.4.2-p3 > - mpc : 0.8.2 > - gdb : 7.1.50 (CVS 2010-07-11 / 09:25 GMT, with minor w64 patches applied) > - make: 3.81.90 (CVS 2010-07-09 / 14:20 GMT, with patches applied according > to savannah bug item 27809.) > - gendef, libmangle: from mingw-w64 svn/trunk > > > File names: > --- > > * Source: > > - mingw-w64-src_20100711_sezero.tar.gz > > > * Targetting Win64: > > - mingw-w64-bin_x86_64-mingw_20100711_sezero.zip > native compiler toolchain for running on x64-windows > host and creating x64-windows binaries. > > - mingw-w64-bin_i686-mingw_20100711_sezero.zip > cross compiler toolchain for running on x86-windows > host but creating x64-windows binaries. > > - mingw-w64-bin_i686-linux_20100711_sezero.tar.gz > cross compiler toolchain for running on a i686-linux > host and creating x64-windows binaries. > > - mingw-w64-bin_x86_64-linux_20100711_sezero.tar.gz > cross compiler toolchain for running on a x86_64-linux > host and creating x64-windows binaries. > > > * Targetting Win32: > > - mingw-w32-bin_i686-mingw_20100711_sezero.zip > native compiler toolchain for running on x86-windows > host and creating x86-windows binaries. > > - mingw-w32-bin_i686-linux_20100711_sezero.tar.gz > cross compiler toolchain for running on a i686-linux > host and creating x86-windows binaries. > > - mingw-w32-bin_x86_64
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
2010/7/30 Earnie :
> Chiheng Xu wrote:
>> 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 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 runtime into 64 bits.
>
>
I thought the first step was porting newlib. Doesn't msys still use that?
>>> Yes, it uses newlib and a mix of Windows API calls. But newlib may
>>> actually be the easier part to convert.
>>>
>>>
>> Is 64-bits MSYS or Cygwin necessary?
>>
>> MSYS may be not necessary at all.
>>
>> If Cygwin merge the changes done in MSYS,
>
> That isn't going to happen which is why I forked Cygwin to create MSYS.
>
>> and provide a Win32_Path
>> mode(translating all Unix paths to Win32 paths at fork/exec or spawn)
>> and MinGW transform itself to use binary mode(linking with binmode.o
>> instead of txtmode.o) and slightly patch uname.exe in coreutils,
>> Cygwin has the potential to replace MSYS and provide many tools
>> missing in MSYS, like tcl/tk, expect, dejagnu necessary for the
>> testing of GCC/GDB/BINUTILS.
>>
>
> Instructions have been provided for building MSYS runtime dependent
> applications in the mingw.org wiki. I understand why you might want
> expect and dejagnu to be available. But are you going to be able to
> test a 64bit version of GCC with a 32bit version of expect and dejagnu?
>
> Earnie
Well, for testing we use linux-host with remote execution on a x64
box, or we use cygwin for this. So as cygwin is 32-bit only, you see
that there is no issue by doing this. At least we didn't noticed here
any. Of course it would be very interesting to have working dejagnu &
expect on msys. This would increase the useful-ness of msys for gcc
maintainers (and possibly also for some other developers), as I expect
that using native expect & gcc increase performance for sure.
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
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 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
Chiheng Xu wrote: > 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 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 runtime into 64 bits. >>> I thought the first step was porting newlib. Doesn't msys still use that? >>> >>> >> Yes, it uses newlib and a mix of Windows API calls. But newlib may >> actually be the easier part to convert. >> >> > Is 64-bits MSYS or Cygwin necessary? > > MSYS may be not necessary at all. > > If Cygwin merge the changes done in MSYS, That isn't going to happen which is why I forked Cygwin to create MSYS. > and provide a Win32_Path > mode(translating all Unix paths to Win32 paths at fork/exec or spawn) > and MinGW transform itself to use binary mode(linking with binmode.o > instead of txtmode.o) and slightly patch uname.exe in coreutils, > Cygwin has the potential to replace MSYS and provide many tools > missing in MSYS, like tcl/tk, expect, dejagnu necessary for the > testing of GCC/GDB/BINUTILS. > Instructions have been provided for building MSYS runtime dependent applications in the mingw.org wiki. I understand why you might want expect and dejagnu to be available. But are you going to be able to test a 64bit version of GCC with a 32bit version of expect and dejagnu? Earnie -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
JonY wrote: > 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, > >>> Earniewrote: > >>> > 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 runtime into 64 > bits. > > >>> I thought the first step was porting newlib. Doesn't msys > >>> still use that? > >>> > >> Yes, it uses newlib and a mix of Windows API calls. But newlib > >> may actually be the easier part to convert. > >> > > > > 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 x86_64 (based from the OS it > > is running) will make me feel better for making you guys waste all > > this time answering this thread. > > > > Hi, > > I think its a bad idea to jump to conclusions based on OS running. > What if I wanted to run plain mingw.org GCC on win64? > > IMHO, setting MSYSTEM would be a better approach. This part of the discussion is concerning identifying the hardware via uname -m. The MSYSTEM variable only affects the uname -s output for the name of the kernel. You will still be able to use "plain mingw.org GCC on win64" as you do today. And you can specify the triplet you need to the --host configure parameter. Earnie -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
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 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 runtime into 64 bits. > >>> > >> I thought the first step was porting newlib. Doesn't msys still > >> use that? > >> > > Yes, it uses newlib and a mix of Windows API calls. But newlib > > may actually be the easier part to convert. > > > > 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. > The uname binary calls a runtime function from MSYS so it would be within the MSYS runtime. Source for that is in CVS at the MinGW project. I don't remember enough to give you a filename. IIRC the path is winsup/cygwin. > If I can add proper identification of x86_64 (based from the OS it > is running) will make me feel better for making you guys waste all > this time answering this thread. > I don't think it has been a waste. It seems to be a productive discussion. Earnie -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] sigset_t and w32pth
On Fri, Jul 30, 2010 at 12:11 PM, Kai Tietz wrote:
> 2010/7/30 Ozkan Sezer :
>> On Fri, Jul 30, 2010 at 4:45 AM, Dongsheng Song
>> wrote:
>>> It seems that Borland C++ defined ENOFILE, and MinGW add the alias of
>>> ENOENT.
>>>
>>
>>
>> Well, ENOENT is actually a standart errno. I learnt ENOFILE just now,
>> but since it seems to be in use, I say that we should define it.
>>
>> --
>> Ozkan
>>
>>
>>> 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.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, 2010 at 21:52, Kai Tietz wrote:
>>> 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 _sigset_t sigset_t;
#endif
#endif /* Not _SIGSET_T_ */
[1] svn://cvs.gnupg.org/w32pth
Regards,
Dongsheng
>>>
>>> Thanks for the point. Committed at revision 3020 to trunk.
>>>
>>> Regards,
>>> Kai
>>>
>>> --
>>> | (\_/) This is Bunny. Copy and paste
>>> | (='.'=) Bunny into your signature to help
>>> | (")_(") him gain world domination
>>>
>>
>
> Well, this is one of those questions. As it is more an alias of ENOENT
> we can add it.
> Maybe someone else wants to comment on this addition?
>
> Cheers,
> Kai
The man page for errno(3) on my linux doesn't list ENOFILE.
Is it a deprecated errno? (I have no objections for its addition, BTW.)
--
Ozkan
>>>
>>
>
> Ok, let use add ENOFILE as '#define ENOFILE ENOENT'
>
> Kai
>
Done, v1.0 branch @3045, tr...@3046.
--
Ozkan
--
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 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] sigset_t and w32pth
2010/7/30 Ozkan Sezer :
> On Fri, Jul 30, 2010 at 4:45 AM, Dongsheng Song
> wrote:
>> It seems that Borland C++ defined ENOFILE, and MinGW add the alias of ENOENT.
>>
>
>
> Well, ENOENT is actually a standart errno. I learnt ENOFILE just now,
> but since it seems to be in use, I say that we should define it.
>
> --
> Ozkan
>
>
>> 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.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, 2010 at 21:52, Kai Tietz wrote:
>> 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 _sigset_t sigset_t;
>>> #endif
>>> #endif /* Not _SIGSET_T_ */
>>>
>>> [1] svn://cvs.gnupg.org/w32pth
>>>
>>> Regards,
>>> Dongsheng
>>
>> Thanks for the point. Committed at revision 3020 to trunk.
>>
>> Regards,
>> Kai
>>
>> --
>> | (\_/) This is Bunny. Copy and paste
>> | (='.'=) Bunny into your signature to help
>> | (")_(") him gain world domination
>>
>
Well, this is one of those questions. As it is more an alias of ENOENT
we can add it.
Maybe someone else wants to comment on this addition?
Cheers,
Kai
>>>
>>> The man page for errno(3) on my linux doesn't list ENOFILE.
>>> Is it a deprecated errno? (I have no objections for its addition, BTW.)
>>>
>>> --
>>> Ozkan
>>>
>>
>
Ok, let use add ENOFILE as '#define ENOFILE ENOENT'
Kai
--
| (\_/) This is Bunny. Copy and paste
| (='.'=) Bunny into your signature to help
| (")_(") him gain world domination
--
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 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] sigset_t and w32pth
On Fri, Jul 30, 2010 at 4:45 AM, Dongsheng Song
wrote:
> It seems that Borland C++ defined ENOFILE, and MinGW add the alias of ENOENT.
>
Well, ENOENT is actually a standart errno. I learnt ENOFILE just now,
but since it seems to be in use, I say that we should define it.
--
Ozkan
> 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.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, 2010 at 21:52, Kai Tietz wrote:
> 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 _sigset_t sigset_t;
>> #endif
>> #endif /* Not _SIGSET_T_ */
>>
>> [1] svn://cvs.gnupg.org/w32pth
>>
>> Regards,
>> Dongsheng
>
> Thanks for the point. Committed at revision 3020 to trunk.
>
> Regards,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
>>>
>>> Well, this is one of those questions. As it is more an alias of ENOENT
>>> we can add it.
>>> Maybe someone else wants to comment on this addition?
>>>
>>> Cheers,
>>> Kai
>>
>> The man page for errno(3) on my linux doesn't list ENOFILE.
>> Is it a deprecated errno? (I have no objections for its addition, BTW.)
>>
>> --
>> Ozkan
>>
>
--
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 Million in cash or HP Products. Visit us here for more details:
http://p.sf.net/sfu/dev2dev-palm
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] pdh - 32bit
On Fri, Jul 30, 2010 at 7:14 AM, Alon Bar-Lev wrote: > Thank you! You're welcome! > When do you consider releasing 1.1 or something similar with new > improvements from trunk but stable? > Admins can answer that better. > 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, >> >> >> >> 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 project put much >> > emphasis on 64 bit rather than 32 bit.) >> > >> > I see that it was only added during late June. I may add it >> > back to v1.0. Which is the one you need? pdh.def, pdhui.def >> > or both? >> > >> > -- >> > Ozkan >> > >> >> OK, I went ahead and added them to v1.0 branch, see rev. 3024. >> >> -- > -- Ozkan -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Making config.guess detect mingw64 platform?
On Thu, Jul 29, 2010 at 8:33 PM, JonY wrote: > 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 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 runtime into 64 bits. > I thought the first step was porting newlib. Doesn't msys still use that? >>> Yes, it uses newlib and a mix of Windows API calls. But newlib may >>> actually be the easier part to convert. >>> >> >> 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 x86_64 (based from the OS it is >> running) will make me feel better for making you guys waste all this >> time answering this thread. >> > > Hi, > > I think its a bad idea to jump to conclusions based on OS running. What > if I wanted to run plain mingw.org GCC on win64? > > IMHO, setting MSYSTEM would be a better approach. You could just use the already existent PROCESSOR_* variables that windows puts in the environment. They should contain everything you need. -- 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 Million in cash or HP Products. Visit us here for more details: http://p.sf.net/sfu/dev2dev-palm ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
