Hello,
Is there any reason why alarm() prototype is declared for win64? It is
not available for Windows anyway... :)
Thanks,
Alon.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the cool
Hello,
After some effort I was able to adjust the OpenSC build system to
build win64 binaries that may actually work. I don't have a machine to
test it, and waiting for feedback, but I thought I post some results
here.
I wrote a script to build the mingw cross compiler, it is available at
[1], in
I wrote a simple script for this, available at [1].
You will need CVS head of binutils, gcc-4.3.2 and SVN head of mingw-w64.
[1] http://www.opensc-project.org/build/browser/trunk/mingw64
On 10/30/08, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> Looking at the download page:
>
>
Hello,
I almost sure it worked until recently... But now a simple program:
#include
#include
int main(void) {
setjmp(NULL);
longjmp(NULL, 0);
}
Cannot be compiled.
x86_64-pc-mingw32-gcc a.c
/tmp/cctlj9Wj.o:a.c:(.text+0xe): undefined reference to `_mingw_getsp'
/tmp/cctlj9Wj.o:a
On 11/13/08, Kai Tietz <[EMAIL PROTECTED]> wrote:
> ok, to support you I need some more details
>
> Which host you are using?
i686-pc-linux-gnu
> Which x86_64-pc-mingw32-gcc you are invoking ? Do you use it from
> /bin, or from /x86_64-pc-mingw32/bin?
/bin
> Have you installed the crt itse
On 11/13/08, Kai Tietz <[EMAIL PROTECTED]> wrote:
> 2008/11/13 Alon Bar-Lev <[EMAIL PROTECTED]>:
>
> > On 11/13/08, Kai Tietz <[EMAIL PROTECTED]> wrote:
> >> ok, to support you I need some more details
> >>
> >> Which host you are using
On 11/13/08, Kai Tietz <[EMAIL PROTECTED]> wrote:
> Hmm, well. Some days ago our Makefile.am was updated. Maybe there is a
> failure happend about this.
Yes...
--- mingw-w64-crt/Makefile.am (revision 493)
+++ mingw-w64-crt/Makefile.am (working copy)
@@ -354,6 +354,7 @@
math/expm1f.c
Which gcc version do you use?
Try latest stable gcc-4.3.2 and not svn head.
Alon.
On 12/3/08, Erik de Castro Lopo <[EMAIL PROTECTED]> wrote:
> Hi all,
>
> I'm trying to build the win64 compiler using this script:
>
> http://www.opensc-project.org/build/browser/trunk/mingw64/build
>
> but it
Just tried again... using binutils CVS head, gcc-4.3.2, mingw-w64 SVN
head and all is OK.
On 12/3/08, Alon Bar-Lev <[EMAIL PROTECTED]> wrote:
> Which gcc version do you use?
> Try latest stable gcc-4.3.2 and not svn head.
>
>
> Alon.
>
>
> On 12/3/08, Erik de
On Sat, Dec 27, 2008 at 11:25 AM, NightStrike wrote:
> Sorry for the long delay, but I've been away for a while. Is this
> still an issue? I just built a fresh toolchain and compiled your code
> with it, having no problems. Please tell me if you are still having
> issues.
It was fixed.
Thanks!
Hello,
Can this be added?
Should be:
typedef enum _HTTP_DATA_CHUNK_TYPE {
HttpDataChunkFromMemory,HttpDataChunkFromFileHandle,HttpDataChunkFromFragmentCache,HttpDataChunkFromFragmentCacheEx,HttpDataChunkMaximum
} HTTP_DATA_CHUNK_TYPE,*PHTTP_DATA_CHUNK_TYPE;
Thanks!
---
please consider to publish a more up-to-date snapshot?
Thanks!
On Tue, Dec 22, 2009 at 10:35 AM, Kai Tietz wrote:
> Alon Bar-Lev wrote on 21.12.2009 17:30:04:
>
>> Hello,
>>
>> Can this be added?
>>
>> Should be:
>> typedef enum _HTTP_DATA_C
Thank you again.
On Tue, Dec 22, 2009 at 1:45 PM, Kai Tietz wrote:
> Sorry for being that lazy. I updated the svn snapshots on our download
> page. We provide additional source balls for toolchain build, but
> those aren't svn snapshots.
>
> You can find two different versions of source snapshots
Hi,
I think that i686-w64-mingw32 should be supported, right?
At least it would be great if it is as this project is much more
maintained and complete than mingw32.
While trying to do so, I get the following... And indeed the
declaration is duplicated.
I tested both v1.0 and trunk snapshots, gcc
Something is invalid with these macros.
Takes localtime_r for example... Both the GNU and standard cannot be compiled...
Is it just me?
#include
#define localtime_r_1(_Time, _Tm) ({ struct tm *___tmp_tm =
\
localtime((_Time)); \
Hello,
I found [1], which states that Microsoft does not support %ll variant.
But I checked this in Visual Studio and it is supported.
So where is the catch?
Thanks,
Alon.
[1]
http://sourceforge.net/tracker/index.php?func=detail&aid=2818436&group_id=2435&atid=102435
--
On Tue, Dec 22, 2009 at 7:44 PM, Tor Lillqvist wrote:
>> I found [1], which states that Microsoft does not support %ll variant.
>> But I checked this in Visual Studio and it is supported.
>> So where is the catch?
>
> There are several different C libraries from Microsoft. Some support
> %ll, some
#define _POSIX
#include
int my_printf(char *format, ...) __attribute__((format(printf,1,2)));
int main(void) {
return 0;
}
$ x86_64-w64-mingw32-gcc -pedantic a.c
a.c:4: warning: ‘__mingw_printf’ is an unrecognized format function type
---
On Tue, Dec 22, 2009 at 7:53 PM, Tor Lillqvist wrote:
>> But this is *UGLY* And I don't have inttypes.h on all platforms...
>> For example solaris8 does not define these constants.
>
> That is why there exists libraries and higher level languages that
> make portability easier.
>
> For instanc
On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
> 2009/12/22 Alon Bar-Lev :
>> Hi,
>>
>> I think that i686-w64-mingw32 should be supported, right?
>> At least it would be great if it is as this project is much more
>> maintained and complete than mingw32.
>&
On Tue, Dec 22, 2009 at 10:01 PM, Kai Tietz wrote:
> Well, we have here (at least for the native printf functions) to
> assume smallest supported feature-set. By using msvcrt.dll (Vista or
> newer) you are using in fact msvcr80.dll + feature set, which supports
> %ll specifier, but older ms runtim
Thanks!
Will use __printf__, I even see it is documented Sorry.
On Tue, Dec 22, 2009 at 9:50 PM, Kai Tietz wrote:
> 2009/12/22 Alon Bar-Lev :
>> #define _POSIX
>> #include
>>
>> int my_printf(char *format, ...) __attribute__((format(printf,1,2)));
>>
>&
/12/23 Alon Bar-Lev :
>> Great!
>> It works.
>
> Thanks for testing. I will apply it to v1.0 branch and trunk.
>
>> But... Why there is a huge difference between lib64 and lib32 libraries?
>> I see that lib32 contains only 142 libraries while lib64 contains 2042.
&g
On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
> The change about malloc isn't used AFAICS, but well I want to keep it,
> as we plan to improve the conditional header includes in future.
> Does this line leads to an build error for you?
Yes... It is needed.
Once the autoconf detects that gnu m
009/12/22 Alon Bar-Lev :
>>> On Tue, Dec 22, 2009 at 9:53 PM, Kai Tietz wrote:
>>>> 2009/12/22 Alon Bar-Lev :
>>>>> Hi,
>>>>>
>>>>> I think that i686-w64-mingw32 should be supported, right?
>>>>> At least it would
Tietz wrote:
> 2009/12/23 Alon Bar-Lev :
>> On Wed, Dec 23, 2009 at 3:03 PM, Kai Tietz wrote:
>>> The change about malloc isn't used AFAICS, but well I want to keep it,
>>> as we plan to improve the conditional header includes in future.
>>> Does this l
Hello,
Just an idea... I had to add pdh.def into current build.
Steps:
1. Add pdh.def into mingw-w64-crt/lib32
2. Add the following to mingw-w64-crt/Makefile.am
cat << __EOF__ >> mingw-w64-crt/Makefile.am
if LIB32
lib32_SCRIPTS += lib32/libpdh.a
endif
__EOF__
3. Do autoreconf
It would be gre
On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
> Ok, I see. I added to the comment that this just happens on
> cross-compile. Btw gendef should work as native build on linux, too.
> There shouldn't be any dependencies to Windows specific runtime.
Almost true... :)
Attached a patch.
Alon.
diff
On Thu, Dec 24, 2009 at 9:55 AM, Alon Bar-Lev wrote:
> On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
>> Ok, I see. I added to the comment that this just happens on
>> cross-compile. Btw gendef should work as native build on linux, too.
>> There shouldn't be a
I don't understand why you keep generated files in svn...
But you should also checkin an updated version of aclocal.m4.
On Thu, Dec 24, 2009 at 10:49 AM, Kai Tietz wrote:
> 2009/12/24 Alon Bar-Lev :
>> On Thu, Dec 24, 2009 at 9:22 AM, Kai Tietz wrote:
>>> Ok, I see. I ad
Hello,
Even if it is exact the same, the timestamp is older the the source
files, so build tries to rebuild it.
Thanks,
Alon.
On Sun, Dec 27, 2009 at 7:44 PM, Kai Tietz wrote:
>
> Hello Alon,
>
> 2009/12/24 Alon Bar-Lev :
> > I don't understand why you keep generated
Anyway, I guess it is not so important for clean checkouts...
On Sun, Dec 27, 2009 at 7:45 PM, Alon Bar-Lev wrote:
> Hello,
>
> Even if it is exact the same, the timestamp is older the the source
> files, so build tries to rebuild it.
>
> Thanks,
> Alon.
>
> On Sun, D
Something like:
((void*)0)+dw
On Mon, Feb 22, 2010 at 1:30 AM, Jim Michaels wrote:
>
>
> it's 32-bit windows 9x code, but the target is 64-bit, so I have to disable
> the 9x code.
> I found a workaround on the internet (great place to look for solutions):
> #if !defined(_WIN64)
> ...//win9x code
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
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
On Sat, Jul 31, 2010 at 11:24 PM, NightStrike wrote:
> Hopefully soon. We (read: I) have to put together a wiki page
> describing our release policies and whatnot.
--
The Palm PDK Hot Apps Program offers developers who u
Build it using cross compile / msys, example is here [1].
[1] http://www.opensc-project.org/build/browser/trunk
On Sat, Aug 28, 2010 at 11:23 PM, Ruben Van Boxem
wrote:
> 2010/8/27 Jaroslav Šmíd
>>
>> Does that mean I need msys to compile it? I run the script from windows
>> command prompt (cmd
Hi,
When compiling this simple source:
---
#include
#include
---
I get tones of errors of redefinitions winnt.h and ddk/ntddk.h.
Should it be possible?
I am using stable branch.
I am actually trying to make winpcap compile... this is the most
problematic issue.
Alon.
---
On Tue, Sep 14, 2010 at 4:49 PM, Ozkan Sezer wrote:
> On Tue, Sep 14, 2010 at 5:41 PM, Alon Bar-Lev wrote:
>> Hi,
>>
>> When compiling this simple source:
>> ---
>> #include
>> #include
>> ---
>> I get tones of errors of redefinitions winnt.h
Hello,
XP have different name for the AES provider.
---
#define MS_ENH_RSA_AES_PROV_XP_A \
"Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)"
#define MS_ENH_RSA_AES_PROV_XP_W \
L"Microsoft Enhanced RSA and AES Cryptographic Provider (Prototype)"
---
This d
_ENH_RSA_AES_PROV MS_ENH_RSA_AES_PROV_W
#else
#define MS_ENH_RSA_AES_PROV_XP MS_ENH_RSA_AES_PROV_XP_A
#define MS_ENH_RSA_AES_PROV MS_ENH_RSA_AES_PROV_A
#endif
#endif //(NTDDI_VERSION >= NTDDI_WINXP)
On Wed, Jul 6, 2011 at 12:03 AM, Ozkan Sezer wrote:
> On Tue, Jul 5, 2011 at 11:41
You should try the mingw package, msys is unmaintained, while the
recent cygwin introduced proper mingw-w64 and recent auto tools which
make it a great alternative.
On Thu, Jan 5, 2012 at 7:25 PM, Patrick von Reth
wrote:
>
> Hi the autotools package contains a broken symbolic link,
> autotools\s
Hello,
Should be supported, right?
Thanks!
Alon
---
#include
#include
int main(void) {
_wctime(NULL);
return 0;
}
---
$ i686-w64-mingw32-gcc -pedantic -Wall -Wextra a.c
/usr/lib/gcc/i686-w64-mingw32/4.5.3/../../../../i686-w64-mingw32/lib/libmingwex.a(lib32_libmingwex_a-_wctime32.
sorry, just noticed that gentoo uses snapshots and proper release is
now in place.
2.0.1 is ok!
On Sat, Feb 25, 2012 at 1:28 AM, JonY wrote:
> On 2/25/2012 07:05, Alon Bar-Lev wrote:
>> Hello,
>> Should be supported, right?
>> Thanks!
>> Alon
>> ---
>> #in
;std::vswprintf, 4 *
sizeof(int),
L"%d", __val); }
Root cause is:
note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
wchar_t*’
L"%d", __val); }
Does this ring any bell?
Full log is available[1].
Regards,
On Tue, Jun 25, 2013 at 12:00 AM, Ruben Van Boxem
wrote:
>
> 2013/6/22 Alon Bar-Lev
>>
>> Hello,
>>
>> gcc-4.8.1 failing for some reason, I guess std::vswprintf is incompatible
>> for some reason, gcc-4.7.3 works correctly. Using mingw64-runtime-2.0.8.
>
On Tue, Jun 25, 2013 at 5:29 AM, Alexey Pavlov wrote:
>
>
>
> 2013/6/25 Alon Bar-Lev
>>
>> On Tue, Jun 25, 2013 at 12:00 AM, Ruben Van Boxem
>> wrote:
>> >
>> > 2013/6/22 Alon Bar-Lev
>> >>
>> >> Hello,
>> >>
&
You should try and use cygwin.
In most cases the following should work:
$ ./configure --host=x86_64-w64-mingw32 --prefix=/tmp/root
CPPFLAGS="-I/tmp/root/include" LDFLAGS="-L/tmp/root/lib"
$ make install
The above actually cross compile to native win32 in cygwin environment.
Alon
On Sat, Aug 17
Hello,
I saw this was released, small comment... this is actually lzma
compressed not bz2, so it causes some issues...
Thanks,
Alon
--
LIMITED TIME SALE - Full Year of Microsoft Training For Just $49.99!
1,500+ hours of
the the crt will use the installed headers by
design, and as the layout of the headers within source differ from
installation, it is not trivial to prepend it to the search list.
Any thoughts?
Regards,
Alon Bar-Lev
Regards,
Alon Bar-Lev
libraries and tools also seems not to be tight coupled with the crt.
Any reason why not to publish these as separate packages?
Regards,
Alon Bar-Lev.
--
October Webinars: Code for Performance
Free Intel webinars can help you
On Sun, Oct 13, 2013 at 4:45 AM, JonY wrote:
> On 10/13/2013 05:24, Alon Bar-Lev wrote:
>> Hi,
>>
>> Is there any advantage of keeping mingw-w64-libraries and
>> mingw-w64-tools at same package as the crt?
>>
>
> Heard you the first time.
I hope no harm is
Hi,
You should update[1]
Alon
[1]
http://sourceforge.net/projects/mingw-w64/files/mingw-w64/mingw-w64-release/
On Thu, Jan 9, 2014 at 11:37 AM, JonY wrote:
> Hi all,
>
> This is a minor bug fix release based on the v3 stable branch.
>
> The notable changes include some fixes for winpthreads
Hi,
Every major update we (at gentoo) and maybe others have issue to upgrade. I
reported[1] this in the past.
Building the crt should use the headers within the crt and not within
sysroot, this to enable building the new crt using an environment that has
the old crt.
Other libc implementation do
On 21 March 2015 at 00:06, Stephen Kitt wrote:
>
> Hi,
>
> On Fri, 20 Mar 2015 22:04:38 +0200, Alon Bar-Lev
> wrote:
> > Every major update we (at gentoo) and maybe others have issue to upgrade. I
> > reported[1] this in the past.
> >
> > Building the cr
On 21 March 2015 at 10:06, Alon Bar-Lev wrote:
> On 21 March 2015 at 00:06, Stephen Kitt wrote:
>>
>> Hi,
>>
>> On Fri, 20 Mar 2015 22:04:38 +0200, Alon Bar-Lev
>> wrote:
>> > Every major update we (at gentoo) and maybe others have issue to up
this somewhat reduces the error checking, but makes code and usage nicer.
Signed-off-by: Alon Bar-Lev
---
configure.ac | 55 ---
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/configure.ac b/configure.ac
index b8677cf..1b59821
Signed-off-by: Alon Bar-Lev
---
Makefile.am | 6 +-
configure.ac | 15 +--
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 26a7606..308b6fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,6 +14,10 @@ if LIBRARIES_PSEH
this somewhat reduces the error checking, but makes code and usage nicer.
Signed-off-by: Alon Bar-Lev
---
configure.ac | 55 ---
1 file changed, 12 insertions(+), 43 deletions(-)
diff --git a/configure.ac b/configure.ac
index 468d1b1..1b59821
Signed-off-by: Alon Bar-Lev
---
Makefile.am | 6 +-
configure.ac | 15 +--
2 files changed, 18 insertions(+), 3 deletions(-)
diff --git a/Makefile.am b/Makefile.am
index 26a7606..308b6fd 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -14,6 +14,10 @@ if LIBRARIES_PSEH
On 5 May 2015 at 16:59, Ozkan Sezer wrote:
>
> On 5/5/15, JonY wrote:
> > On 5/5/2015 03:47, Alon Bar-Lev wrote:
> >> this somewhat reduces the error checking, but makes code and usage nicer.
> >
> > Hi,
> >
> > Thanks for the patch, but I'm
On 6 May 2015 at 01:29, JonY wrote:
>
> On 5/5/2015 22:15, Alon Bar-Lev wrote:
> >
> > Of course it is easier for me in Gentoo to use the toplevel autoconf
> > script, it worked so far, not sure why not just support it, but
> > partial support is not the right
On 6 May 2015 at 01:36, Alon Bar-Lev wrote:
> On 6 May 2015 at 01:29, JonY wrote:
>>
>> On 5/5/2015 22:15, Alon Bar-Lev wrote:
>> >
>> > Of course it is easier for me in Gentoo to use the toplevel autoconf
>> > script, it worked so far, not sure why not
this effects only top level package, if crt is to be built:
1. install headers into builddir for staging
2. adjust CPPFLAGS for tools and libraries to find local headers
3. disable sysroot for crt so search path contain only local headers
Signed-off-by: Alon Bar-Lev
---
Makefile.am
s worse than not at all.
please feel free to send these patches so I can see if I can improve these.
>
> On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev wrote:
> > this effects only top level package, if crt is to be built:
> > 1. install headers into builddir for staging
> >
On 6 May 2015 at 17:34, NightStrike wrote:
> On Wed, May 6, 2015 at 10:08 AM, Alon Bar-Lev wrote:
>>> On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev wrote:
>>> > this effects only top level package, if crt is to be built:
>>> > 1. install headers into builddir
On 6 May 2015 at 17:48, NightStrike wrote:
> On Wed, May 6, 2015 at 10:39 AM, Alon Bar-Lev wrote:
>> On 6 May 2015 at 17:34, NightStrike wrote:
>>> On Wed, May 6, 2015 at 10:08 AM, Alon Bar-Lev wrote:
>>>>> On Wed, May 6, 2015 at 6:25 AM, Alon Bar-Lev
>&
reference,
waiting for input of alternate methods.
Signed-off-by: Alon Bar-Lev
---
Makefile.am | 6 +-
configure.ac| 13 +++--
mingw-w64-crt/configure.ac | 6 --
mingw-w64-headers-local/Makefile.am | 10 ++
4
something that is usable.
Thanks,
Alon
On 4 May 2015 at 22:47, Alon Bar-Lev wrote:
> Signed-off-by: Alon Bar-Lev
> ---
> Makefile.am | 6 +-
> configure.ac | 15 +--
> 2 files changed, 18 insertions(+), 3 deletions(-)
>
> diff --git a/Makefile.am b/Makefi
nyway.
>
> For these who are, it bring us one step closer to something that is usable.
>
> Thanks,
> Alon
On 4 May 2015 at 22:47, Alon Bar-Lev wrote:
> this somewhat reduces the error checking, but makes code and usage nicer.
>
> Signed-
a really bad patch. Sorry.
>
> On Thu, May 28, 2015 at 9:53 AM, Alon Bar-Lev wrote:
> > Quoting my-self:
> >
> >>
> >> Hi,
> >>
> >> I do not have a response from NightStrike, this patch set is modifying the
> >> top level autoconf
Instead of enable all or a single specific tool and library allow enable
or disable comma separated libraries.
This somewhat reduces the error checking, but makes code and usage nicer.
Signed-off-by: Alon Bar-Lev
---
configure.ac | 68
pseh supports only x86, no point in enabling it when libraries are
enabled. This enables downstream to enable libraries without failing.
Signed-off-by: Alon Bar-Lev
---
configure.ac | 8 ++--
1 file changed, 6 insertions(+), 2 deletions(-)
diff --git a/configure.ac b/configure.ac
index
element.
Thanks,
Alon
Alon Bar-Lev (2):
build: enable pseh only in x86
build: enable specific tools and libraries
configure.ac | 64 ++--
1 file changed, 19 insertions(+), 45 deletions(-)
--
2.13.6
On 5 November 2017 at 07:00, JonY via Mingw-w64-public
wrote:
> On 11/04/2017 09:02 PM, Alon Bar-Lev wrote:
> Patches OK, but is there a reason to not use grep -q?
Thanks!
As far as I can see this is how autoconf generates grep stat
On 7 November 2017 at 01:09, JonY via Mingw-w64-public
wrote:
>
> On 11/04/2017 09:02 PM, Alon Bar-Lev wrote:
> > Hi,
> >
> > I see that the patch to add winpthreads was finally merged, this is great as
> > we can patch less the build system at Gentoo.
> >
76 matches
Mail list logo
