Re: [Mingw-w64-public] [PATCH 0/2] Top level build libraries/tools improvements
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. > > > > Here are additional two patches: > > 1. Enable build of pseh only in supported architecture > > 2. Enable comma-separated list of tools and libraries instead explicit > >single element. > > Pushed to master. Thanks! Can you please also cherry-pick these into v5.x? -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ 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 0/2] Top level build libraries/tools improvements
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 statements. -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/2] build: enable pseh only in x86
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 468d1b19..cfb07362 100644 --- a/configure.ac +++ b/configure.ac @@ -58,10 +58,14 @@ AC_ARG_WITH([libraries], [with_libraries=no]) AS_CASE([$with_libraries], [yes|all],[ -with_libraries="libmangle,pseh,winpthreads" +with_libraries="libmangle,winpthreads" with_libraries_winpthreads=yes with_libraries_mangle=yes -with_libraries_pseh=yes], +AS_CASE([$host_cpu], + [i?86], [ +with_libraries="$with_libraries,pseh" +with_libraries_pseh=yes + ])], [libmangle],[ with_libraries="libmangle" with_libraries_winpthreads=no -- 2.13.6 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 0/2] Top level build libraries/tools improvements
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. Here are additional two patches: 1. Enable build of pseh only in supported architecture 2. Enable comma-separated list of tools and libraries instead explicit single 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 -- Check out the vibrant tech community on one of the world's most engaging tech sites, Slashdot.org! http://sdm.link/slashdot ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] build: enable specific tools and libraries
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 +---
1 file changed, 19 insertions(+), 49 deletions(-)
diff --git a/configure.ac b/configure.ac
index cfb07362..71d8f8e6 100644
--- a/configure.ac
+++ b/configure.ac
@@ -53,39 +53,20 @@ AC_MSG_RESULT([$with_crt])
AC_MSG_CHECKING([whether to build the optional libraries])
AC_ARG_WITH([libraries],
[AS_HELP_STRING([--with-libraries=ARG],
-[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
winpthreads, or all])],
+[Build the extra mingw-w64 libs, where ARG is comma separated list of
libmangle, pseh, winpthreads, or all])],
[],
[with_libraries=no])
-AS_CASE([$with_libraries],
- [yes|all],[
-with_libraries="libmangle,winpthreads"
-with_libraries_winpthreads=yes
-with_libraries_mangle=yes
-AS_CASE([$host_cpu],
- [i?86], [
-with_libraries="$with_libraries,pseh"
-with_libraries_pseh=yes
- ])],
- [libmangle],[
-with_libraries="libmangle"
-with_libraries_winpthreads=no
-with_libraries_mangle=yes
-with_libraries_pseh=no],
- [pseh],[
-with_libraries="pseh"
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=yes],
- [winpthreads],[
-with_libraries="winpthreads"
-with_libraries_winpthreads=yes
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [no],[
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [MW64_OPTION_ERROR([with-libraries])])
+libraries="winpthreads mangle"
+AS_CASE([$host_cpu],
+ [i?86], [
+libraries="$libraries pseh"
+ ])
+for l in $libraries; do
+ res=`echo "$with_libraries" | grep $l > /dev/null && echo yes || echo no`
+ AS_CASE([$with_libraries],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_libraries_$l], [res])
+done
AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test "x$with_libraries_winpthreads" =
xyes])
@@ -97,26 +78,15 @@ AC_MSG_RESULT([$with_libraries])
AC_MSG_CHECKING([whether to build the optional tools])
AC_ARG_WITH([tools],
[AS_HELP_STRING([--with-tools=ARG],
-[Build the extra mingw-w64 tools, where ARG is one of gendef, genidl, or
all])],
+[Build the extra mingw-w64 tools, where ARG is comma separated list of
gendef, genidl, or all])],
[],
[with_tools=no])
-AS_CASE([$with_tools],
- [yes|all],[
-with_tools="gendef,genidl"
-with_tools_gendef=yes
-with_tools_genidl=yes],
- [gendef],[
-with_tools="gendef"
-with_tools_gendef=yes
-with_tools_genidl=no],
- [genidl],[
-with_tools="genidl"
-with_tools_gendef=no
-with_tools_genidl=yes],
- [no],[
-with_tools_gendef=no
-with_tools_genidl=no],
- [MW64_OPTION_ERROR([with-tools])])
+for t in gendef genidl; do
+ res=`echo "${with_tools}" | grep $t > /dev/null && echo yes || echo no`
+ AS_CASE([$with_tools],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_tools_$t], [res])
+done
AM_CONDITIONAL([TOOLS_GENDEF],[test "x$with_tools_gendef" = xyes])
AM_CONDITIONAL([TOOLS_GENIDL],[test "x$with_tools_genidl" = xyes])
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
--
2.13.6
--
Check out the vibrant tech community on one of the world's most
engaging tech sites, Slashdot.org! http://sdm.link/slashdot
___
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 2/2] build: autoconf: enable multiple tools and libs
Sorry, I did search my mail and I did waited for your response, I also
ping you few times, including this week.
And apart of your statements that this is a bad patch, you do not
address the actual problem of building crt using older toolchain in
order to upgrade the crt.
Your statements are not helpful for me to understand what is wrong, I
did modify what I did understand from your general comments.
These patches are applied and used successfully in Gentoo now, and
provide working solution, I do need to understand what can be
improved, but telling me that these are bad patches while they solve
actual problem is not helpful.
Please help me to improve this.
On 28 May 2015 at 21:18, NightStrike wrote:
>
> I did respond, and your patch brings things steps away from usable,
> not closer. Check your email, I explained how to do what you are
> trying to do. Your patch is 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 to work properly. Can you please consider it?
> >>
> >> For all who are not using the top level autoconf, it should not matter, as
> >> you do not use it anyway.
> >>
> >> 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-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 100644
> >> --- a/configure.ac
> >> +++ b/configure.ac
> >> @@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
> >> [Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
> >> winpthreads, or all])],
> >>[],
> >>[with_libraries=no])
> >> -AS_CASE([$with_libraries],
> >> - [yes|all],[
> >> -with_libraries="libmangle,pseh,winpthreads"
> >> -with_libraries_winpthreads=yes
> >> -with_libraries_mangle=yes
> >> -with_libraries_pseh=yes],
> >> - [libmangle],[
> >> -with_libraries="libmangle"
> >> -with_libraries_winpthreads=no
> >> -with_libraries_mangle=yes
> >> -with_libraries_pseh=no],
> >> - [pseh],[
> >> -with_libraries="pseh"
> >> -with_libraries_winpthreads=no
> >> -with_libraries_mangle=no
> >> -with_libraries_pseh=yes],
> >> - [winpthreads],[
> >> -with_libraries="winpthreads"
> >> -with_libraries_winpthreads=yes
> >> -with_libraries_mangle=no
> >> -with_libraries_pseh=no],
> >> - [no],[
> >> -with_libraries_winpthreads=no
> >> -with_libraries_mangle=no
> >> -with_libraries_pseh=no],
> >> - [MW64_OPTION_ERROR([with-libraries])])
> >> +for l in winpthreads mangle pseh; do
> >> + res=`echo "${with_libraries}" | grep $l > /dev/null && echo yes || echo
> >> no`
> >> + AS_CASE([$with_libraries],
> >> +[all|yes],[res=yes])
> >> +AS_VAR_COPY([with_libraries_$l], [res])
> >> +done
> >> AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
> >> AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
> >> AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test
> >> "x$with_libraries_winpthreads" = xyes])
> >> @@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
> >> [Build the extra mingw-w64 tools, where ARG is one of gendef, genidl,
> >> or all])],
> >>[],
> >>[with_tools=no])
> >> -AS_CASE([$with_tools],
> >> - [yes|all],[
> >> -with_tools="gendef,genidl"
> >> -with_tools_gendef=yes
> >> -with_tools_genidl=yes],
> >> - [gendef],[
> >> -with_tools="gendef"
> >> -with_tools_gendef=yes
> >> -with_tools_genidl=no],
> >> - [genidl],[
> >> -with_tools="genidl"
> >> -with_tools_gendef=no
&g
Re: [Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs
Quoting my-self:
>
> Hi,
>
> I do not have a response from NightStrike, this patch set is modifying the
> top level autoconf to work properly. Can you please consider it?
>
> For all who are not using the top level autoconf, it should not matter, as
> you do not use it anyway.
>
> 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-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 100644
> --- a/configure.ac
> +++ b/configure.ac
> @@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
> [Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
> winpthreads, or all])],
>[],
>[with_libraries=no])
> -AS_CASE([$with_libraries],
> - [yes|all],[
> -with_libraries="libmangle,pseh,winpthreads"
> -with_libraries_winpthreads=yes
> -with_libraries_mangle=yes
> -with_libraries_pseh=yes],
> - [libmangle],[
> -with_libraries="libmangle"
> -with_libraries_winpthreads=no
> -with_libraries_mangle=yes
> -with_libraries_pseh=no],
> - [pseh],[
> -with_libraries="pseh"
> -with_libraries_winpthreads=no
> -with_libraries_mangle=no
> -with_libraries_pseh=yes],
> - [winpthreads],[
> -with_libraries="winpthreads"
> -with_libraries_winpthreads=yes
> -with_libraries_mangle=no
> -with_libraries_pseh=no],
> - [no],[
> -with_libraries_winpthreads=no
> -with_libraries_mangle=no
> -with_libraries_pseh=no],
> - [MW64_OPTION_ERROR([with-libraries])])
> +for l in winpthreads mangle pseh; do
> + res=`echo "${with_libraries}" | grep $l > /dev/null && echo yes || echo no`
> + AS_CASE([$with_libraries],
> +[all|yes],[res=yes])
> +AS_VAR_COPY([with_libraries_$l], [res])
> +done
> AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
> AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
> AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test "x$with_libraries_winpthreads"
> = xyes])
> @@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
> [Build the extra mingw-w64 tools, where ARG is one of gendef, genidl, or
> all])],
>[],
>[with_tools=no])
> -AS_CASE([$with_tools],
> - [yes|all],[
> -with_tools="gendef,genidl"
> -with_tools_gendef=yes
> -with_tools_genidl=yes],
> - [gendef],[
> -with_tools="gendef"
> -with_tools_gendef=yes
> -with_tools_genidl=no],
> - [genidl],[
> -with_tools="genidl"
> -with_tools_gendef=no
> -with_tools_genidl=yes],
> - [no],[
> -with_tools_gendef=no
> -with_tools_genidl=no],
> - [MW64_OPTION_ERROR([with-tools])])
> +for t in gendef genidl; do
> + res=`echo "${with_tools}" | grep $t > /dev/null && echo yes || echo no`
> + AS_CASE([$with_tools],
> +[all|yes],[res=yes])
> +AS_VAR_COPY([with_tools_$t], [res])
> +done
> AM_CONDITIONAL([TOOLS_GENDEF],[test "x$with_tools_gendef" = xyes])
> AM_CONDITIONAL([TOOLS_GENIDL],[test "x$with_tools_genidl" = xyes])
> AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
> --
> 2.3.6
>
--
___
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 1/2] build: autoconf: support winpthreads library
Hi, I do not have a response from NightStrike, this patch set is modifying the top level autoconf to work properly. Can you please consider it? For all who are not using the top level autoconf, it should not matter, as you do not use it anyway. 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: > 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 >MAYBE_LIBRARIES_PSEH = mingw-w64-libraries/pseh > endif > > +if LIBRARIES_WINPTHREADS > + MAYBE_LIBRARIES_WINPTHREADS = mingw-w64-libraries/winpthreads > +endif > + > if TOOLS_GENDEF >MAYBE_TOOLS_GENDEF = mingw-w64-tools/gendef > endif > @@ -22,7 +26,7 @@ if TOOLS_GENIDL >MAYBE_TOOLS_GENIDL = mingw-w64-tools/genidl > endif > > -SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) > $(MAYBE_LIBRARIES_PSEH) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) > +SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) > $(MAYBE_LIBRARIES_PSEH) $(MAYBE_LIBRARIES_WINPTHREADS) > $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) > > DISTCHECK_CONFIGURE_FLAGS = --with-headers --with-crt > --with-libraries=all --with-tools=all > > diff --git a/configure.ac b/configure.ac > index 4bb3926..468d1b1 100644 > --- a/configure.ac > +++ b/configure.ac > @@ -53,30 +53,41 @@ AC_MSG_RESULT([$with_crt]) > AC_MSG_CHECKING([whether to build the optional libraries]) > AC_ARG_WITH([libraries], >[AS_HELP_STRING([--with-libraries=ARG], > -[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, > or all])], > +[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, > winpthreads, or all])], >[], >[with_libraries=no]) > AS_CASE([$with_libraries], >[yes|all],[ > -with_libraries="libmangle,pseh" > +with_libraries="libmangle,pseh,winpthreads" > +with_libraries_winpthreads=yes > with_libraries_mangle=yes > with_libraries_pseh=yes], >[libmangle],[ > with_libraries="libmangle" > +with_libraries_winpthreads=no > with_libraries_mangle=yes > with_libraries_pseh=no], >[pseh],[ > with_libraries="pseh" > +with_libraries_winpthreads=no > with_libraries_mangle=no > with_libraries_pseh=yes], > + [winpthreads],[ > +with_libraries="winpthreads" > +with_libraries_winpthreads=yes > +with_libraries_mangle=no > +with_libraries_pseh=no], >[no],[ > +with_libraries_winpthreads=no > with_libraries_mangle=no > with_libraries_pseh=no], >[MW64_OPTION_ERROR([with-libraries])]) > AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes]) > AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes]) > +AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test > "x$with_libraries_winpthreads" = xyes]) > > > AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])]) > > AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])]) > > +AM_COND_IF([LIBRARIES_WINPTHREADS],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/winpthreads])]) > AC_MSG_RESULT([$with_libraries]) > > AC_MSG_CHECKING([whether to build the optional tools]) > -- > 2.3.6 > > -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH] [PROTOTYPE] build crt using locally provided headers
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
fixed per NightStrike technical comments, sending just for 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 files changed, 30 insertions(+), 5 deletions(-)
create mode 100644 mingw-w64-headers-local/Makefile.am
diff --git a/Makefile.am b/Makefile.am
index 26a7606..1a25781 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -2,6 +2,10 @@ if HEADER
MAYBE_HEADER = mingw-w64-headers
endif
+if HEADER_LOCAL
+ MAYBE_HEADER_LOCAL = mingw-w64-headers-local
+endif
+
if CRT
MAYBE_CRT = mingw-w64-crt
endif
@@ -22,7 +26,7 @@ if TOOLS_GENIDL
MAYBE_TOOLS_GENIDL = mingw-w64-tools/genidl
endif
-SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE)
$(MAYBE_LIBRARIES_PSEH) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL)
+SUBDIRS = $(MAYBE_HEADER) $(MAYBE_HEADER_LOCAL) $(MAYBE_CRT)
$(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_TOOLS_GENDEF)
$(MAYBE_TOOLS_GENIDL)
DISTCHECK_CONFIGURE_FLAGS = --with-headers --with-crt --with-libraries=all
--with-tools=all
diff --git a/configure.ac b/configure.ac
index 4bb3926..22e20d2 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,7 +44,16 @@ AC_ARG_WITH([crt],
[],
[with_crt=yes])
AS_CASE([$with_crt],
- [yes],[AC_CONFIG_SUBDIRS([mingw-w64-crt])],
+ [yes],[AS_CASE([$with_headers],
+[yes],[
+ AC_CONFIG_SUBDIRS([mingw-w64-crt])
+
AS_VAR_SET([CPPFLAGS],["-I\$(abs_top_builddir)/../mingw-w64-headers-local/headers/include
${CPPFLAGS}"])
+ AS_VAR_SET([SYSROOT_DISABLE],[yes])
+ # export so will effect subpackages
+ export CPPFLAGS
+ export SYSROOT_DISABLE
+ AM_CONDITIONAL([HEADER_LOCAL],[true])
+])],
[no],[],
[MW64_OPTION_ERROR([with-crt])])
AM_CONDITIONAL([CRT],[test "x$with_crt" = xyes])
@@ -108,6 +117,6 @@
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
AM_COND_IF([TOOLS_GENIDL],[AC_CONFIG_SUBDIRS([mingw-w64-tools/genidl])])
AC_MSG_RESULT([$with_tools])
-AC_CONFIG_FILES([Makefile])
+AC_CONFIG_FILES([Makefile mingw-w64-headers-local/Makefile])
AC_OUTPUT
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index bcf7d0c..12d1980 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -18,7 +18,9 @@ AC_ARG_WITH([sysroot],
[AS_HELP_STRING([--with-sysroot=DIR],
[Search for headers within DIR/include (default: prefix)])],
[],
- [AS_VAR_SET([with_sysroot],[yes])])
+ [AS_CASE([$SYSROOT_DISABLE],
+[yes],[AS_VAR_SET([with_sysroot],[no])],
+[AS_VAR_SET([with_sysroot],[yes])])])
AS_CASE([$with_sysroot],
[no],[],
[yes],[AS_VAR_SET([with_sysroot],[$prefix])],
@@ -252,7 +254,7 @@ AC_MSG_RESULT([$enable_tests_unicode])
#AC_FUNC_VPRINTF
#AC_CHECK_FUNCS([alarm atexit btowc fesetround floor ftruncate gettimeofday
isascii localeconv mbrlen memmove memset pow rint setlocale sqrt strcasecmp
strchr strncasecmp strtoull strtoumax])
-AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the
mingw-w64 header set and the build/host option are set properly.])])
+AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_WARN([Please check if the
mingw-w64 header set and the build/host option are set properly.])])
#Warnings and errors, default level is 3
AC_MSG_CHECKING([for warning levels])
diff --git a/mingw-w64-headers-local/Makefile.am
b/mingw-w64-headers-local/Makefile.am
new file mode 100644
index 000..f26b6e8
--- /dev/null
+++ b/mingw-w64-headers-local/Makefile.am
@@ -0,0 +1,10 @@
+all-local:
+ rm -fr headers
+ $(MAKE) \
+ -C "$(top_builddir)/mingw-w64-headers" \
+ prefix="$(abs_builddir)/headers" \
+ includedir="$(abs_builddir)/headers/include" \
+ libdir="$(abs_builddir)/headers/lib" \
+ install
+clean-local:
+ rm -fr headers
--
2.3.6
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
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] [PROTOTYPE] build crt using locally provided headers
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 >>>>> wrote: >>>>> > 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 >>>>> >>>>> This is a very bad idea. You are never allowed to modify the CPPFLAGS >>>>> variable. That is a user only variable, not for use by the package. >>>> >>>> appending (not replacing) to CPPFLAGS or CFLAGS or LDFLAGS within >>>> autoconf is widely used, I never saw that comment. I can remove it in >>>> favour of yet another substitution. I do not see the benefit, nor do I >>>> see such restriction in the autoconf manual. >>>> >>>>> > 3. disable sysroot for crt so search path contain only local headers >>>>> >>>>> This makes no sense. Just change the sysroot that you are passing in. >>>> >>>> there is no need to do so, as the CPPFLAGS are enough and respected by >>>> the crt, the default of having sysroot as $prefix when sysroot is >>>> something that may be considered to change, default should probably be >>>> no. >>> >>> http://www.gnu.org/software/automake/manual/html_node/User-Variables.html#User-Variables >>> >>> "Sometimes package developers are tempted to set user variables such >>> as CFLAGS because it appears to make their job easier. However, the >>> package itself **should never set a user variable**, particularly not >>> to include switches that are required for proper compilation of the >>> package. Since these variables are documented as being for the package >>> builder, that person rightfully expects to be able to override any of >>> these variables at build time." >> >> this is correct for the automake part, you use AM_CPPFLAGS to or >> _CPPFLAGS to alter flags, but at autoconf level appending more flags >> is not something that far fetched, especially when the top level >> configure script is customizing the environment for the subpackages. > > Yes, it's from the automake manual, but the point is still the same. > It's a variable meant for the user, not the build system... which > brings me to my next point... > >> however, I have not understood what you suggest as alternative. as far >> as I understand, we have N subpackages that we to build, adding a -I<> >> to a directory in builddir only if top level package is used. > > I was writing separate emails to do that, but I'll just give the short > version here, which is that, simply, I think a lot of what you're > trying to do belongs in make, not configure. You can do this a lot > more safely using conditionals and make variables, as can be seen > elsewhere in many places across the build system. > > I will send you what I have as per your request when I am home > tomorrow, and maybe it'll serve as a more concrete example for > discussion. That's will be great! The way I see this is that the top level package just automate the build of the subpackages, it just replacement of a script that execute each subpackage with appropriate settings. I perfectly agree to your note if I to modify one of the subpackages that actually build something, but in this case I do not see any reason to make the subpackages complex just for the sake of top level to be able to instrument thecomplete build sequence. Waiting for your hints. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] [PROTOTYPE] build crt using locally provided headers
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 for staging >>> > 2. adjust CPPFLAGS for tools and libraries to find local headers >>> >>> This is a very bad idea. You are never allowed to modify the CPPFLAGS >>> variable. That is a user only variable, not for use by the package. >> >> appending (not replacing) to CPPFLAGS or CFLAGS or LDFLAGS within >> autoconf is widely used, I never saw that comment. I can remove it in >> favour of yet another substitution. I do not see the benefit, nor do I >> see such restriction in the autoconf manual. >> >>> > 3. disable sysroot for crt so search path contain only local headers >>> >>> This makes no sense. Just change the sysroot that you are passing in. >> >> there is no need to do so, as the CPPFLAGS are enough and respected by >> the crt, the default of having sysroot as $prefix when sysroot is >> something that may be considered to change, default should probably be >> no. > > http://www.gnu.org/software/automake/manual/html_node/User-Variables.html#User-Variables > > "Sometimes package developers are tempted to set user variables such > as CFLAGS because it appears to make their job easier. However, the > package itself **should never set a user variable**, particularly not > to include switches that are required for proper compilation of the > package. Since these variables are documented as being for the package > builder, that person rightfully expects to be able to override any of > these variables at build time." this is correct for the automake part, you use AM_CPPFLAGS to or _CPPFLAGS to alter flags, but at autoconf level appending more flags is not something that far fetched, especially when the top level configure script is customizing the environment for the subpackages. however, I have not understood what you suggest as alternative. as far as I understand, we have N subpackages that we to build, adding a -I<> to a directory in builddir only if top level package is used. -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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] [PROTOTYPE] build crt using locally provided headers
On 6 May 2015 at 16:09, NightStrike wrote:
>
> I know I've been silent for a long time, but I do still read the
> lists, and I felt the need to comment on what I consider a bad change.
> Feel free to ignore me.
thank you for your comments.
> I understand the intent, and the intent is good (that is, to make top
> level work again). I still have some local patches to that effect
> from before the git switch that I never committed in time, and I won't
> be using git anytime soon, so it's good that someone else is doing it.
> But, doing it poorly is 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
> > 2. adjust CPPFLAGS for tools and libraries to find local headers
>
> This is a very bad idea. You are never allowed to modify the CPPFLAGS
> variable. That is a user only variable, not for use by the package.
appending (not replacing) to CPPFLAGS or CFLAGS or LDFLAGS within
autoconf is widely used, I never saw that comment. I can remove it in
favour of yet another substitution. I do not see the benefit, nor do I
see such restriction in the autoconf manual.
> > 3. disable sysroot for crt so search path contain only local headers
>
> This makes no sense. Just change the sysroot that you are passing in.
there is no need to do so, as the CPPFLAGS are enough and respected by
the crt, the default of having sysroot as $prefix when sysroot is
something that may be considered to change, default should probably be
no.
> >
> > Signed-off-by: Alon Bar-Lev
> > ---
> > Makefile.am | 2 +-
> > configure.ac| 10 --
> > mingw-w64-crt/configure.ac | 5 +++--
> > mingw-w64-headers-local/Makefile.am | 9 +
> > 4 files changed, 21 insertions(+), 5 deletions(-)
> > create mode 100644 mingw-w64-headers-local/Makefile.am
> >
> > diff --git a/Makefile.am b/Makefile.am
> > index 26a7606..0cf559c 100644
> > --- a/Makefile.am
> > +++ b/Makefile.am
> > @@ -3,7 +3,7 @@ if HEADER
> > endif
> >
> > if CRT
> > - MAYBE_CRT = mingw-w64-crt
> > + MAYBE_CRT = mingw-w64-headers-local mingw-w64-crt
> > endif
> >
> > if LIBRARIES_MANGLE
> > diff --git a/configure.ac b/configure.ac
> > index 4bb3926..e0f7685 100644
> > --- a/configure.ac
> > +++ b/configure.ac
> > @@ -44,7 +44,13 @@ AC_ARG_WITH([crt],
> >[],
> >[with_crt=yes])
> > AS_CASE([$with_crt],
> > - [yes],[AC_CONFIG_SUBDIRS([mingw-w64-crt])],
> > + [yes],[
> > +AC_CONFIG_SUBDIRS([mingw-w64-crt])
> > +
> > CPPFLAGS="-I\$(top_builddir)/../mingw-w64-headers-local/headers/include
> > ${CPPFLAGS}"
> > +export CPPFLAGS # so will effect subpackages
> > +SYSROOT_DISABLE=yes
> > +export SYSROOT_DISABLE # so will effect crt
> > + ],
>
> You are breaking formatting conventions established in all of the
> other files. You don't need two lines to set and export a variable.
> You should not be writing this raw shell code anyway, as autoconf
> gives you facilities to both set and propagate variables in a
> portable, maintainable way.
ok, will use AS_VAR_SET, but I still need to export, right? I do not
know if there is a way to do this using AS_* macros.
>
> >[no],[],
> >[MW64_OPTION_ERROR([with-crt])])
> > AM_CONDITIONAL([CRT],[test "x$with_crt" = xyes])
> > @@ -108,6 +114,6 @@
> > AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
> > AM_COND_IF([TOOLS_GENIDL],[AC_CONFIG_SUBDIRS([mingw-w64-tools/genidl])])
> > AC_MSG_RESULT([$with_tools])
> >
> > -AC_CONFIG_FILES([Makefile])
> > +AC_CONFIG_FILES([Makefile mingw-w64-headers-local/Makefile])
> > AC_OUTPUT
> >
> > diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
> > index bcf7d0c..387380f 100644
> > --- a/mingw-w64-crt/configure.ac
> > +++ b/mingw-w64-crt/configure.ac
> > @@ -18,7 +18,8 @@ AC_ARG_WITH([sysroot],
> >[AS_HELP_STRING([--with-sysroot=DIR],
> > [Search for headers within DIR/include (default: prefix)])],
> >[],
> > - [AS_VAR_SET([with_sysroot],[yes])])
> > + [AS_VAR_IF([SYSROOT_DISABLE], [yes],
> > +[AS_VAR_SET([with_sysroot],[no]],
> > [AS_VAR_SET([with_sysroot],[yes])]))])
>
> Generally speaking, convention is to use AS_CASE whenever possible.
> The resulting shell code is faster and more portable.
[Mingw-w64-public] [PATCH] [PROTOTYPE] build crt using locally provided headers
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 | 2 +-
configure.ac| 10 --
mingw-w64-crt/configure.ac | 5 +++--
mingw-w64-headers-local/Makefile.am | 9 +
4 files changed, 21 insertions(+), 5 deletions(-)
create mode 100644 mingw-w64-headers-local/Makefile.am
diff --git a/Makefile.am b/Makefile.am
index 26a7606..0cf559c 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,7 +3,7 @@ if HEADER
endif
if CRT
- MAYBE_CRT = mingw-w64-crt
+ MAYBE_CRT = mingw-w64-headers-local mingw-w64-crt
endif
if LIBRARIES_MANGLE
diff --git a/configure.ac b/configure.ac
index 4bb3926..e0f7685 100644
--- a/configure.ac
+++ b/configure.ac
@@ -44,7 +44,13 @@ AC_ARG_WITH([crt],
[],
[with_crt=yes])
AS_CASE([$with_crt],
- [yes],[AC_CONFIG_SUBDIRS([mingw-w64-crt])],
+ [yes],[
+AC_CONFIG_SUBDIRS([mingw-w64-crt])
+CPPFLAGS="-I\$(top_builddir)/../mingw-w64-headers-local/headers/include
${CPPFLAGS}"
+export CPPFLAGS # so will effect subpackages
+SYSROOT_DISABLE=yes
+export SYSROOT_DISABLE # so will effect crt
+ ],
[no],[],
[MW64_OPTION_ERROR([with-crt])])
AM_CONDITIONAL([CRT],[test "x$with_crt" = xyes])
@@ -108,6 +114,6 @@
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
AM_COND_IF([TOOLS_GENIDL],[AC_CONFIG_SUBDIRS([mingw-w64-tools/genidl])])
AC_MSG_RESULT([$with_tools])
-AC_CONFIG_FILES([Makefile])
+AC_CONFIG_FILES([Makefile mingw-w64-headers-local/Makefile])
AC_OUTPUT
diff --git a/mingw-w64-crt/configure.ac b/mingw-w64-crt/configure.ac
index bcf7d0c..387380f 100644
--- a/mingw-w64-crt/configure.ac
+++ b/mingw-w64-crt/configure.ac
@@ -18,7 +18,8 @@ AC_ARG_WITH([sysroot],
[AS_HELP_STRING([--with-sysroot=DIR],
[Search for headers within DIR/include (default: prefix)])],
[],
- [AS_VAR_SET([with_sysroot],[yes])])
+ [AS_VAR_IF([SYSROOT_DISABLE], [yes],
+[AS_VAR_SET([with_sysroot],[no]], [AS_VAR_SET([with_sysroot],[yes])]))])
AS_CASE([$with_sysroot],
[no],[],
[yes],[AS_VAR_SET([with_sysroot],[$prefix])],
@@ -252,7 +253,7 @@ AC_MSG_RESULT([$enable_tests_unicode])
#AC_FUNC_VPRINTF
#AC_CHECK_FUNCS([alarm atexit btowc fesetround floor ftruncate gettimeofday
isascii localeconv mbrlen memmove memset pow rint setlocale sqrt strcasecmp
strchr strncasecmp strtoull strtoumax])
-AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_ERROR([Please check if the
mingw-w64 header set and the build/host option are set properly.])])
+AC_CHECK_HEADER([_mingw_mac.h], [], [AC_MSG_WARN([Please check if the
mingw-w64 header set and the build/host option are set properly.])])
#Warnings and errors, default level is 3
AC_MSG_CHECKING([for warning levels])
diff --git a/mingw-w64-headers-local/Makefile.am
b/mingw-w64-headers-local/Makefile.am
new file mode 100644
index 000..9047e8b
--- /dev/null
+++ b/mingw-w64-headers-local/Makefile.am
@@ -0,0 +1,9 @@
+all-local: clean-local
+ $(MAKE) \
+ -C "$(top_builddir)/mingw-w64-headers" \
+ prefix="$(abs_builddir)/headers" \
+ includedir="$(abs_builddir)/headers/include" \
+ libdir="$(abs_builddir)/headers/lib" \
+ install
+clean-local:
+ rm -fr headers
--
2.3.6
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
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 2/2] build: autoconf: enable multiple tools and libs
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 just support it, but >> > partial support is not the right way to go. >> > >> >> It doesn't actually work all the time, especially when the installed >> headers and build versions differ. The install may be silently broken >> even if it did complete. Some problems include missing GUID >> instantiation, missing prototypes causing implicit function declaration etc. >> >> If you put it that way, I vote to get rid of it. >> > > this will create overhead when upstream adds a new tool or library, > then downstream need to figure out what else to build instead of > having this within package customization. > > the header issue is solved quite easily in v4, see [1], the only issue > is pseh that cannot be built, I thought to attend to that later or > remove it from top level configure. BTW: if you like I can workout a solution for that. adding new subdir that will be build between headers and crt so that it installs the headers within builddir and use it in crt. > > I will be very happy if you do not drop it. > > Alon > > [1] > https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/mingw64-runtime/mingw64-runtime-4.0.1.ebuild?revision=1.1&view=markup -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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 2/2] build: autoconf: enable multiple tools and libs
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 way to go. > > > > It doesn't actually work all the time, especially when the installed > headers and build versions differ. The install may be silently broken > even if it did complete. Some problems include missing GUID > instantiation, missing prototypes causing implicit function declaration etc. > > If you put it that way, I vote to get rid of it. > this will create overhead when upstream adds a new tool or library, then downstream need to figure out what else to build instead of having this within package customization. the header issue is solved quite easily in v4, see [1], the only issue is pseh that cannot be built, I thought to attend to that later or remove it from top level configure. I will be very happy if you do not drop it. Alon [1] https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/dev-util/mingw64-runtime/mingw64-runtime-4.0.1.ebuild?revision=1.1&view=markup -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ 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 2/2] build: autoconf: enable multiple tools and libs
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 rather ambivalent about keeping the > > top-level configure. > > > > It doesn't quite work as it is supposed to, building everything in one > > shot, since the CRT depend on an already installed header set before it > > can even compile. Likewise for the libraries. > > > > Kai? Ozkan? LRN? Any thoughts? > > > > Personally, I like doing things stepwise + manually, so my vote would be no. These libraries and tools can be also packaged and distributed regardless of the crt. However, if it is available in toplevel autoconf please support it properly, or just drop it. 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 way to go. Thanks, Alon -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/2] build: autoconf: support winpthreads library
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 MAYBE_LIBRARIES_PSEH = mingw-w64-libraries/pseh endif +if LIBRARIES_WINPTHREADS + MAYBE_LIBRARIES_WINPTHREADS = mingw-w64-libraries/winpthreads +endif + if TOOLS_GENDEF MAYBE_TOOLS_GENDEF = mingw-w64-tools/gendef endif @@ -22,7 +26,7 @@ if TOOLS_GENIDL MAYBE_TOOLS_GENIDL = mingw-w64-tools/genidl endif -SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) +SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_LIBRARIES_WINPTHREADS) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) DISTCHECK_CONFIGURE_FLAGS = --with-headers --with-crt --with-libraries=all --with-tools=all diff --git a/configure.ac b/configure.ac index 4bb3926..468d1b1 100644 --- a/configure.ac +++ b/configure.ac @@ -53,30 +53,41 @@ AC_MSG_RESULT([$with_crt]) AC_MSG_CHECKING([whether to build the optional libraries]) AC_ARG_WITH([libraries], [AS_HELP_STRING([--with-libraries=ARG], -[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, or all])], +[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, winpthreads, or all])], [], [with_libraries=no]) AS_CASE([$with_libraries], [yes|all],[ -with_libraries="libmangle,pseh" +with_libraries="libmangle,pseh,winpthreads" +with_libraries_winpthreads=yes with_libraries_mangle=yes with_libraries_pseh=yes], [libmangle],[ with_libraries="libmangle" +with_libraries_winpthreads=no with_libraries_mangle=yes with_libraries_pseh=no], [pseh],[ with_libraries="pseh" +with_libraries_winpthreads=no with_libraries_mangle=no with_libraries_pseh=yes], + [winpthreads],[ +with_libraries="winpthreads" +with_libraries_winpthreads=yes +with_libraries_mangle=no +with_libraries_pseh=no], [no],[ +with_libraries_winpthreads=no with_libraries_mangle=no with_libraries_pseh=no], [MW64_OPTION_ERROR([with-libraries])]) AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes]) AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes]) +AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test "x$with_libraries_winpthreads" = xyes]) AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])]) AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])]) +AM_COND_IF([LIBRARIES_WINPTHREADS],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/winpthreads])]) AC_MSG_RESULT([$with_libraries]) AC_MSG_CHECKING([whether to build the optional tools]) -- 2.3.6 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs
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 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
winpthreads, or all])],
[],
[with_libraries=no])
-AS_CASE([$with_libraries],
- [yes|all],[
-with_libraries="libmangle,pseh,winpthreads"
-with_libraries_winpthreads=yes
-with_libraries_mangle=yes
-with_libraries_pseh=yes],
- [libmangle],[
-with_libraries="libmangle"
-with_libraries_winpthreads=no
-with_libraries_mangle=yes
-with_libraries_pseh=no],
- [pseh],[
-with_libraries="pseh"
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=yes],
- [winpthreads],[
-with_libraries="winpthreads"
-with_libraries_winpthreads=yes
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [no],[
-with_libraries_winpthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [MW64_OPTION_ERROR([with-libraries])])
+for l in winpthreads mangle pseh; do
+ res=`echo "${with_libraries}" | grep $l > /dev/null && echo yes || echo no`
+ AS_CASE([$with_libraries],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_libraries_$l], [res])
+done
AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test "x$with_libraries_winpthreads" =
xyes])
@@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
[Build the extra mingw-w64 tools, where ARG is one of gendef, genidl, or
all])],
[],
[with_tools=no])
-AS_CASE([$with_tools],
- [yes|all],[
-with_tools="gendef,genidl"
-with_tools_gendef=yes
-with_tools_genidl=yes],
- [gendef],[
-with_tools="gendef"
-with_tools_gendef=yes
-with_tools_genidl=no],
- [genidl],[
-with_tools="genidl"
-with_tools_gendef=no
-with_tools_genidl=yes],
- [no],[
-with_tools_gendef=no
-with_tools_genidl=no],
- [MW64_OPTION_ERROR([with-tools])])
+for t in gendef genidl; do
+ res=`echo "${with_tools}" | grep $t > /dev/null && echo yes || echo no`
+ AS_CASE([$with_tools],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_tools_$t], [res])
+done
AM_CONDITIONAL([TOOLS_GENDEF],[test "x$with_tools_gendef" = xyes])
AM_CONDITIONAL([TOOLS_GENIDL],[test "x$with_tools_genidl" = xyes])
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
--
2.3.6
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 1/2] build: autoconf: support winpthreads library
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 MAYBE_LIBRARIES_PSEH = mingw-w64-libraries/pseh endif +if LIBRARIES_WINPTHREADS + MAYBE_LIBRARIES_WINPTHREADS = mingw-w64-libraries/winpthreads +endif + if TOOLS_GENDEF MAYBE_TOOLS_GENDEF = mingw-w64-tools/gendef endif @@ -22,7 +26,7 @@ if TOOLS_GENIDL MAYBE_TOOLS_GENIDL = mingw-w64-tools/genidl endif -SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) +SUBDIRS = $(MAYBE_HEADER) $(MAYBE_CRT) $(MAYBE_LIBRARIES_MANGLE) $(MAYBE_LIBRARIES_PSEH) $(MAYBE_LIBRARIES_WINPTHREADS) $(MAYBE_TOOLS_GENDEF) $(MAYBE_TOOLS_GENIDL) DISTCHECK_CONFIGURE_FLAGS = --with-headers --with-crt --with-libraries=all --with-tools=all diff --git a/configure.ac b/configure.ac index 4bb3926..b8677cf 100644 --- a/configure.ac +++ b/configure.ac @@ -53,30 +53,41 @@ AC_MSG_RESULT([$with_crt]) AC_MSG_CHECKING([whether to build the optional libraries]) AC_ARG_WITH([libraries], [AS_HELP_STRING([--with-libraries=ARG], -[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, or all])], +[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh, winpthreads, or all])], [], [with_libraries=no]) AS_CASE([$with_libraries], [yes|all],[ -with_libraries="libmangle,pseh" +with_libraries="libmangle,pseh,winpthreads" +with_libraries_pthreads=yes with_libraries_mangle=yes with_libraries_pseh=yes], [libmangle],[ with_libraries="libmangle" +with_libraries_pthreads=no with_libraries_mangle=yes with_libraries_pseh=no], [pseh],[ with_libraries="pseh" +with_libraries_pthreads=no with_libraries_mangle=no with_libraries_pseh=yes], + [winpthreads],[ +with_libraries="winpthreads" +with_libraries_winpthreads=yes +with_libraries_mangle=no +with_libraries_pseh=no], [no],[ +with_libraries_pthreads=no with_libraries_mangle=no with_libraries_pseh=no], [MW64_OPTION_ERROR([with-libraries])]) AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes]) AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes]) +AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test "x$with_libraries_winpthreads" = xyes]) AM_COND_IF([LIBRARIES_MANGLE],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/libmangle])]) AM_COND_IF([LIBRARIES_PSEH],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/pseh])]) +AM_COND_IF([LIBRARIES_WINPTHREADS],[AC_CONFIG_SUBDIRS([mingw-w64-libraries/winpthreads])]) AC_MSG_RESULT([$with_libraries]) AC_MSG_CHECKING([whether to build the optional tools]) -- 2.3.6 -- One dashboard for servers and applications across Physical-Virtual-Cloud Widest out-of-the-box monitoring support with 50+ applications Performance metrics, stats and reports that give you Actionable Insights Deep dive visibility with transaction tracing using APM Insight. http://ad.doubleclick.net/ddm/clk/290420510;117567292;y ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [PATCH 2/2] build: autoconf: enable multiple tools and libs
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 100644
--- a/configure.ac
+++ b/configure.ac
@@ -56,32 +56,12 @@ AC_ARG_WITH([libraries],
[Build the extra mingw-w64 libs, where ARG is one of libmangle, pseh,
winpthreads, or all])],
[],
[with_libraries=no])
-AS_CASE([$with_libraries],
- [yes|all],[
-with_libraries="libmangle,pseh,winpthreads"
-with_libraries_pthreads=yes
-with_libraries_mangle=yes
-with_libraries_pseh=yes],
- [libmangle],[
-with_libraries="libmangle"
-with_libraries_pthreads=no
-with_libraries_mangle=yes
-with_libraries_pseh=no],
- [pseh],[
-with_libraries="pseh"
-with_libraries_pthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=yes],
- [winpthreads],[
-with_libraries="winpthreads"
-with_libraries_winpthreads=yes
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [no],[
-with_libraries_pthreads=no
-with_libraries_mangle=no
-with_libraries_pseh=no],
- [MW64_OPTION_ERROR([with-libraries])])
+for l in winpthreads mangle pseh; do
+ res=`echo "${with_libraries}" | grep $l > /dev/null && echo yes || echo no`
+ AS_CASE([$with_libraries],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_libraries_$l], [res])
+done
AM_CONDITIONAL([LIBRARIES_MANGLE],[test "x$with_libraries_mangle" = xyes])
AM_CONDITIONAL([LIBRARIES_PSEH],[test "x$with_libraries_pseh" = xyes])
AM_CONDITIONAL([LIBRARIES_WINPTHREADS],[test "x$with_libraries_winpthreads" =
xyes])
@@ -96,23 +76,12 @@ AC_ARG_WITH([tools],
[Build the extra mingw-w64 tools, where ARG is one of gendef, genidl, or
all])],
[],
[with_tools=no])
-AS_CASE([$with_tools],
- [yes|all],[
-with_tools="gendef,genidl"
-with_tools_gendef=yes
-with_tools_genidl=yes],
- [gendef],[
-with_tools="gendef"
-with_tools_gendef=yes
-with_tools_genidl=no],
- [genidl],[
-with_tools="genidl"
-with_tools_gendef=no
-with_tools_genidl=yes],
- [no],[
-with_tools_gendef=no
-with_tools_genidl=no],
- [MW64_OPTION_ERROR([with-tools])])
+for t in gendef genidl; do
+ res=`echo "${with_tools}" | grep $t > /dev/null && echo yes || echo no`
+ AS_CASE([$with_tools],
+[all|yes],[res=yes])
+AS_VAR_COPY([with_tools_$t], [res])
+done
AM_CONDITIONAL([TOOLS_GENDEF],[test "x$with_tools_gendef" = xyes])
AM_CONDITIONAL([TOOLS_GENIDL],[test "x$with_tools_genidl" = xyes])
AM_COND_IF([TOOLS_GENDEF],[AC_CONFIG_SUBDIRS([mingw-w64-tools/gendef])])
--
2.3.6
--
One dashboard for servers and applications across Physical-Virtual-Cloud
Widest out-of-the-box monitoring support with 50+ applications
Performance metrics, stats and reports that give you Actionable Insights
Deep dive visibility with transaction tracing using APM Insight.
http://ad.doubleclick.net/ddm/clk/290420510;117567292;y
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] v4.0.0 released
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 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 does exactly that, I tried to modify the build of
>> > the mingw runtime and it seem non trivial to achieve this in current state.
>> >
>> > Can you please consider implementing that?
>>
>> The way I get around this is a variant of:
>>
>> * build the CRT headers
>> * install them to ${source}/tmp (so they end up in
>> ${source}/tmp/usr/${target}/include)
>> * configure the CRT libraries with -I${source}/tmp/usr/${target}/include
>>
>> That way the CRT libraries are built with the provided headers, not the
>> installed ones.
>
> Thanks!
> It seems to work, I tried this trick in 3.0 and it took the header out
> of sysroot because it injected this as sysinclude.
Maybe stupid question... but why not build against in-tree headers by default?
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] v4.0.0 released
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 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 does exactly that, I tried to modify the build of
> > the mingw runtime and it seem non trivial to achieve this in current state.
> >
> > Can you please consider implementing that?
>
> The way I get around this is a variant of:
>
> * build the CRT headers
> * install them to ${source}/tmp (so they end up in
> ${source}/tmp/usr/${target}/include)
> * configure the CRT libraries with -I${source}/tmp/usr/${target}/include
>
> That way the CRT libraries are built with the provided headers, not the
> installed ones.
Thanks!
It seems to work, I tried this trick in 3.0 and it took the header out
of sysroot because it injected this as sysinclude.
--
Dive into the World of Parallel Programming The Go Parallel Website, sponsored
by Intel and developed in partnership with Slashdot Media, is your hub for all
things parallel software development, from weekly thought leadership blogs to
news, videos, case studies, tutorials and more. Take a look and join the
conversation now. http://goparallel.sourceforge.net/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] v4.0.0 released
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 does exactly that, I tried to modify the build of the mingw runtime and it seem non trivial to achieve this in current state. Can you please consider implementing that? Thanks, Alon [1] http://sourceforge.net/p/mingw-w64/mailman/message/31513430/ -- Dive into the World of Parallel Programming The Go Parallel Website, sponsored by Intel and developed in partnership with Slashdot Media, is your hub for all things parallel software development, from weekly thought leadership blogs to news, videos, case studies, tutorials and more. Take a look and join the conversation now. http://goparallel.sourceforge.net/___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] mingw-w64 v3.1.0 out!
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 deadlocking and a > workaround for C/C++ linkage clash in crt/intrin.h. > > > > -- > CenturyLink Cloud: The Leader in Enterprise Cloud Services. > Learn Why More Businesses Are Choosing CenturyLink Cloud For > Critical Workloads, Development Environments & Everything In Between. > Get a Quote or Start a Free Trial Today. > > http://pubads.g.doubleclick.net/gampad/clk?id=119420431&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- CenturyLink Cloud: The Leader in Enterprise Cloud Services. Learn Why More Businesses Are Choosing CenturyLink Cloud For Critical Workloads, Development Environments & Everything In Between. Get a Quote or Start a Free Trial Today. http://pubads.g.doubleclick.net/gampad/clk?id=119420431&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] advantage of keeping mingw-w64-libraries and mingw-w64-tools within crt package
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 done when I use a human text in message body in addition to short subject. > >> These cannot be compiled if there is no fully functional toolchain. >> >> Following sequence does not work: >> >> 1. binutil >> 2. crt headers >> 3. gcc-stage1 >> 4. crt --with-libraries --with-tools >> >> The libraries and tools also seems not to be tight coupled with the crt. >> > > You seem to be confusing the CRT with the entire package. > > The top level configure is a very recent development compared to the > rest, for now, it is a rather poor replacement to build the components > separately, traditionally, it is done: > > binutils > headers > gcc-stage1 > crt > the rest of gcc > the rest of the libraries and tools. > >> Any reason why not to publish these as separate packages? >> > > Mostly because everything goes under /trunk, and a release is just svn > export. I understand, however, probably the extra packages can go into their own repository and release cycle. Thanks, Alon Bar-Lev. -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&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] advantage of keeping mingw-w64-libraries and mingw-w64-tools within crt package
Hi, Is there any advantage of keeping mingw-w64-libraries and mingw-w64-tools at same package as the crt? These cannot be compiled if there is no fully functional toolchain. Following sequence does not work: 1. binutil 2. crt headers 3. gcc-stage1 4. crt --with-libraries --with-tools The 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 accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&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] building crt at one pass (headers + crt)
Hi, I know this is odd question... as usually the order is: 1. binutils 2. crt headers 3. gcc stage 1 4. crt 5. gcc stage 2 In this sequence crt can use the installed headers while it is being built. However, a sequence of crt update fails for us (Gentoo)... having already built environment and just updating the mingw crt using the existing compiler, in this case the new crt will use the headers of the old crt while built. A solution for both sequences is to always compile crt with the header provided within the package and not what currently installed at sysroot. As far as I can see 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 -- October Webinars: Code for Performance Free Intel webinars can help you accelerate application performance. Explore tips for MPI, OpenMP, advanced profiling, and more. Get the most from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60134071&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] mingw-w64-v3.0.tar.bz2 is actually xz
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 tutorials including VisualStudio 2012, Windows 8, SharePoint 2013, SQL 2012, MVC 4, more. BEST VALUE: New Multi-Library Power Pack includes Mobile, Cloud, Java, and UX Design. Lowest price ever! Ends 9/20/13. http://pubads.g.doubleclick.net/gampad/clk?id=58041151&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] status of MSYS?
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, 2013 at 10:52 AM, Jim Michaels wrote: > I always get compile or make errors, usually due to a tool or compiler > feature missing or not passing the tests. > nothing has yet completed a compile to date. > fstab is unconfigured (which I did manually correctly I hope, don't know how > for compiling), > I am just not smart anymore at compiling and configuring *nix stuff I was > in my prime there 20 years ago. I have been on other platforms (dos, > windows, cp/m). > I don't know what automake and autoconf are for or how to use them. > I could not compile postgresql for instance. I wanted to compile with libpq. > and libpq had some problems I wanted to try to fix (they said "please > build"). but the config files were complicated and undocumented enough I > could not configure the thing so it would compile. > and then there are the library dependecies. I *think* you just add those to > INLCUDE and LIB. yes? do I need to add to PATH as well? > there are no MSYS instructions for configuring it with a specific compiler. > or does it have its own? do I have to use the one it comes with? > > I also just discovered that some windows 7 components were not installed > (like the unix support stuff) that (?) may be handy. > http://Jesusnjim.com/programming/just-starting/windows-services-developers-may-want-to-start.html#enable > does that really make any difference? > > I think zlib compiles. but I am not sure which kind of zlib (there are 2 out > there). > > I would have to try to find a project again like libxml. > > I eventually need a commercial gcc compiler with a GUI toolkit. not sure how > much those cost. was looking at cygwin. I don't care for all the tools in it > (some of the names are just plain bad, better names and more descriptive > could have been chosen). > > > > > From: niXman > To: mingw-w64-public@lists.sourceforge.net > Sent: Friday, August 9, 2013 4:31 AM > Subject: Re: [Mingw-w64-public] status of MSYS? > > 2013/8/9 Jim Michaels: >> it was said that cURL should be easy to build with mingw-w64. I have been >> unable to build anything using MSYS other than using my own batch files as >> a >> build environment. something is just not configured, and there's no >> manual, >> and I am not a full-fledged *nix nut. MSYS just doesn't work. >> >> is it OK to use MSYS? or do I need to use cygwin to build anything >> *nix-like? > What problems have you encountered? > > > -- > Regards, > niXman > ___ > Dual-target(32 & 64-bit) MinGW compilers for 32 and 64-bit Windows: > http://sourceforge.net/projects/mingwbuilds/ > ___ > Another online IDE: http://liveworkspace.org/ > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > > -- > Get 100% visibility into Java/.NET code with AppDynamics Lite! > It's a free troubleshooting tool designed for production. > Get down to code-level detail for bottlenecks, with <2% overhead. > Download for free and get started troubleshooting in minutes. > http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Get 100% visibility into Java/.NET code with AppDynamics Lite! It's a free troubleshooting tool designed for production. Get down to code-level detail for bottlenecks, with <2% overhead. Download for free and get started troubleshooting in minutes. http://pubads.g.doubleclick.net/gampad/clk?id=48897031&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] gcc-4.8.1 build failure libstdc++ string
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,
>> >>
>> >> 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.
>> >>
>> >> Example (libstdc++-v3/include/bits/basic_string.h):
>> >> inline wstring
>> >> to_wstring(int __val)
>> >> { return __gnu_cxx::__to_xstring(&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?
>> >
>> >
>> > Yes: you must use MinGW-w64 trunk for GCC >= 4.8. This requirement
>> > allowed everyone to enjoy std::to_string. Thank your friendly libstdc++
>> > maintainers.
>> >
>>
>> Thanks!
>> Will wait for release.
>>
> Wait for what?
> Try it!
> http://sourceforge.net/projects/mingwbuilds/files/host-windows/releases/4.8.1/
Thanks!
Gentoo provides a method for building from source.
We can take a snapshot of trunk but there is a reason why you guys
have not released, right?
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] gcc-4.8.1 build failure libstdc++ string
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.
>>
>> Example (libstdc++-v3/include/bits/basic_string.h):
>> inline wstring
>> to_wstring(int __val)
>> { return __gnu_cxx::__to_xstring(&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?
>
>
> Yes: you must use MinGW-w64 trunk for GCC >= 4.8. This requirement allowed
> everyone to enjoy std::to_string. Thank your friendly libstdc++ maintainers.
>
Thanks!
Will wait for release.
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] gcc-4.8.1 build failure libstdc++ string
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.
Example (libstdc++-v3/include/bits/basic_string.h):
inline wstring
to_wstring(int __val)
{ return __gnu_cxx::__to_xstring(&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,
Alon Bar-Lev
[1] https://bugs.gentoo.org/show_bug.cgi?id=473916
---
gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc -DDLL_EXPORT -DPIC
-D_GLIBCXX_SHARED -o .libs/compatibility-c++0x.o
In file included from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/string:52:0,
from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc:26:
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:
In function ‘std::wstring std::to_wstring(int)’:
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2967:22:
error: no matching function for call to ‘__to_xstring(int (*)(wchar_t*,
const wchar_t*, char*), unsigned int, const wchar_t [3], int&)’
L"%d", __val); }
^
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2967:22:
note: candidate is:
In file included from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2815:0,
from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/string:52,
from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc:26:
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/ext/string_conversions.h:83:5:
note: template _String
__gnu_cxx::__to_xstring(int (*)(_CharT*, std::size_t, const _CharT*,
char*), std::size_t, const _CharT*, ...)
__to_xstring(int (*__convf) (_CharT*, std::size_t, const _CharT*,
^
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/ext/string_conversions.h:83:5:
note: template argument deduction/substitution failed:
In file included from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/string:52:0,
from
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/gcc-4.8.1/libstdc++-v3/src/c++11/compatibility-c++0x.cc:26:
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2967:22:
note: mismatched types ‘std::size_t {aka unsigned int}’ and ‘const
wchar_t*’
L"%d", __val); }
^
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:
In function ‘std::wstring std::to_wstring(unsigned int)’:
/var/tmp/portage/cross-i686-w64-mingw32/gcc-4.8.1/work/build/i686-w64-mingw32/libstdc++-v3/include/bits/basic_string.h:2973:22:
error: no matching function for call to ‘__to_xstring(int (*)(wchar_t*,
const wchar_t*, char*), unsigned int, const wchar_t [3], unsigned int&)’
L"%u", __val); }
^
--
This SF.net email is sponsored by Windows:
Build for Windows Store.
http://p.sf.net/sfu/windows-dev2dev___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] _wctime() missing?
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
>> ---
>> #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.o):(.text+0x4):
>> undefined reference to `__imp__wctime'
>> collect2: ld returned 1 exit status
>> ---
>> [I-O] [ ] cross-i686-w64-mingw32/binutils-2.22-r1:i686-w64-mingw32
>> [I-O] [ ] cross-i686-w64-mingw32/gcc-4.5.3-r2:i686-w64-mingw32-4.5
>> [I-O] [ ] cross-i686-w64-mingw32/mingw64-runtime-20110523:0
>> ---
>
> Checking trunk msvcrt.def, it has: _wctime DATA
> And compiling said _wctime32 gives: __imp___wctime, not __imp__wctime.
>
> So something else went wrong in your build process. Did you mess with
> the underscore prefix?
>
>
> --
> Virtualization & Cloud Management Using Capacity Planning
> Cloud computing makes use of virtualization - but cloud computing
> also focuses on allowing computing to be delivered as a service.
> http://www.accelacomm.com/jaw/sfnl/114/51521223/
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] _wctime() missing?
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.o):(.text+0x4):
undefined reference to `__imp__wctime'
collect2: ld returned 1 exit status
---
[I-O] [ ] cross-i686-w64-mingw32/binutils-2.22-r1:i686-w64-mingw32
[I-O] [ ] cross-i686-w64-mingw32/gcc-4.5.3-r2:i686-w64-mingw32-4.5
[I-O] [ ] cross-i686-w64-mingw32/mingw64-runtime-20110523:0
---
--
Virtualization & Cloud Management Using Capacity Planning
Cloud computing makes use of virtualization - but cloud computing
also focuses on allowing computing to be delivered as a service.
http://www.accelacomm.com/jaw/sfnl/114/51521223/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] autotools
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\share\aclocal points to /usr/share/aclocal wont work if extracted > with a normal tool. > Also if the package gets updated can you please build it with disabled perl > threads? > The msys-perl doesn't support threads so some autotools operations are > failing. > > Cheers > > Patrick > > -- > Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex > infrastructure or vast IT resources to deliver seamless, secure access to > virtual desktops. With this all-in-one solution, easily deploy virtual > desktops for less than the cost of PCs and save 60% on VDI infrastructure > costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- Ridiculously easy VDI. With Citrix VDI-in-a-Box, you don't need a complex infrastructure or vast IT resources to deliver seamless, secure access to virtual desktops. With this all-in-one solution, easily deploy virtual desktops for less than the cost of PCs and save 60% on VDI infrastructure costs. Try it free! http://p.sf.net/sfu/Citrix-VDIinabox ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] [wincrypt.h] Missing: MS_ENH_RSA_AES_PROV_XP
Oh... I can provide the exact syntax from wincrypt.h: #if (NTDDI_VERSION >= NTDDI_WINXP) #define MS_ENH_RSA_AES_PROV_A "Microsoft Enhanced RSA and AES Cryptographic Provider" #define MS_ENH_RSA_AES_PROV_W L"Microsoft Enhanced RSA and AES Cryptographic 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)" #ifdef UNICODE #define MS_ENH_RSA_AES_PROV_XP MS_ENH_RSA_AES_PROV_XP_W #define MS_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 PM, Alon Bar-Lev wrote: >> 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 definition is missing from mingw includes. >> I verified this, the XP (prototype) provides works on XP and the none >> prototype is not found. >> >> Please consider to add. >> Alon. > > There are few hits on a google search for MS_ENH_RSA_AES_PROV_XP > and this one: > http://www.genmaint.com/invalid-algorithm-specified-on-windows-2003-server-only.html > ... shows the same string as Alon types. So, I guess the suggested macro > is correct. If added, should be done so for both the trunk as well as > the release > versions of wincrypt.h. > > -- > O.S. > > -- > All of the data generated in your IT infrastructure is seriously valuable. > Why? It contains a definitive record of application performance, security > threats, fraudulent activity, and more. Splunk takes this data and makes > sense of it. IT sense. And common sense. > http://p.sf.net/sfu/splunk-d2d-c2 > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [wincrypt.h] Missing: MS_ENH_RSA_AES_PROV_XP
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 definition is missing from mingw includes. I verified this, the XP (prototype) provides works on XP and the none prototype is not found. Please consider to add. Alon. -- All of the data generated in your IT infrastructure is seriously valuable. Why? It contains a definitive record of application performance, security threats, fraudulent activity, and more. Splunk takes this data and makes sense of it. IT sense. And common sense. http://p.sf.net/sfu/splunk-d2d-c2 ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] ntddk.h
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 and ddk/ntddk.h. > > You aren't supposed to include those together: ntddk.h includes > ntdef.h which includes necessary things for a driver compilation. > windows.h includes winnt.h and it conflicts with ntdef.h and other > ddk includes. Thanks! I will try to fix the mess. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] ntddk.h
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. -- Start uncovering the many advantages of virtual appliances and start using them to simplify application deployment and accelerate your shift to cloud computing. http://p.sf.net/sfu/novell-sfdev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] How to build OpenSSL
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.exe)... well, that would explain POSIX-like slashes >> in printed stuff. Grr, I don't want to install msys. >> >> On 27.8.2010 16:00, Luis Lavena wrote: >> > On Fri, Aug 27, 2010 at 7:04 AM, Jaroslav Šmíd >> > wrote: >> >> I have successfully created MSVC x64 build of OpenSSL-1.0.0a, but I >> >> need >> >> mingw-w64 build now. There doesn't seem to be any info in OpenSSL >> >> documentation, but I found it in "Projects successfully using >> >> MinGW-w64" >> >> list on mingw-w64 site. I have tried to configure it with >> >> >> >> perl Configure mingw64 --prefix=D:\Devel\Mingw-w64\OpenSSL\Dist >> >> >> >> But what I get is >> >> >> >> --- part removed --- >> >> RC4_CHUNK is unsigned long long >> >> e_os2.h => include/openssl/e_os2.h >> >> "making $target in $dir..." >> >> 'TOP' is not recognized as an internal or external command, >> >> operable program or batch file. >> >> make: *** [links] Error 1 >> >> >> >> >> >> In MSVC build RC4_CHUNK line is the last one printed and I can run >> >> nmake >> >> then, so there seems to be something wrong. >> >> >> > >> > Have you set TERM=msys before invoking Configure? >> > >> > I found that perl Configure mingw or perl Configure mingw64 will not >> > generate the proper files without emulating msys terminal (like >> > expecting been invoked inside msys bash) >> > >> >> >> -- >> Sell apps to millions through the Intel(R) Atom(Tm) Developer Program >> Be part of this innovative community and reach millions of netbook users >> worldwide. Take advantage of special opportunities to increase revenue and >> speed time-to-market. Join now, and jumpstart your future. >> http://p.sf.net/sfu/intel-atom-d2d >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > We provide a convenient download and unpack MSYS. It's under external binary > packages under the donwloads section. See the wiki for instructions, it's > easy and fast :) > http://sourceforge.net/apps/trac/mingw-w64/wikiMSYS > > -- > Sell apps to millions through the Intel(R) Atom(Tm) Developer Program > Be part of this innovative community and reach millions of netbook users > worldwide. Take advantage of special opportunities to increase revenue and > speed time-to-market. Join now, and jumpstart your future. > http://p.sf.net/sfu/intel-atom-d2d > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > -- Sell apps to millions through the Intel(R) Atom(Tm) Developer Program Be part of this innovative community and reach millions of netbook users worldwide. Take advantage of special opportunities to increase revenue and speed time-to-market. Join now, and jumpstart your future. http://p.sf.net/sfu/intel-atom-d2d ___ 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 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 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
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, > >> > >> 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. > > -- -- 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
[Mingw-w64-public] pdh - 32bit
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 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] x64 can't cast ptr to DWORD
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
> #endif
>
>
>
> From: Ozkan Sezer
> To: Jim Michaels
> Cc: mingw64
> Sent: Fri, February 19, 2010 1:28:02 AM
> Subject: Re: [Mingw-w64-public] x64 can't cast ptr to DWORD
>
> On Fri, Feb 19, 2010 at 11:25 AM, Jim Michaels wrote:
> > after much difficulty trying to get subscribed to the list, here is my
> > question.
> >
> > #define CAST(x) reinterpret_cast( x )
> > or
> > #define CAST(x) (DWORD)( x )
> > ...
> > // All msdos data structures must be packed on a 1 byte boundary
> > #pragma pack (1)
> > struct {
> > DWORD StartingSector ;
> > WORD NumberOfSectors ;
> > DWORD pBuffer;
> > } ControlBlock;
> > #pragma pack ()
> > ...
> > ControlBlock.pBuffer = CAST(buffer) ;
> >
> > "dgeomlib.cpp:178: error: cast from 'unsigned char*' to 'DWORD' loses
> > precision"
> >
> > this only occurs on 64-bit target compiler.
> > how can I circumvent?
>
> Use DWORD_PTR instead.
>
> > or, how can I use ifdefs to disable this windows 9x code only for x64 target
> > (obviously the x64-output compiler must have some sort of #define?)?
> >
>
> #ifdef _WIN64 ... #endif should do?
>
> >
> > Jim Michaels
> > jmich...@yahoo.com(main)
> > JesusnJim.com (my site)
>
> --
> Ozkan
> I don't think it's going to fit in 32 bits.
>
>
>
> --
> Download Intel® Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> ___
> Mingw-w64-public mailing list
> Mingw-w64-public@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
>
--
Download Intel® Parallel Studio Eval
Try the new software tools for yourself. Speed compiling, find bugs
proactively, and fine-tune applications for parallel performance.
See why Intel Parallel Studio got high marks during beta.
http://p.sf.net/sfu/intel-sw-dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
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, 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 files in svn...
>> > But you should also checkin an updated version of aclocal.m4.
>> Well, this is a decision we made, that we want to provide the use of
>> configure without the need of having proper autotools installed. So we
>> maintain also the pre-generated files in repository.
>> But I don't see the issue that aclocal.m4 isn't updated? I regenerated
>> it an had no differences to repository.
>>
>> I hope you had some good high days.
>>
>> Cheers,
>> Kai
>> --
>> | (\_/) This is Bunny. Copy and paste
>> | (='.'=) Bunny into your signature to help
>> | (")_(") him gain world domination
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
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 files in svn...
> > But you should also checkin an updated version of aclocal.m4.
> Well, this is a decision we made, that we want to provide the use of
> configure without the need of having proper autotools installed. So we
> maintain also the pre-generated files in repository.
> But I don't see the issue that aclocal.m4 isn't updated? I regenerated
> it an had no differences to repository.
>
> I hope you had some good high days.
>
> Cheers,
> Kai
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
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 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.
>
>
> Hello Alon,
>
> thanks for the patch. I've applied it at revision 1683 with ChangeLog entry
>
> 2009-12-24 Alon Bar-Lev
>
> * Makefile.am (gendef_SOURCES): Add src/compat_string.c file.
> * configure.ac (AC_CHECK_FUNCS): Check for strlwr.
> * src/compat-string.h: New header.
> * sre/compat_string.c: New source-file.
> * Makefile.in: Regenerated.
> * config.h.in: Likewise.
> * configure: Likewise.
>
> Is this ok for you?
>
> Cheers,
> Kai
>
>
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
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 any dependencies to Windows specific runtime.
>
> Almost true... :)
> Attached a patch.
>
> Alon.
>
Just another note...
The following line in Makefile.am:
gendef_CFLAGS = -O3 -g -Werror -Wall -Wextra
is somewhat none standard... Let autoconf do this work...
Replace with something like this in configure.ac:
AC_ARG_WITH([strict], [AS_HELP_STRING[--with-strict],[enable strict
compiler warnings]),,[with_strict="no"])
test with_strict = "yes" && CFLAGS="${CFLAGS} -Werror -Wall -Wextra"
Alon.
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
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 --git a/Makefile.am b/Makefile.am
index 1fe0933..8ccf260 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -3,6 +3,6 @@ bin_PROGRAMS = gendef
gendef_LIBS = @LIBMANGLE_LIB@
gendef_CPPFLAGS = @LIBMANGLE_CPPFLAGS@
gendef_LDFLAGS = @LIBMANGLE_LDFLAGS@
-gendef_SOURCES = src/gendef.h src/gendef.c src/gendef_def.c
+gendef_SOURCES = src/gendef.h src/gendef.c src/gendef_def.c src/compat_string.c
gendef_CFLAGS = -O3 -g -Werror -Wall -Wextra
diff --git a/configure.ac b/configure.ac
index 3d00cab..85dbc35 100644
--- a/configure.ac
+++ b/configure.ac
@@ -32,7 +32,7 @@ AC_TYPE_UINT8_T
# is not available, it places in config.h the define of malloc as
# rpl_malloc. By this linkage could fail on cross-compiles.
#AC_FUNC_MALLOC
-AC_CHECK_FUNCS([memset strdup strrchr])
+AC_CHECK_FUNCS([memset strdup strrchr strlwr])
# Check for libmangle
libmangle_h=no
diff --git a/src/compat-string.h b/src/compat-string.h
new file mode 100644
index 000..769f750
--- /dev/null
+++ b/src/compat-string.h
@@ -0,0 +1,8 @@
+#ifndef __COMPAT_STRING_H
+#define __COMPAT_STRING_H
+
+#ifndef HAVE_STRLWER
+char *strlwr(char *s);
+#endif /* HAVE_STRLWER */
+
+#endif /* __COMPAT_STRING_H */
diff --git a/src/compat_string.c b/src/compat_string.c
new file mode 100644
index 000..fbf36d9
--- /dev/null
+++ b/src/compat_string.c
@@ -0,0 +1,19 @@
+#ifdef CONFIG_H
+#include
+#endif
+
+#ifndef HAVE_STRLWER
+
+#include
+#include "compat-string.h"
+
+char *strlwr(char *s) {
+ while(*s != '\x0') {
+ *s = tolower(*s);
+ s++;
+ }
+
+ return s;
+}
+
+#endif /* HAVE_STRLWER */
diff --git a/src/gendef.c b/src/gendef.c
index 6addc14..c5afd8a 100644
--- a/src/gendef.c
+++ b/src/gendef.c
@@ -28,6 +28,7 @@
#include
#include
#include
+#include "compat-string.h"
#include "gendef.h"
#ifdef HAVE_LIBMANGLE_H
#include
diff --git a/src/gendef_def.c b/src/gendef_def.c
index 156369a..09ac82e 100644
--- a/src/gendef_def.c
+++ b/src/gendef_def.c
@@ -29,6 +29,7 @@
#include
#include
#include
+#include "compat-string.h"
#include "gendef.h"
typedef struct sImpDef {
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Simplifying new def addition
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 great if this process was much simpler... Add pdh.def into mingw-w64-crt/lib32 and that's it. Of course this applies for "simple" defs. It can be done easily using autoconf... It can do something like: autoconf: --- LIB32_LIBS="$(echo $((cd mingw-w64-crt && find lib32 -name '*.def' ) | sed 's#\([^/]*\)\.def#lib\1.a#'))" AC_SUBST([LIB32_LIBS]) --- automake: --- lib32_SCRIPTS = @LIB32_LIBS@ --- What do you think? Alon. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
Oh... For the comment I understand that you did not fully understand
the reason for failure...
For testing if the malloc is gnu malloc or not a autoconf must try to
*RUN* a program...
---
int
main ()
{
return ! malloc (0);
;
return 0;
}
---
The problem is that when you cross compile autoconf cannot run any
program, so it cannot detect malloc variant. So using this macro
usually breaks cross compiling.
Now I understand why I have some issues that you don't have... you run
on Windows while I cross-compile all my programs in Linux... :)
Alon.
On Wed, Dec 23, 2009 at 3:29 PM, Kai 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 line leads to an build error for you?
>>
>> Yes... It is needed.
>> Once the autoconf detects that gnu malloc is not available, it place
>> #define malloc rpl_malloc in config.h.
>> You do not have rpl_malloc in sources so linkage fail.
>>
>> Alon.
>>
>
> Ok fixed. Thanks for the explaination.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
Great! It works. But... Why there is a huge difference between lib64 and lib32 libraries? I see that lib32 contains only 142 libraries while lib64 contains 2042. For example libpdh is missing in lib32. On Wed, Dec 23, 2009 at 12:57 PM, Kai Tietz wrote: > 2009/12/22 Kai Tietz : >> 2009/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 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 is 4.4.2. >>>>> >>>>> x86_64-w64-mingw32 compiles OK. >>>>> >>>>> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: >>>>> error: conflicting types for ‘_mm_shuffle_ps’ >>>>> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: >>>>> previous definition of ‘_mm_shuffle_ps’ was here >>>>> make[1]: *** [intrincs/lib32_libmingwex_a-readfsword.o] Error 1 >>>>> make[1]: *** Waiting for unfinished jobs >>>>> In file included from intrincs/readfsbyte.c:1: >>>>> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: >>>>> error: conflicting types for ‘_mm_shuffle_ps’ >>>>> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: >>>>> previous definition of ‘_mm_shuffle_ps’ was here >>>>> make[1]: *** [intrincs/lib32_libmingwex_a-readfsbyte.o] Error 1 >>>>> In file included from intrincs/readfsdword.c:1: >>>>> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: >>>>> error: conflicting types for ‘_mm_shuffle_ps’ >>>>> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: >>>>> previous definition of ‘_mm_shuffle_ps’ was here >>>>> make[1]: *** [intrincs/lib32_libmingwex_a-readfsdword.o] Error 1 >>>>> make[1]: Leaving directory >>>>> `/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/trunk/mingw-w64-crt' >>>>> make: *** [all] Error 2 >>>>> >>>>> -- >>>>> This SF.Net email is sponsored by the Verizon Developer Community >>>>> Take advantage of Verizon's best-in-class app development support >>>>> A streamlined, 14 day to market process makes app distribution fast and >>>>> easy >>>>> Join now and get one step closer to millions of Verizon customers >>>>> http://p.sf.net/sfu/verizon-dev2dev >>>>> ___ >>>>> Mingw-w64-public mailing list >>>>> Mingw-w64-public@lists.sourceforge.net >>>>> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >>>>> >>>> >>>> Yes, i686 should be supported and I am curious about this warning, but >>>> well, you are using 4.4.2 gcc. >>>> I'll try to find out where this issue comes from and then prepare a >>>> fix for this. >>>> >>>> Cheers, >>>> Kai >>> >>> Which gcc should I use? >>> >> >> Well, 4.4.2 isn't bad. But the upcoming 4.4.3 has some bug-fixes maybe >> worth to have. >> >> Cheers, >> Kai > > So ... The issue is reasoned by a prototype. This function has args > (__m128,__m128,int const) and not as we wrote (__m128,__m128,unsigned > int). > > Does the following patch fixes your problem? (I tried to reproduce > this error, but hadn't luck. > > Cheers, > Kai > > Index: intrin.h > === > --- intrin.h (revision 1670) > +++ intrin.h (working copy) > @@ -582,7 +582,7 @@ > __MACHINEX86X_NOWIN64(__m64 _mm_cvtt_ps2pi(__m128)) > __MACHINEX86X_NOIA64(__m128 _mm_cvt_si2ss(__m128,int)) > __MACHINEX86X_NOWIN64(__m128 _mm_cvt_pi2ps(__m128,__m64)) > - __
Re: [Mingw-w64-public] Compiling win32 compiler fails
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 malloc is not available, it place #define malloc rpl_malloc in config.h. You do not have rpl_malloc in sources so linkage fail. Alon. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
OK.
Thanks.
I had to fixup the gendef...
1. You check for gnu compliant malloc but not define the rpl_malloc,
so I removed this check.
2. You treat warnings as errors and do not eliminate unused parameters.
Attached is a patch.
Alon
On Wed, Dec 23, 2009 at 2:28 PM, Kai Tietz wrote:
> 2009/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.
>>
>> For example libpdh is missing in lib32.
>
> Well, for 64-bit we generated those import libraries by gendef tool.
> For 32-bit we took as initial set the .def files from mingw.org (we
> extended already some of them). So if you want to have specific import
> libraries generated, feel free to use our gendef tool on this DLL and
> review if the imports described are matching. If you want to provide
> your generated .def file(s) and that it becomes part of default crt
> build, be welcome to post the .def file for x86.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
gendef.patch
Description: Binary data
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev ___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] __attribute__((format(printf,....)) issue
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)));
>>
>> 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
>
> This is reasoned by the definition of _POSIX. In this case printf gets
> redefined to __mingw_printf, which is used later in your formatter
> ((format (printf, 1,2))) ...
> Use instead of printf in formatter the __printf__ keyword, this fixes
> your problem.
>
> Cheers,
> Kai
>
> --
> | (\_/) This is Bunny. Copy and paste
> | (='.'=) Bunny into your signature to help
> | (")_(") him gain world domination
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf %ll
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 runtimes don't. > By specifying _POSIX, or by defining __MINGW_USE_ANSI_STDIO=1, you can > use the POSIX emulation printf functions, which are supporting %ll > (and also %Lg, etc). But be aware that just the printf functions are > currently emulated, not the scanf ones. Thanks! This exactly what I intended to do, but could not use _POSIX. So I will use -D__USE_MINGW_ANSI_STDIO=1 Great. Alon. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Compiling win32 compiler fails
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. >> >> While trying to do so, I get the following... And indeed the >> declaration is duplicated. >> I tested both v1.0 and trunk snapshots, gcc is 4.4.2. >> >> x86_64-w64-mingw32 compiles OK. >> >> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: >> error: conflicting types for ‘_mm_shuffle_ps’ >> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: >> previous definition of ‘_mm_shuffle_ps’ was here >> make[1]: *** [intrincs/lib32_libmingwex_a-readfsword.o] Error 1 >> make[1]: *** Waiting for unfinished jobs >> In file included from intrincs/readfsbyte.c:1: >> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: >> error: conflicting types for ‘_mm_shuffle_ps’ >> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: >> previous definition of ‘_mm_shuffle_ps’ was here >> make[1]: *** [intrincs/lib32_libmingwex_a-readfsbyte.o] Error 1 >> In file included from intrincs/readfsdword.c:1: >> /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: >> error: conflicting types for ‘_mm_shuffle_ps’ >> /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: >> previous definition of ‘_mm_shuffle_ps’ was here >> make[1]: *** [intrincs/lib32_libmingwex_a-readfsdword.o] Error 1 >> make[1]: Leaving directory >> `/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/trunk/mingw-w64-crt' >> make: *** [all] Error 2 >> >> -- >> This SF.Net email is sponsored by the Verizon Developer Community >> Take advantage of Verizon's best-in-class app development support >> A streamlined, 14 day to market process makes app distribution fast and easy >> Join now and get one step closer to millions of Verizon customers >> http://p.sf.net/sfu/verizon-dev2dev >> ___ >> Mingw-w64-public mailing list >> Mingw-w64-public@lists.sourceforge.net >> https://lists.sourceforge.net/lists/listinfo/mingw-w64-public >> > > Yes, i686 should be supported and I am curious about this warning, but > well, you are using 4.4.2 gcc. > I'll try to find out where this issue comes from and then prepare a > fix for this. > > Cheers, > Kai Which gcc should I use? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf %ll
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 instance, GLib has G_GINT64_FORMAT. And then there is Java. > > --tml > Funny... :) Had I could do what I need in Java I would have... I don't understand why the gcc was modified to stop recognizing %ll even if mingw emulation is used, which suppose to provide %ll, right? -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] __attribute__((format(printf,....)) issue
#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
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] printf %ll
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 don't. (They all support %I64d.) Use PRId64 etc from > , that's what they are there for. > > --tml > Thanks! But this is *UGLY* And I don't have inttypes.h on all platforms... For example solaris8 does not define these constants. -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] printf %ll
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 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] time.h (POSIX) _r functions
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)); \
if (___tmp_tm) \
*(_Tm) = *___tmp_tm; \
else *(_Tm) = 0;\
___tmp_tm; })
#define localtime_r_2(_Time, _Tm) (localtime ((_Time)) ? *(_Tm) =
*localtime ((_Time),(_Tm)) : 0)
int main(void) {
time_t t1;
struct tm tm1;
localtime_r_1(&t1, &tm1);
localtime_r_2(&t1, &tm1);
}
$ x86_64-w64-mingw32-gcc -pedantic /tmp/time.c
/tmp/time.c: In function ‘main’:
/tmp/time.c:15: error: incompatible types when assigning to type
‘struct tm’ from type ‘int’
/tmp/time.c:15: warning: ISO C forbids braced-groups within expressions
/tmp/time.c:16: error: too many arguments to function ‘localtime’
/tmp/time.c:16: error: type mismatch in conditional expression
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Compiling win32 compiler fails
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 is 4.4.2. x86_64-w64-mingw32 compiles OK. /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: error: conflicting types for ‘_mm_shuffle_ps’ /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: previous definition of ‘_mm_shuffle_ps’ was here make[1]: *** [intrincs/lib32_libmingwex_a-readfsword.o] Error 1 make[1]: *** Waiting for unfinished jobs In file included from intrincs/readfsbyte.c:1: /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: error: conflicting types for ‘_mm_shuffle_ps’ /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: previous definition of ‘_mm_shuffle_ps’ was here make[1]: *** [intrincs/lib32_libmingwex_a-readfsbyte.o] Error 1 In file included from intrincs/readfsdword.c:1: /var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/sysroot/usr/i686-w64-mingw32/include/intrin.h:585: error: conflicting types for ‘_mm_shuffle_ps’ /usr/lib/gcc/i686-w64-mingw32/4.4.2/include/xmmintrin.h:716: note: previous definition of ‘_mm_shuffle_ps’ was here make[1]: *** [intrincs/lib32_libmingwex_a-readfsdword.o] Error 1 make[1]: Leaving directory `/var/tmp/cross/i686-w64-mingw32/portage/cross-i686-w64-mingw32/mingw64-runtime-20091222/work/trunk/mingw-w64-crt' make: *** [all] Error 2 -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Missing http.h::_HTTP_DATA_CHUNK_TYPE::HttpDataChunkFromFragmentCacheEx
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. One is our > current trunk version and the second is the snapshot of our v1.0 > release branch. > > Regards, > Kai -- This SF.Net email is sponsored by the Verizon Developer Community Take advantage of Verizon's best-in-class app development support A streamlined, 14 day to market process makes app distribution fast and easy Join now and get one step closer to millions of Verizon customers http://p.sf.net/sfu/verizon-dev2dev ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Missing http.h::_HTTP_DATA_CHUNK_TYPE::HttpDataChunkFromFragmentCacheEx
Thanks!
When are you going to publish a new snapshot?
Current snapshot is mingw-w64-snapshot-20090419.tar.bz2 and is it very old.
Vapier, the lord of toolchain in Gentoo, recently added out-of-the-box
support for mingw64... However he will only use formal snapshots for
the runtime.
Can you 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_CHUNK_TYPE {
>> HttpDataChunkFromMemory,HttpDataChunkFromFileHandle,
>> HttpDataChunkFromFragmentCache,HttpDataChunkFromFragmentCacheEx,
>> HttpDataChunkMaximum
>> } HTTP_DATA_CHUNK_TYPE,*PHTTP_DATA_CHUNK_TYPE;
>>
>>
>> Thanks!
>
> Thanks for the missing constant. I can confirm by genidl and msdn, that we
> missed this constant.
> I've added it to trunk version at revision 1670.
>
> 2009-12-22 Kai Tietz
>
> * http.h (HTTP_DATA_CHUNK_TYPE): Add
> HttpDataChunkFromFragmentCacheEx.
>
>
> Cheers,
> Kai
>
> | (\_/) This is Bunny. Copy and paste Bunny
> | (='.'=) into your signature to help him gain
> | (")_(") world domination.
>
>
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] Missing http.h::_HTTP_DATA_CHUNK_TYPE::HttpDataChunkFromFragmentCacheEx
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!
--
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] setjmp/longjmp issue
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! -- ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Can't build compiler using script
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 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 errors out with: > > > > /home/erikd/mingw-w64/Toolchain/x86_64-pc-mingw32/bin/ld: dllcrt2.o: > > No such file: No such file or directory > > collect2: ld returned 1 exit status > > make[2]: *** [libgcc_s.dll] Error 1 > > make[2]: Leaving directory > `/home/erikd/mingw-w64/Build/gcc/x86_64-pc-mingw32/libgcc' > > make[1]: *** [all-target-libgcc] Error 2 > > make[1]: Leaving directory `/home/erikd/mingw-w64/Build/gcc' > > make: *** [all] Error 2 > > FATAL: gcc.make > > > > > > Any ideas why? > > > > Cheers, > > Erik > > -- > > - > > Erik de Castro Lopo > > - > > "Powershell is slow. Exceedingly slow. I didn't think speed would be > > a factor in a shell until I used Powershell. The Unix shell tools are > > literally hundreds, if not thousands of times faster than the equivalent > > Powershell commands." > > -- http://reddit.com/r/programming/info/6cgne/comments/c03h3h7 > > > > - > > This SF.Net email is sponsored by the Moblin Your Move Developer's > challenge > > Build the coolest Linux based applications with Moblin SDK & win great > prizes > > Grand prize is a trip for two to an Open Source event anywhere in the > world > > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > > ___ > > Mingw-w64-public mailing list > > Mingw-w64-public@lists.sourceforge.net > > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > > > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Can't build compiler using script
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 errors out with: > > /home/erikd/mingw-w64/Toolchain/x86_64-pc-mingw32/bin/ld: dllcrt2.o: > No such file: No such file or directory > collect2: ld returned 1 exit status > make[2]: *** [libgcc_s.dll] Error 1 > make[2]: Leaving directory > `/home/erikd/mingw-w64/Build/gcc/x86_64-pc-mingw32/libgcc' > make[1]: *** [all-target-libgcc] Error 2 > make[1]: Leaving directory `/home/erikd/mingw-w64/Build/gcc' > make: *** [all] Error 2 > FATAL: gcc.make > > > Any ideas why? > > Cheers, > Erik > -- > - > Erik de Castro Lopo > - > "Powershell is slow. Exceedingly slow. I didn't think speed would be > a factor in a shell until I used Powershell. The Unix shell tools are > literally hundreds, if not thousands of times faster than the equivalent > Powershell commands." > -- http://reddit.com/r/programming/info/6cgne/comments/c03h3h7 > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] setjmp/longjmp issue
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.cmath/ldexpf.c math/powi.c math/pow.c\ \ misc/mb_wc_common.h \ + misc/mingw_getsp.S \ misc/alarm.cmisc/fesetenv.c misc/mbsinit.c misc/wcstold.c\ misc/btowc.cmisc/fesetexceptflag.c misc/mingw-aligned-malloc.c misc/wcstoumax.c \ misc/ctime.cmisc/fesetround.c misc/mingw-fseek.c misc/wctob.c \ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] setjmp/longjmp issue
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?
> >
> > 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 itself?
> >
> > Yes.
> > Build script is at [1]. Using binutils CVS head, gcc-4.2.3, mingw-w64 svn
> trunk.
> >
> > Thanks!
> > Alon.
> >
> > [1] http://www.opensc-project.org/build/browser/trunk/mingw64
> >
>
>
> Shouldn't be the line 'ln -s "${CHOST}" "${SYSROOT}/mingw" || die
> "ln"' be 'ln -s "${SYSROOT}/${CHOST}" "${SYSROOT}/mingw" || die "ln"'
> ?
>
> Maybe this is the problem you have.
>
I do this in two stages.
But I fixed this now if you think it is more correct this way.
I have no problem with any other API except of the setjmp/longjmp...
If I remove these from OpenSC code OpenSSL, zlib, OpenSC complies OK.
I am sure that all worked in the past with the same build of
toolchain... So something must have changed.
Thanks,
Alon.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] setjmp/longjmp issue
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 itself? Yes. Build script is at [1]. Using binutils CVS head, gcc-4.2.3, mingw-w64 svn trunk. Thanks! Alon. [1] http://www.opensc-project.org/build/browser/trunk/mingw64 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] setjmp/longjmp issue
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.c:(.text+0x2a): undefined reference to `_longjmp'
collect2: ld returned 1 exit status
Using i686-pc-mingw32 it compiles.
Any clue?
Using:
binutils CVS head
gcc-4.2.3
mingw-w64 svn trunk
Alon.
-
This SF.Net email is sponsored by the Moblin Your Move Developer's challenge
Build the coolest Linux based applications with Moblin SDK & win great prizes
Grand prize is a trip for two to an Open Source event anywhere in the world
http://moblin-contest.org/redirect.php?banner_id=100&url=/
___
Mingw-w64-public mailing list
Mingw-w64-public@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
Re: [Mingw-w64-public] Latest and greatest Linux -> w64 compiler
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: > > > http://sourceforge.net/project/showfiles.php?group_id=202880&package_id=245516&release_id=546049 > > it seems that the latest mingw-w64-bin_i686-linux binary is dated > 20080828. > > So I thought I'd have a look at compiling one myself. I grabbed the > SVN sources and I'm reading the file mingw-w64-howto-build.txt, but > those instructions seem to suggest that I need to install them > somewhere specific like /usr or /usr/local. > > However, what I'd really like is a method of creating a release tarball > much like the one dated 20080828 so that i can compile it once and > install it on many machines. > > How is that release tarball generated? If its a script, does anyone > care to share? > > Cheers, > Erik > -- > - > Erik de Castro Lopo > - > "Anyone who considers arithmetical methods of producing random > digits is, of course, in a state of sin." - John Von Neumann (1951) > > - > This SF.Net email is sponsored by the Moblin Your Move Developer's challenge > Build the coolest Linux based applications with Moblin SDK & win great prizes > Grand prize is a trip for two to an Open Source event anywhere in the world > http://moblin-contest.org/redirect.php?banner_id=100&url=/ > ___ > Mingw-w64-public mailing list > Mingw-w64-public@lists.sourceforge.net > https://lists.sourceforge.net/lists/listinfo/mingw-w64-public > - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] [SUCCESS] OpenSC Project Windows 64
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 order to make it work use binutils CVS head and gcc-4.3.2. binutils heads is required to avoid incorrect DLL linkage. A required patch is available at bug#6987 [5]. The OpenSC build is available at [2], it cross compiles the following components: lzo-2.02 openssl-SNAP-20081023 zlib-1.2.3 libtool-1.5.26 opensc-0.11.6-svn libp11-0.2.4-svn engine_pkcs11-0.1.5-svn pkcs11-helper-1.06 openvpn-2.1_rc13 In order to make libtool detect the pe-x86-64, a fix should be added to ltmain.sh (reported) of every package that uses libtool: sed -i 's/architecture: i386)?'\''/architecture: i386)?|file format pe-x86-64'\''/' ltmain.sh The greatest challenge was OpenSSL, and in order to merge it I think we should address the SIGALRM and other invalid signals that resides in mingw include files. bug#2182468 [3]. It compiles without assembly and without uplink. patch at [4]. It also revealed the binutils issue. In order to compile OpenSC components I am using: EXTRA_OPENSSL_CONFIG="no-asm" \ CHOST=x86_64-pc-mingw32 CBUILD=i686-pc-iinux-gnu \ ./build Thank you for the great work! Alon. [1] http://www.opensc-project.org/build/browser/trunk/mingw64/build [2] http://www.opensc-project.org/build/browser/trunk [3] http://sourceforge.net/tracker/index.php?func=detail&aid=2182468&group_id=202880&atid=983354 [4] http://www.opensc-project.org/build/browser/trunk/patches/openssl-002-SNAP-20081003-mingw64.patch [5] http://sourceware.org/bugzilla/show_bug.cgi?id=6987 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
[Mingw-w64-public] io.h - alarm()
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 coolest Linux based applications with Moblin SDK & win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100&url=/ ___ Mingw-w64-public mailing list Mingw-w64-public@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/mingw-w64-public
