Menu
▾
▴
cegcc-devel — Discussion about CeGCC development
You can subscribe to this list here.
| 2006 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
(2) |
Aug
(63) |
Sep
(78) |
Oct
(111) |
Nov
(104) |
Dec
(39) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(69) |
Feb
(68) |
Mar
(23) |
Apr
(61) |
May
(56) |
Jun
(122) |
Jul
(82) |
Aug
(44) |
Sep
(63) |
Oct
(73) |
Nov
(77) |
Dec
(102) |
| 2008 |
Jan
(34) |
Feb
(51) |
Mar
(39) |
Apr
(43) |
May
(8) |
Jun
(59) |
Jul
(69) |
Aug
(97) |
Sep
(140) |
Oct
(72) |
Nov
(37) |
Dec
(35) |
| 2009 |
Jan
(70) |
Feb
(104) |
Mar
(42) |
Apr
(121) |
May
(161) |
Jun
(109) |
Jul
(90) |
Aug
(85) |
Sep
(104) |
Oct
(59) |
Nov
(76) |
Dec
(145) |
| 2010 |
Jan
(123) |
Feb
(45) |
Mar
(37) |
Apr
(9) |
May
|
Jun
(5) |
Jul
(22) |
Aug
|
Sep
(4) |
Oct
(5) |
Nov
(2) |
Dec
(83) |
| 2011 |
Jan
(19) |
Feb
(33) |
Mar
(14) |
Apr
|
May
|
Jun
(4) |
Jul
|
Aug
|
Sep
|
Oct
(7) |
Nov
(8) |
Dec
(8) |
| 2012 |
Jan
(2) |
Feb
(4) |
Mar
(1) |
Apr
|
May
(5) |
Jun
|
Jul
(1) |
Aug
(1) |
Sep
|
Oct
|
Nov
|
Dec
|
| 2015 |
Jan
|
Feb
|
Mar
(2) |
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
(1) |
Dec
|
|
From: Stefan P. <ste...@gm...> - 2010-12-23 15:37:35
|
>On Thu, 23 Dec 2010, Sébastien Lorquet wrote: >> Hello, >> >> any success with my instructions, or is everyone (including me) too >> busy eating chocolate? :-) > too busy :p Honestly, the compilation is a lot faster on linux than with > MSYS/MinGW > Vincent Yes, unfortunately me too. But I will find time soon i hope. Marry Christmas and a happy new year you, too ;) >> >> BTW, Merry Christmas and Happy new year to all. There are few chances >> that I'll post here on Dec 24. >> >> Sebastien >> >> On Fri, Dec 17, 2010 at 8:09 PM, Sébastien Lorquet <sq...@gm...> wrote: >>> Hi >>> >>> I noticed that our next exchanges did not make it to the list because >>> of the bad handling of lists reply-to by gmail (Harald Welte explained >>> to me that it's a desirable feature, but I always forget to >>> reply-to-all :-) ) >>> >>> Let's fix it. >>> ><> ==================================================================== >>> >>> here are new steps to build mingw32ce for windows from debian. >>> >>> get code >>> >>> cd $HOME >>> mkdir cegcc >>> cd cegcc >>> svn co https://cegcc.svn.sourceforge.net/svnroot/cegcc/trunk cegcc-src >>> wget ftp://ftp.gmplib.org/pub/gmp-4.3.1/gmp-4.3.1.tar.gz >>> wget http://www.mpfr.org/mpfr-2.4.1/mpfr-2.4.1.tar.gz >>> tar zxvf gmp-4.3.1.tar.gz >>> tar zxvf mpfr-2.4.1.tar.gz >>> >>> patch code >>> >>> Here is what you must change in the mingw32ce build script >>> Basically this deals with passing the proper gmp/mpfr options to the >>> gcc configure script. This might be achievable by other means, e.g. >>> environment. >>> >>> svn diff: >>> ><> ---8<--- >>> Index: build-mingw32ce.sh >>> =================================================================== >>> --- build-mingw32ce.sh (revision 1449) >>> +++ build-mingw32ce.sh (working copy) >>> @@ -49,12 +49,17 @@ >>> --components=LIST specify which components to build >>> valid components are: ${COMPONENTS_COMMA_LIST} >>> [all] >>> + --gmp=DIR path to GMP library >>> + --mpfr=DIR path to MPFR library >>> >>> Report bugs to <ceg...@li...>. >>> _ACEOF >>> >>> } >>> >>> +lib_gmp= >>> +lib_mpfr= >>> + >>> ac_prev= >>> for ac_option >>> do >>> @@ -97,6 +102,12 @@ >>> | --co=* | --c=*) >>> components=$ac_optarg ;; >>> >>> + --gmp=*) >>> + lib_gmp=$ac_optarg ;; >>> + >>> + --mpfr=*) >>> + lib_mpfr=$ac_optarg ;; >>> + >>> --host) >>> ac_prev=host ;; >>> --host=*) >>> @@ -179,6 +190,16 @@ >>> exit 1 >>> fi >>> >>> +#compute the options for gmp and mpfr >>> + >>> +GCCDEPS= >>> +if [ "x${lib_gmp}" != "x" ]; then >>> + GCCDEPS="--with-gmp=${lib_gmp}" >>> +fi >>> +if [ "x${lib_gmp}" != "x" ]; then >>> + GCCDEPS="${GCCDEPS} --with-mpfr=${lib_mpfr}" >>> +fi >>> + >>> build_binutils() >>> { >>> echo "" >>> @@ -209,6 +230,7 @@ >>> --with-gcc \ >>> --with-gnu-ld \ >>> --with-gnu-as \ >>> + ${GCCDEPS} \ >>> --target=${TARGET} \ >>> --build=${BUILD} \ >>> --host=${HOST} \ >>> @@ -314,6 +336,7 @@ >>> --target=${TARGET} \ >>> --host=${HOST} \ >>> --prefix=${PREFIX} \ >>> + ${GCCDEPS} \ >>> --enable-threads=win32 \ >>> --disable-nls \ >>> --enable-languages=c,c++ \ >>> @@ -333,6 +356,7 @@ >>> --target=${TARGET} \ >>> --host=${HOST} \ >>> --prefix=${PREFIX} \ >>> + ${GCCDEPS} \ >>> --enable-threads=win32 \ >>> --disable-nls \ >>> --enable-languages=c,c++ \ >>> ---8<--- >>> >>> now we're ready to go. >>> >>> First step is to build a linux mingw32ce, to allow building the target >>> libs (build=host=linux, target=arm-wince-pe) >>> >>> we need some dependencies - you may have them in apt-get, I recompiled >>> to get the same versions as what the final compiler has >>> >>> mkdir depends-linux >>> mkdir gmp-linux >>> cd gmp-linux >>> ../gmp-4.3.1/configure --prefix=`cd ../depends-linux; pwd` >>> make >>> make install >>> cd .. >>> >>> mkdir mpfr-linux >>> cd mpfr-linux >>> ../mpfr-2.4.1/configure --prefix=`cd ../depends-linux; pwd` >>> --with-gmp=`cd ../depends-linux; pwd` >>> make >>> make install >>> cd .. >>> >>> build the compiler and install e.g. to /opt/mingw32ce >>> (target=arm-wince-pe, build=host=linux) >>> This will NOT WORK if you do not set gcc_src=gcc, I don't know what's >>> the problem with gcc 4.4 (you can try, though) >>> >>> mkdir build-linux >>> cd build-linux >>> sudo gcc_src=gcc >>> ../cegcc-src/cegcc/src/scripts/build/build-minw32ce.sh >>> --prefix=/opt/mingw32ce --gmp=`cd ../depends-linux;pwd` --mpfr=`cd >>> ../depends-linux;pwd` >>> cd .. >>> >>> Second step is to cross build the win32 compiler >>> >>> install mingw for linux -- or build it, if you prefer... >>> sudo apt-get install mingw32 >>> >>> the compiler prefix is i586-mingw32msvc- >>> >>> crossbuild dependencies for windows host (build is linux, host is >>> windows, target has no sense (same as host)) >>> >>> mkdir depends-win >>> mkdir gmp-win >>> cd gmp-win >>> ../gmp-4.3.1/configure --host=i586-mingw32msvc --prefix=`cd ../depends-win; pwd` >>> make >>> make install >>> cd .. >>> >>> mkdir mpfr-win >>> cd mpfr-win >>> ../mpfr-2.4.1/configure --host=i586-mingw32msvc --prefix=`cd >>> ../depends-win; pwd` --with-gmp=`cd ../depends-win; pwd` >>> make >>> make install >>> cd .. >>> >>> build cegcc for windows: build=linux, host=windows, target=arm-wince-pe >>> the linux version of the compiler needs to be in the path to build the >>> target libs! >>> Do not forget to update PATH or the build will fail, of course. >>> >>> mkdir INSTALL >>> mkdir build-win >>> cd build-win >>> PATH=/opt/mingw32ce/bin:$PATH >>> export PATH >>> gcc_src=gcc ../cegcc-src/cegcc/src/scripts/build-mingw32ce.sh >>> --prefix=`cd ../INSTALL;pwd` --host=i586-mingw32msvc --gmp=`cd >>> ../depends-win;pwd` --mpfr=`cd ../depends-win;pwd` >>> make >>> make install >>> >>> And here you have a nice arm-wince-pe toolchain for mingw! >>> >>> I'd like some feedback on this process. That's why I'm not posting >>> binaries yet. I want someone else to test that, to check wether that's >>> ok or not. >>> >>> Sebastien >>> >> >> ------------------------------------------------------------------------------ >> Learn how Oracle Real Application Clusters (RAC) One Node allows customers >> to consolidate database storage, standardize their database environment, and, >> should the need arise, upgrade to a full multi-node Oracle RAC database >> without downtime or disruption >> http://p.sf.net/sfu/oracle-sfdevnl >> _______________________________________________ >> Cegcc-devel mailing list >> Ceg...@li... >> https://lists.sourceforge.net/lists/listinfo/cegcc-devel >> >> -- Neu: GMX De-Mail - Einfach wie E-Mail, sicher wie ein Brief! Jetzt De-Mail-Adresse reservieren: http://portal.gmx.net/de/go/demail |
|
From: Vincent T. <vt...@un...> - 2010-12-23 13:06:02
|
On Thu, 23 Dec 2010, Sébastien Lorquet wrote: > Hello, > > any success with my instructions, or is everyone (including me) too > busy eating chocolate? :-) too busy :p Honestly, the compilation is a lot faster on linux than with MSYS/MinGW Vincent > > BTW, Merry Christmas and Happy new year to all. There are few chances > that I'll post here on Dec 24. > > Sebastien > > On Fri, Dec 17, 2010 at 8:09 PM, Sébastien Lorquet <sq...@gm...> wrote: >> Hi >> >> I noticed that our next exchanges did not make it to the list because >> of the bad handling of lists reply-to by gmail (Harald Welte explained >> to me that it's a desirable feature, but I always forget to >> reply-to-all :-) ) >> >> Let's fix it. >> >> ==================================================================== >> >> here are new steps to build mingw32ce for windows from debian. >> >> get code >> >> cd $HOME >> mkdir cegcc >> cd cegcc >> svn co https://cegcc.svn.sourceforge.net/svnroot/cegcc/trunk cegcc-src >> wget ftp://ftp.gmplib.org/pub/gmp-4.3.1/gmp-4.3.1.tar.gz >> wget http://www.mpfr.org/mpfr-2.4.1/mpfr-2.4.1.tar.gz >> tar zxvf gmp-4.3.1.tar.gz >> tar zxvf mpfr-2.4.1.tar.gz >> >> patch code >> >> Here is what you must change in the mingw32ce build script >> Basically this deals with passing the proper gmp/mpfr options to the >> gcc configure script. This might be achievable by other means, e.g. >> environment. >> >> svn diff: >> >> ---8<--- >> Index: build-mingw32ce.sh >> =================================================================== >> --- build-mingw32ce.sh (revision 1449) >> +++ build-mingw32ce.sh (working copy) >> @@ -49,12 +49,17 @@ >> --components=LIST specify which components to build >> valid components are: ${COMPONENTS_COMMA_LIST} >> [all] >> + --gmp=DIR path to GMP library >> + --mpfr=DIR path to MPFR library >> >> Report bugs to <ceg...@li...>. >> _ACEOF >> >> } >> >> +lib_gmp= >> +lib_mpfr= >> + >> ac_prev= >> for ac_option >> do >> @@ -97,6 +102,12 @@ >> | --co=* | --c=*) >> components=$ac_optarg ;; >> >> + --gmp=*) >> + lib_gmp=$ac_optarg ;; >> + >> + --mpfr=*) >> + lib_mpfr=$ac_optarg ;; >> + >> --host) >> ac_prev=host ;; >> --host=*) >> @@ -179,6 +190,16 @@ >> exit 1 >> fi >> >> +#compute the options for gmp and mpfr >> + >> +GCCDEPS= >> +if [ "x${lib_gmp}" != "x" ]; then >> + GCCDEPS="--with-gmp=${lib_gmp}" >> +fi >> +if [ "x${lib_gmp}" != "x" ]; then >> + GCCDEPS="${GCCDEPS} --with-mpfr=${lib_mpfr}" >> +fi >> + >> build_binutils() >> { >> echo "" >> @@ -209,6 +230,7 @@ >> --with-gcc \ >> --with-gnu-ld \ >> --with-gnu-as \ >> + ${GCCDEPS} \ >> --target=${TARGET} \ >> --build=${BUILD} \ >> --host=${HOST} \ >> @@ -314,6 +336,7 @@ >> --target=${TARGET} \ >> --host=${HOST} \ >> --prefix=${PREFIX} \ >> + ${GCCDEPS} \ >> --enable-threads=win32 \ >> --disable-nls \ >> --enable-languages=c,c++ \ >> @@ -333,6 +356,7 @@ >> --target=${TARGET} \ >> --host=${HOST} \ >> --prefix=${PREFIX} \ >> + ${GCCDEPS} \ >> --enable-threads=win32 \ >> --disable-nls \ >> --enable-languages=c,c++ \ >> ---8<--- >> >> now we're ready to go. >> >> First step is to build a linux mingw32ce, to allow building the target >> libs (build=host=linux, target=arm-wince-pe) >> >> we need some dependencies - you may have them in apt-get, I recompiled >> to get the same versions as what the final compiler has >> >> mkdir depends-linux >> mkdir gmp-linux >> cd gmp-linux >> ../gmp-4.3.1/configure --prefix=`cd ../depends-linux; pwd` >> make >> make install >> cd .. >> >> mkdir mpfr-linux >> cd mpfr-linux >> ../mpfr-2.4.1/configure --prefix=`cd ../depends-linux; pwd` >> --with-gmp=`cd ../depends-linux; pwd` >> make >> make install >> cd .. >> >> build the compiler and install e.g. to /opt/mingw32ce >> (target=arm-wince-pe, build=host=linux) >> This will NOT WORK if you do not set gcc_src=gcc, I don't know what's >> the problem with gcc 4.4 (you can try, though) >> >> mkdir build-linux >> cd build-linux >> sudo gcc_src=gcc >> ../cegcc-src/cegcc/src/scripts/build/build-minw32ce.sh >> --prefix=/opt/mingw32ce --gmp=`cd ../depends-linux;pwd` --mpfr=`cd >> ../depends-linux;pwd` >> cd .. >> >> Second step is to cross build the win32 compiler >> >> install mingw for linux -- or build it, if you prefer... >> sudo apt-get install mingw32 >> >> the compiler prefix is i586-mingw32msvc- >> >> crossbuild dependencies for windows host (build is linux, host is >> windows, target has no sense (same as host)) >> >> mkdir depends-win >> mkdir gmp-win >> cd gmp-win >> ../gmp-4.3.1/configure --host=i586-mingw32msvc --prefix=`cd ../depends-win; pwd` >> make >> make install >> cd .. >> >> mkdir mpfr-win >> cd mpfr-win >> ../mpfr-2.4.1/configure --host=i586-mingw32msvc --prefix=`cd >> ../depends-win; pwd` --with-gmp=`cd ../depends-win; pwd` >> make >> make install >> cd .. >> >> build cegcc for windows: build=linux, host=windows, target=arm-wince-pe >> the linux version of the compiler needs to be in the path to build the >> target libs! >> Do not forget to update PATH or the build will fail, of course. >> >> mkdir INSTALL >> mkdir build-win >> cd build-win >> PATH=/opt/mingw32ce/bin:$PATH >> export PATH >> gcc_src=gcc ../cegcc-src/cegcc/src/scripts/build-mingw32ce.sh >> --prefix=`cd ../INSTALL;pwd` --host=i586-mingw32msvc --gmp=`cd >> ../depends-win;pwd` --mpfr=`cd ../depends-win;pwd` >> make >> make install >> >> And here you have a nice arm-wince-pe toolchain for mingw! >> >> I'd like some feedback on this process. That's why I'm not posting >> binaries yet. I want someone else to test that, to check wether that's >> ok or not. >> >> Sebastien >> > > ------------------------------------------------------------------------------ > Learn how Oracle Real Application Clusters (RAC) One Node allows customers > to consolidate database storage, standardize their database environment, and, > should the need arise, upgrade to a full multi-node Oracle RAC database > without downtime or disruption > http://p.sf.net/sfu/oracle-sfdevnl > _______________________________________________ > Cegcc-devel mailing list > Ceg...@li... > https://lists.sourceforge.net/lists/listinfo/cegcc-devel > > |
|
From: Sébastien L. <sq...@gm...> - 2010-12-23 08:32:22
|
Hello, any success with my instructions, or is everyone (including me) too busy eating chocolate? :-) BTW, Merry Christmas and Happy new year to all. There are few chances that I'll post here on Dec 24. Sebastien On Fri, Dec 17, 2010 at 8:09 PM, Sébastien Lorquet <sq...@gm...> wrote: > Hi > > I noticed that our next exchanges did not make it to the list because > of the bad handling of lists reply-to by gmail (Harald Welte explained > to me that it's a desirable feature, but I always forget to > reply-to-all :-) ) > > Let's fix it. > > ==================================================================== > > here are new steps to build mingw32ce for windows from debian. > > get code > > cd $HOME > mkdir cegcc > cd cegcc > svn co https://cegcc.svn.sourceforge.net/svnroot/cegcc/trunk cegcc-src > wget ftp://ftp.gmplib.org/pub/gmp-4.3.1/gmp-4.3.1.tar.gz > wget http://www.mpfr.org/mpfr-2.4.1/mpfr-2.4.1.tar.gz > tar zxvf gmp-4.3.1.tar.gz > tar zxvf mpfr-2.4.1.tar.gz > > patch code > > Here is what you must change in the mingw32ce build script > Basically this deals with passing the proper gmp/mpfr options to the > gcc configure script. This might be achievable by other means, e.g. > environment. > > svn diff: > > ---8<--- > Index: build-mingw32ce.sh > =================================================================== > --- build-mingw32ce.sh (revision 1449) > +++ build-mingw32ce.sh (working copy) > @@ -49,12 +49,17 @@ > --components=LIST specify which components to build > valid components are: ${COMPONENTS_COMMA_LIST} > [all] > + --gmp=DIR path to GMP library > + --mpfr=DIR path to MPFR library > > Report bugs to <ceg...@li...>. > _ACEOF > > } > > +lib_gmp= > +lib_mpfr= > + > ac_prev= > for ac_option > do > @@ -97,6 +102,12 @@ > | --co=* | --c=*) > components=$ac_optarg ;; > > + --gmp=*) > + lib_gmp=$ac_optarg ;; > + > + --mpfr=*) > + lib_mpfr=$ac_optarg ;; > + > --host) > ac_prev=host ;; > --host=*) > @@ -179,6 +190,16 @@ > exit 1 > fi > > +#compute the options for gmp and mpfr > + > +GCCDEPS= > +if [ "x${lib_gmp}" != "x" ]; then > + GCCDEPS="--with-gmp=${lib_gmp}" > +fi > +if [ "x${lib_gmp}" != "x" ]; then > + GCCDEPS="${GCCDEPS} --with-mpfr=${lib_mpfr}" > +fi > + > build_binutils() > { > echo "" > @@ -209,6 +230,7 @@ > --with-gcc \ > --with-gnu-ld \ > --with-gnu-as \ > + ${GCCDEPS} \ > --target=${TARGET} \ > --build=${BUILD} \ > --host=${HOST} \ > @@ -314,6 +336,7 @@ > --target=${TARGET} \ > --host=${HOST} \ > --prefix=${PREFIX} \ > + ${GCCDEPS} \ > --enable-threads=win32 \ > --disable-nls \ > --enable-languages=c,c++ \ > @@ -333,6 +356,7 @@ > --target=${TARGET} \ > --host=${HOST} \ > --prefix=${PREFIX} \ > + ${GCCDEPS} \ > --enable-threads=win32 \ > --disable-nls \ > --enable-languages=c,c++ \ > ---8<--- > > now we're ready to go. > > First step is to build a linux mingw32ce, to allow building the target > libs (build=host=linux, target=arm-wince-pe) > > we need some dependencies - you may have them in apt-get, I recompiled > to get the same versions as what the final compiler has > > mkdir depends-linux > mkdir gmp-linux > cd gmp-linux > ../gmp-4.3.1/configure --prefix=`cd ../depends-linux; pwd` > make > make install > cd .. > > mkdir mpfr-linux > cd mpfr-linux > ../mpfr-2.4.1/configure --prefix=`cd ../depends-linux; pwd` > --with-gmp=`cd ../depends-linux; pwd` > make > make install > cd .. > > build the compiler and install e.g. to /opt/mingw32ce > (target=arm-wince-pe, build=host=linux) > This will NOT WORK if you do not set gcc_src=gcc, I don't know what's > the problem with gcc 4.4 (you can try, though) > > mkdir build-linux > cd build-linux > sudo gcc_src=gcc > ../cegcc-src/cegcc/src/scripts/build/build-minw32ce.sh > --prefix=/opt/mingw32ce --gmp=`cd ../depends-linux;pwd` --mpfr=`cd > ../depends-linux;pwd` > cd .. > > Second step is to cross build the win32 compiler > > install mingw for linux -- or build it, if you prefer... > sudo apt-get install mingw32 > > the compiler prefix is i586-mingw32msvc- > > crossbuild dependencies for windows host (build is linux, host is > windows, target has no sense (same as host)) > > mkdir depends-win > mkdir gmp-win > cd gmp-win > ../gmp-4.3.1/configure --host=i586-mingw32msvc --prefix=`cd ../depends-win; pwd` > make > make install > cd .. > > mkdir mpfr-win > cd mpfr-win > ../mpfr-2.4.1/configure --host=i586-mingw32msvc --prefix=`cd > ../depends-win; pwd` --with-gmp=`cd ../depends-win; pwd` > make > make install > cd .. > > build cegcc for windows: build=linux, host=windows, target=arm-wince-pe > the linux version of the compiler needs to be in the path to build the > target libs! > Do not forget to update PATH or the build will fail, of course. > > mkdir INSTALL > mkdir build-win > cd build-win > PATH=/opt/mingw32ce/bin:$PATH > export PATH > gcc_src=gcc ../cegcc-src/cegcc/src/scripts/build-mingw32ce.sh > --prefix=`cd ../INSTALL;pwd` --host=i586-mingw32msvc --gmp=`cd > ../depends-win;pwd` --mpfr=`cd ../depends-win;pwd` > make > make install > > And here you have a nice arm-wince-pe toolchain for mingw! > > I'd like some feedback on this process. That's why I'm not posting > binaries yet. I want someone else to test that, to check wether that's > ok or not. > > Sebastien > |
|
From: SourceForge.net <no...@so...> - 2010-12-22 17:32:48
|
Bugs item #3141753, was opened at 2010-12-22 16:20 Message generated for change (Comment added) made by pedroalves You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3141753&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW32CE (arm-wince-mingw32ce Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcus Brinkmann (marcus-b) Assigned to: Nobody/Anonymous (nobody) Summary: IAT address calculated wrongly Initial Comment: According to the PE/COFF spec, the IAT address must be relative to the image base (as other entries in the DataDirectory). This patch fixes the calculation. ---------------------------------------------------------------------- >Comment By: Pedro Alves (pedroalves) Date: 2010-12-22 17:32 Message: Thanks. Can you please post this at bin...@so... instead? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3141753&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2010-12-22 16:20:52
|
Bugs item #3141753, was opened at 2010-12-22 17:20 Message generated for change (Tracker Item Submitted) made by marcus-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3141753&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW32CE (arm-wince-mingw32ce Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcus Brinkmann (marcus-b) Assigned to: Nobody/Anonymous (nobody) Summary: IAT address calculated wrongly Initial Comment: According to the PE/COFF spec, the IAT address must be relative to the image base (as other entries in the DataDirectory). This patch fixes the calculation. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3141753&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2010-12-22 16:19:34
|
Bugs item #3141752, was opened at 2010-12-22 17:19 Message generated for change (Tracker Item Submitted) made by marcus-b You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3141752&group_id=173455 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: MinGW32CE (arm-wince-mingw32ce Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Marcus Brinkmann (marcus-b) Assigned to: Nobody/Anonymous (nobody) Summary: idata5 MUST NOT be in .rdata Initial Comment: idata5 must be writable, because it contains the addresses of imported symbols. cegcc currently places them in .rdata. The system happily accepts that and fills in the addresses of imported symbols, but under memory pressure the page can be evicted (it's "rdata" after all), and when it is loaded back from storage the address of the imported symbols on this page are gone. The problem is only visible under memory pressure, when the application suddenly starts to crash when calling library functions. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3141752&group_id=173455 |
|
From: Paul S. <pm...@gm...> - 2010-12-21 12:34:50
|
Hello, On Tue, 21 Dec 2010 07:17:25 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > > On Tue, 21 Dec 2010, Paul Sokolovsky wrote: > > > Hello, > > > > On Tue, 21 Dec 2010 02:24:27 +0200 > > Paul Sokolovsky <pm...@gm...> wrote: > > > >> [] (should be linked from wiki)? > > > > On a second thought: > > > > I already started some wiki cleanup, but: sf.net's native tracker is > > apparently not up to the day. But there's Trac hosted app, and Trac > > hopefully is well-known and easy on its own. But it also has wiki, > > and it makes sense to keep everything in one place for ease of > > maintenance and cross-reference. So, maybe, until mediawiki grows > > in content, activate and migrate to Trac? > > I like Trac as a user. Except that it is written in python :) If you > know python and php well, then there should be no problem for you Thanks. Well, I like both Trac and Python ;-). But I would like to avoid tool flip-flops, so argument is that having integrated tool for wiki and bugs will allow for more seamless usage and maintenance. As for Python knowledge, it shouldn't be immediately required - Trac instance will be maintained by SourceForge. > > Vincent Torri > -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2010-12-21 12:26:37
|
Hello, On Tue, 21 Dec 2010 07:15:23 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > > On Tue, 21 Dec 2010, Paul Sokolovsky wrote: > > > Hello, > > > > I was added as a member to cegcc project, thanks Danny! Going to > > start some clean up work, and first question I have is about > > project docs. There appears to be 2 sets: > > > > 1. http://cegcc.sourceforge.net/documentation.html - This is what > > linked by "Development" on cegcc.sf.net > > 2. http://cegcc.sourceforge.net/docs/ - this is what I have in > > completion db of my browser, possible from old time. > > > > Which one is current (should be linked from wiki)? Should the other > > copy be removed? > > Normally, the first link is what Danny did when re-writing the cegcc > website. Hence it should be more or less a copy of the second link. > Just verify it is a copy :) Yes, now I looked closer and see that they indeed have identical content vs style. I also guess docs/index.html come directly from SVN, so is the master copy, while documentation.html conversion to site's style. > > regards > > Vincent Torri -- Best regards, Paul mailto:pm...@gm... |
|
From: Vincent T. <vt...@un...> - 2010-12-21 06:17:32
|
On Tue, 21 Dec 2010, Paul Sokolovsky wrote: > Hello, > > On Tue, 21 Dec 2010 02:24:27 +0200 > Paul Sokolovsky <pm...@gm...> wrote: > >> [] (should be linked from wiki)? > > On a second thought: > > I already started some wiki cleanup, but: sf.net's native tracker is > apparently not up to the day. But there's Trac hosted app, and Trac > hopefully is well-known and easy on its own. But it also has wiki, and > it makes sense to keep everything in one place for ease of maintenance > and cross-reference. So, maybe, until mediawiki grows in content, > activate and migrate to Trac? I like Trac as a user. Except that it is written in python :) If you know python and php well, then there should be no problem for you Vincent Torri |
|
From: Vincent T. <vt...@un...> - 2010-12-21 06:15:31
|
On Tue, 21 Dec 2010, Paul Sokolovsky wrote: > Hello, > > I was added as a member to cegcc project, thanks Danny! Going to start > some clean up work, and first question I have is about project docs. > There appears to be 2 sets: > > 1. http://cegcc.sourceforge.net/documentation.html - This is what > linked by "Development" on cegcc.sf.net > 2. http://cegcc.sourceforge.net/docs/ - this is what I have in > completion db of my browser, possible from old time. > > Which one is current (should be linked from wiki)? Should the other > copy be removed? Normally, the first link is what Danny did when re-writing the cegcc website. Hence it should be more or less a copy of the second link. Just verify it is a copy :) regards Vincent Torri |
|
From: Paul S. <pm...@gm...> - 2010-12-21 01:12:45
|
Hello, On Tue, 21 Dec 2010 02:24:27 +0200 Paul Sokolovsky <pm...@gm...> wrote: >[] (should be linked from wiki)? On a second thought: I already started some wiki cleanup, but: sf.net's native tracker is apparently not up to the day. But there's Trac hosted app, and Trac hopefully is well-known and easy on its own. But it also has wiki, and it makes sense to keep everything in one place for ease of maintenance and cross-reference. So, maybe, until mediawiki grows in content, activate and migrate to Trac? -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2010-12-21 00:24:43
|
Hello, I was added as a member to cegcc project, thanks Danny! Going to start some clean up work, and first question I have is about project docs. There appears to be 2 sets: 1. http://cegcc.sourceforge.net/documentation.html - This is what linked by "Development" on cegcc.sf.net 2. http://cegcc.sourceforge.net/docs/ - this is what I have in completion db of my browser, possible from old time. Which one is current (should be linked from wiki)? Should the other copy be removed? -- Best regards, Paul mailto:pm...@gm... |
|
From: Danny B. <dan...@sc...> - 2010-12-18 15:57:14
|
On Sat, 2010-12-18 at 17:52 +0200, Paul Sokolovsky wrote: > Well, #ifdef is 2 lines => bigger patches, harder to eye-ball, higher > chance of conflict on upstream merge. Would you have comments regarding > _WNAME() macro I proposed in the other mail? (I undertstand it's only > part of the story, there're also CE-only funcs, funcs introduced in > newer CE versions, where #ifdefs are unavoidable). I forget which ones, but there are exceptions to the implied rule that CE functions end in a W. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Paul S. <pm...@gm...> - 2010-12-18 15:52:48
|
Hello, On Sat, 18 Dec 2010 14:29:25 +0100 Danny Backx <dan...@sc...> wrote: > On Thu, 2010-12-16 at 23:48 +0200, Paul Sokolovsky wrote: > > And back to the issue at that link, I worked it around with the > > following patch: > > > > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW); > > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW); > > -#define Shell_NotifyIcon Shell_NotifyIconW > > +//#define Shell_NotifyIcon Shell_NotifyIconW > > > > But where's correct place to resolve this issue? AFAIK, headers come > > from w32api/mingw32, so extra-patching them makes little sense, > > besises they seem to be correct per MS docs, which say that wince > > has only "W" functions. I understand that coredll is dllinked by > > oridinals, so names are secondary, but maybe libcoredll.a is what > > actually should provide "W" symbols? > > I'm not going to get involved again, but take this advice from me : > - you'll find that the MS docs are not always correct > - you'll find every version of Windows to be subtly different I bet ;-I > > Merging with some other development (e.g. w32api) involves > introducing a set of #ifdefs for CE into their sources. Well, #ifdef is 2 lines => bigger patches, harder to eye-ball, higher chance of conflict on upstream merge. Would you have comments regarding _WNAME() macro I proposed in the other mail? (I undertstand it's only part of the story, there're also CE-only funcs, funcs introduced in newer CE versions, where #ifdefs are unavoidable). > > Danny > -- > Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info > -- Best regards, Paul mailto:pm...@gm... |
|
From: Danny B. <dan...@sc...> - 2010-12-18 13:29:34
|
On Thu, 2010-12-16 at 23:48 +0200, Paul Sokolovsky wrote: > And back to the issue at that link, I worked it around with the > following patch: > > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW); > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW); > -#define Shell_NotifyIcon Shell_NotifyIconW > +//#define Shell_NotifyIcon Shell_NotifyIconW > > But where's correct place to resolve this issue? AFAIK, headers come > from w32api/mingw32, so extra-patching them makes little sense, besises > they seem to be correct per MS docs, which say that wince has only "W" > functions. I understand that coredll is dllinked by oridinals, so names > are secondary, but maybe libcoredll.a is what actually should provide > "W" symbols? I'm not going to get involved again, but take this advice from me : - you'll find that the MS docs are not always correct - you'll find every version of Windows to be subtly different Merging with some other development (e.g. w32api) involves introducing a set of #ifdefs for CE into their sources. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Vincent T. <vt...@un...> - 2010-12-18 12:26:31
|
On Sat, 18 Dec 2010, Paul Sokolovsky wrote: > Hello, > > On Sat, 18 Dec 2010 13:04:43 +0100 > Vincent Richomme <fo...@sm...> wrote: > >> Hi, >> >> You should discuss with mingw-w64 folks and especially with Kai Tietz >> because >> he was interested in including mingw32ce inside their repository. >> It would be great to do so because some features that have been >> included into >> mingw-w64 could be backported to cegcc (SEH exceptions, unicode >> startup). >> I already added some files their and you should have a look. > > I tried to look at what mingw-w64 uses for w32api (did they fork it? > do they maintain upstream connection?), but among first google hits I > found discussion of licensing quality concerns with mingw-w64 headers, > and I didn't look further. Then, just ask the mingw-w64 guys. On irc : OFTC, mingw-w64 Vincent Torri |
|
From: Paul S. <pm...@gm...> - 2010-12-18 12:20:51
|
Hello, On Sat, 18 Dec 2010 13:04:43 +0100 Vincent Richomme <fo...@sm...> wrote: > Hi, > > You should discuss with mingw-w64 folks and especially with Kai Tietz > because > he was interested in including mingw32ce inside their repository. > It would be great to do so because some features that have been > included into > mingw-w64 could be backported to cegcc (SEH exceptions, unicode > startup). > I already added some files their and you should have a look. I tried to look at what mingw-w64 uses for w32api (did they fork it? do they maintain upstream connection?), but among first google hits I found discussion of licensing quality concerns with mingw-w64 headers, and I didn't look further. Can you give some hints regarding what you added where - I'm pretty overloaded with information, so that's helpful. I'm so far concentrating on w32api, because that's IMHO the most lacking part of cegcc now - out of 2 (native) apps I tried, none built OOB, and one required heavy header patching. But exception handling was my next concern, because if SEH isn't supported, cegcc can't replace proprietary compiler, and I still don't have clear picture regarding that in cegcc, though presense of *sjlj*.dll somehow hints... OTOH, that thread which I refer to (around http://lists-archives.org/mingw-users/18900-yet-another-mingwrt-w32api-provenance-discussion.html ) mentioned that w64 does use sjlj, while original mingw dwarf2 EH... > -- Best regards, Paul mailto:pm...@gm... |
|
From: Vincent R. <fo...@sm...> - 2010-12-18 12:04:52
|
Hi, You should discuss with mingw-w64 folks and especially with Kai Tietz because he was interested in including mingw32ce inside their repository. It would be great to do so because some features that have been included into mingw-w64 could be backported to cegcc (SEH exceptions, unicode startup). I already added some files their and you should have a look. |
|
From: Paul S. <pm...@gm...> - 2010-12-18 01:53:01
|
Hello Max,
On Sat, 18 Dec 2010 01:39:01 +0100
Max Kellermann <ma...@du...> wrote:
> On 2010/12/18 01:26, Paul Sokolovsky <pm...@gm...> wrote:
> > Or, it would be possible to produce list of all commits on branch,
> > manually filter out merge commits from it, and then pass to some
> > "mass cherry-pick" tool. Of course, there will be conflicts, so that
> > tool must behave like rebase - stop on cnflict, allow to inspect,
> > fix, or skip it, and then continue with the sequence. Well, does
> > such mass c-p tool exist? It must be ;-)
>
> As always with git, there are several ways of doing that. Here's how
> I would do it:
>
> First, "git filter-branch" may be used to get only a sub tree (such as
> src/gcc-4.4.0). That will leave only commits touching gcc.
Yeah, or just git svn import gcc subdir.
> Then use "stg uncommit"
So, is stgit still alive? They r.i.p.ed cogito, so I worry for any
other wrapper, taking into account pace with which git develops.
Anyway, my idea was that git rebase -i should be good enough for
in-repo patch maintenance (even though I have to admit I didn't try it
for that use in prolonged time).
> to convert all commits after the pristine
> import to stgit patches.
>
> Import the newest upstream gcc into a new branch.
>
> Use "stg rebase" to replace cegcc's initial gcc import with the new
Somehow it seems that you either presume, or simplify, that cegcc was
developed in linear manner, with single initial import, followed with
just cegcc-related commits. But it's not like that. There're multiple
upstream syncs/merges, cherry-picks from upstream or elsewhere
("updated to 3.15 with patches"), post-merge updates (can be part of
merge or no), etc. That's what complicates commit re-extraction. Some
parts like gcc might be not too affected; I may imagine, gcc 4.4.0
indeed was dropped once and then mostly cegcc-patched, but gcc at all
has cleaned up patchset from Pedro Alves:
http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2841
But for other tools, I don't see how stgit would help without even
more work than mass c-p approach I imagined.
> upstream version, and stgit will push all the patches on top of the
> new upstream version (with lots and lots of conflicts, of course).
>
> In the end (after a few days of hard work), you'll have a branch full
> of patches, and these need to be sorted, folded, submitted.
Just to make it clear - I'm not interested in upstreaming anything. I'm
interested in making it maintainable outside of upstream. I also have
-10 free hours a day (that's why noise on ML - I can be swayed away
tomorrow for unknown period of time, so would rather leave some traces
for next session, be it mine or somebody else's) and intend cegcc for
higher-level goals than itself, so hacking on it is nuisance. But if
doing that, I try to do it in such way that result will be a cleaner
thing than before. Well, there may be some Guardian knot cuts (and I
may fail to produce something).
--
Best regards,
Paul mailto:pm...@gm...
|
|
From: Max K. <ma...@du...> - 2010-12-18 00:40:06
|
On 2010/12/18 01:26, Paul Sokolovsky <pm...@gm...> wrote: > Or, it would be possible to produce list of all commits on branch, > manually filter out merge commits from it, and then pass to some > "mass cherry-pick" tool. Of course, there will be conflicts, so that > tool must behave like rebase - stop on cnflict, allow to inspect, fix, > or skip it, and then continue with the sequence. Well, does such mass > c-p tool exist? It must be ;-) As always with git, there are several ways of doing that. Here's how I would do it: First, "git filter-branch" may be used to get only a sub tree (such as src/gcc-4.4.0). That will leave only commits touching gcc. Then use "stg uncommit" to convert all commits after the pristine import to stgit patches. Import the newest upstream gcc into a new branch. Use "stg rebase" to replace cegcc's initial gcc import with the new upstream version, and stgit will push all the patches on top of the new upstream version (with lots and lots of conflicts, of course). In the end (after a few days of hard work), you'll have a branch full of patches, and these need to be sorted, folded, submitted. |
|
From: Paul S. <pm...@gm...> - 2010-12-18 00:26:29
|
Hello, On Fri, 17 Dec 2010 08:58:49 +0100 Max Kellermann <ma...@du...> wrote: > Hi, > > good to see some activity over here again. I'm a developer on the > XCSoar project, which ultimately needs mingw32ce to compile for > Windows CE targets, so this project is vital for us. Unfortunately, I > didn't have any chance to free some time to work on mingw32ce/cegcc so > far. > > I have imported the cegcc subversion trunk into a git repository (with > git-svn), just in case anybody here finds that useful: > > git://git.xcsoar.org/xcsoar/max/cegcc.git > http://git.xcsoar.org/cgit/max/cegcc.git/ Thanks! Quite useful already for revision browsing. > > It might be a good start to get more people involved quickly. Clone > it, and hack it. If nobody else steps up, maybe I would volunteer to > manage the "main" repository, and handle pull requests from you. I'd > really love to hack the code myself, if only the day had 96 hours... > > It might be a good idea to make separate git repositories for gcc, > binutils etc., to sync with the upstream projects in the long run, so > this could just be a temporary solution until some brave person > decides to start this upstream merge. Yes, to get some real boon out of it, all of gcc, binutils, mingw and w32api need to split into own repos. But what's next? Well, it's clear that cegcc commits should be "rebased" to git-managed mirror of pristine repos, but in what form - as a big flattened patch, or as sequence of original individual commits? One big flat patch is what should be output of such project IMHO, and yet if to think about upstreaming it, it should at least somehow split. In this regard, sequence of original individual commits is not much useful, and yet they represent detailed history and useful as a reference... And I have no idea how to "copy" them from an "alien" branch which mixes upstream merges and actual useful commits. Apart from manual cherry-picking each commit, of course. Or, it would be possible to produce list of all commits on branch, manually filter out merge commits from it, and then pass to some "mass cherry-pick" tool. Of course, there will be conflicts, so that tool must behave like rebase - stop on cnflict, allow to inspect, fix, or skip it, and then continue with the sequence. Well, does such mass c-p tool exist? It must be ;-) But it seems that the ideal solution is mid-way: big flat patch is too big and flat, while bothering to faithfully port commits like "Oops, I added file to wrong dir" makes little use too. So, I'm going to (subject to time constraints) make a proof of concept migration of w32api with following procedure: 1. git svn import cegcc's w32api 2. git cvs import upstream w32api (yeah, they use CVS by the end of 2010, whoa!) 3. Then, put these two imports as separate branches into one repo. They are not expected to be merged. 4. cegcc's w32api will be there for reference at fingertips, and to pull from SVN, if there will be changes (and cherry-pick them). 5. Upstream w32api will track upstream closely. 6. From it, work branch will be created. 7. One big flat patch will be produced from cegcc w32api repo and its upstream. 8. Then, it will be cleaned up based on ideas in my other today's mails. 9. Then, it will be split per some usefull, yet simple, criteria, like separate patch for each header vs build changes vs bulk .def additions. 10. Those patches will be applied one by one to work branch. 11. Regarding attribution, ChangeLog.ce will be there. Not sure how to deal with it, ideally each patch should include relevant bits from it, but that doesn't qualify as "simple". So, likely will be dropped in intact, elaboration of that can be left for later, if there ever be upstream submission. -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2010-12-17 23:36:49
|
Hello, On Fri, 17 Dec 2010 15:46:55 +0200 Paul Sokolovsky <pm...@gm...> wrote: [] > So, this should be handled differently. Quick idea is to use implib > aliasing, like > > SetPropW=SetProp Well, either I mix up things, or in my times (ca. 10 years ago) that indeed worked with dlltool for creating implibs from .defs. But it doesn't now, and it was a hell to find an MS compiler to verify that behavior. In the process, learned that there's no implib.exe nowadays (eVC4), but lib.exe does the trick. Still, binutils people made what I had in mind: http://sourceware.org/git/?p=binutils.git;a=commit;f=binutils/dlltool.c;h=f762b0771734d0a4c81f3b19302bce8a1853a9d8 http://sourceware.org/git/?p=binutils.git;a=blob;f=binutils/testsuite/binutils-all/alias-2.def;h=ef41eec6c15954b8e252481e4adc9a69b6248c6c;hb=f762b0771734d0a4c81f3b19302bce8a1853a9d8 But well, would need to upgrade binutils to elaborate w32api. Scope creep. Another issue is that objects produced with such technique would be unlinkable by MSVC - some people appear to use such scenario. Another approach to at least minimize w32api patching is: #ifdef _WIN32_WCE #define _WNAME(name) name #else #define _WNAME(name) name ## W #endif BOOL WINAPI Shell_NotifyIconA(DWORD,PNOTIFYICONDATAA); BOOL WINAPI _WNAME(Shell_NotifyIcon)(DWORD,PNOTIFYICONDATAW); #define Shell_NotifyIcon _WNAME(Shell_NotifyIcon) -- Best regards, Paul mailto:pm...@gm... |
|
From: Sébastien L. <sq...@gm...> - 2010-12-17 19:09:41
|
Hi I noticed that our next exchanges did not make it to the list because of the bad handling of lists reply-to by gmail (Harald Welte explained to me that it's a desirable feature, but I always forget to reply-to-all :-) ) Let's fix it. ==================================================================== here are new steps to build mingw32ce for windows from debian. get code cd $HOME mkdir cegcc cd cegcc svn co https://cegcc.svn.sourceforge.net/svnroot/cegcc/trunk cegcc-src wget ftp://ftp.gmplib.org/pub/gmp-4.3.1/gmp-4.3.1.tar.gz wget http://www.mpfr.org/mpfr-2.4.1/mpfr-2.4.1.tar.gz tar zxvf gmp-4.3.1.tar.gz tar zxvf mpfr-2.4.1.tar.gz patch code Here is what you must change in the mingw32ce build script Basically this deals with passing the proper gmp/mpfr options to the gcc configure script. This might be achievable by other means, e.g. environment. svn diff: ---8<--- Index: build-mingw32ce.sh =================================================================== --- build-mingw32ce.sh (revision 1449) +++ build-mingw32ce.sh (working copy) @@ -49,12 +49,17 @@ --components=LIST specify which components to build valid components are: ${COMPONENTS_COMMA_LIST} [all] + --gmp=DIR path to GMP library + --mpfr=DIR path to MPFR library Report bugs to <ceg...@li...>. _ACEOF } +lib_gmp= +lib_mpfr= + ac_prev= for ac_option do @@ -97,6 +102,12 @@ | --co=* | --c=*) components=$ac_optarg ;; + --gmp=*) + lib_gmp=$ac_optarg ;; + + --mpfr=*) + lib_mpfr=$ac_optarg ;; + --host) ac_prev=host ;; --host=*) @@ -179,6 +190,16 @@ exit 1 fi +#compute the options for gmp and mpfr + +GCCDEPS= +if [ "x${lib_gmp}" != "x" ]; then + GCCDEPS="--with-gmp=${lib_gmp}" +fi +if [ "x${lib_gmp}" != "x" ]; then + GCCDEPS="${GCCDEPS} --with-mpfr=${lib_mpfr}" +fi + build_binutils() { echo "" @@ -209,6 +230,7 @@ --with-gcc \ --with-gnu-ld \ --with-gnu-as \ + ${GCCDEPS} \ --target=${TARGET} \ --build=${BUILD} \ --host=${HOST} \ @@ -314,6 +336,7 @@ --target=${TARGET} \ --host=${HOST} \ --prefix=${PREFIX} \ + ${GCCDEPS} \ --enable-threads=win32 \ --disable-nls \ --enable-languages=c,c++ \ @@ -333,6 +356,7 @@ --target=${TARGET} \ --host=${HOST} \ --prefix=${PREFIX} \ + ${GCCDEPS} \ --enable-threads=win32 \ --disable-nls \ --enable-languages=c,c++ \ ---8<--- now we're ready to go. First step is to build a linux mingw32ce, to allow building the target libs (build=host=linux, target=arm-wince-pe) we need some dependencies - you may have them in apt-get, I recompiled to get the same versions as what the final compiler has mkdir depends-linux mkdir gmp-linux cd gmp-linux ../gmp-4.3.1/configure --prefix=`cd ../depends-linux; pwd` make make install cd .. mkdir mpfr-linux cd mpfr-linux ../mpfr-2.4.1/configure --prefix=`cd ../depends-linux; pwd` --with-gmp=`cd ../depends-linux; pwd` make make install cd .. build the compiler and install e.g. to /opt/mingw32ce (target=arm-wince-pe, build=host=linux) This will NOT WORK if you do not set gcc_src=gcc, I don't know what's the problem with gcc 4.4 (you can try, though) mkdir build-linux cd build-linux sudo gcc_src=gcc ../cegcc-src/cegcc/src/scripts/build/build-minw32ce.sh --prefix=/opt/mingw32ce --gmp=`cd ../depends-linux;pwd` --mpfr=`cd ../depends-linux;pwd` cd .. Second step is to cross build the win32 compiler install mingw for linux -- or build it, if you prefer... sudo apt-get install mingw32 the compiler prefix is i586-mingw32msvc- crossbuild dependencies for windows host (build is linux, host is windows, target has no sense (same as host)) mkdir depends-win mkdir gmp-win cd gmp-win ../gmp-4.3.1/configure --host=i586-mingw32msvc --prefix=`cd ../depends-win; pwd` make make install cd .. mkdir mpfr-win cd mpfr-win ../mpfr-2.4.1/configure --host=i586-mingw32msvc --prefix=`cd ../depends-win; pwd` --with-gmp=`cd ../depends-win; pwd` make make install cd .. build cegcc for windows: build=linux, host=windows, target=arm-wince-pe the linux version of the compiler needs to be in the path to build the target libs! Do not forget to update PATH or the build will fail, of course. mkdir INSTALL mkdir build-win cd build-win PATH=/opt/mingw32ce/bin:$PATH export PATH gcc_src=gcc ../cegcc-src/cegcc/src/scripts/build-mingw32ce.sh --prefix=`cd ../INSTALL;pwd` --host=i586-mingw32msvc --gmp=`cd ../depends-win;pwd` --mpfr=`cd ../depends-win;pwd` make make install And here you have a nice arm-wince-pe toolchain for mingw! I'd like some feedback on this process. That's why I'm not posting binaries yet. I want someone else to test that, to check wether that's ok or not. Sebastien |
|
From: Paul S. <pm...@gm...> - 2010-12-17 15:13:51
|
Hello, Well, here's situation in utero: PocketPC2003 SDK defines Shell_NotifyIcon. Yet there's MessageBoxW. Apparently, for WinCE they decided to add W only for functions which directly get LPTSTR, not indirectly via structures. But on WinXP, shell32.dll has all 3 of Shell_NotifyIcon, Shell_NotifyIconA, Shell_NotifyIconW (and w32api def too, but headers lack Shell_NotifyIcon). What a mess! And I'm still not sure how to deal with it. It depends on the scope of effort. One thing is to run behind the vendor to support its platform with alternative tools, and another is to maintain platform they fail to maintain (PocketPC, WindowsMobile). On Fri, 17 Dec 2010 15:46:55 +0200 Paul Sokolovsky <pm...@gm...> wrote: > Hello, > > On Thu, 16 Dec 2010 23:48:20 +0200 > Paul Sokolovsky <pm...@gm...> wrote: > > [] > > > http://www.mail-archive.com/ceg...@li.../msg03053.html , > > > > And back to the issue at that link, I worked it around with the > > following patch: > > > > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW); > > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW); > > -#define Shell_NotifyIcon Shell_NotifyIconW > > +//#define Shell_NotifyIcon Shell_NotifyIconW > > > > But where's correct place to resolve this issue? AFAIK, headers come > > from w32api/mingw32, so extra-patching them makes little sense, > > besises they seem to be correct per MS docs, which say that wince > > has only "W" functions. I understand that coredll is dllinked by > > oridinals, so names are secondary, but maybe libcoredll.a is what > > actually should provide "W" symbols? > > Update: turns out that .def files don't have ordinals, so, at least on > the level of implibs, they are not used. I also see how this issue > being handled: > > winuser.h: > #ifndef _WIN32_WCE > WINUSERAPI LONG WINAPI ChangeDisplaySettingsA(PDEVMODEA,DWORD); > WINUSERAPI LONG WINAPI ChangeDisplaySettingsW(PDEVMODEW,DWORD); > WINUSERAPI LONG WINAPI > ChangeDisplaySettingsExA(LPCSTR,LPDEVMODEA,HWND,DWORD,LPVOID); > WINUSERAPI LONG WINAPI > ChangeDisplaySettingsExW(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID); > #else /* _WIN32_WCE */ WINUSERAPI LONG WINAPI > ChangeDisplaySettingsEx(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID); > #endif /* _WIN32_WCE */ > > But that goes out of hand IMHO, as if it's not enough that MS dupped > every string-receiving function, and everyone actually maintains 2 > defs instead of employing some preprocessor to generate them out of > common description. Duplication (triplication?) leads to apparent > errors, like: > > #ifdef _WIN32_WCE > WINUSERAPI BOOL WINAPI SetProp(HWND,LPCSTR,HANDLE); > #else > WINUSERAPI BOOL WINAPI SetPropA(HWND,LPCSTR,HANDLE); > WINUSERAPI BOOL WINAPI SetPropW(HWND,LPCWSTR,HANDLE); > #endif > > Note pointer type in SetProp(). > > > So, this should be handled differently. Quick idea is to use implib > aliasing, like > > SetPropW=SetProp > > That assumes that coredll.dll indeed exports A/W-less functions. > Seeing's believing, but it's locked on device, google is noisy, and > have no idea where my own rom dumps... > > > > > > > > > But this is from memory, I may have forgotten some aspects. > > > > > > Note that I can provide SVN write access on the cegcc project for > > > those who want to do real work on it. > > > > I guess, with the current situation, scope should change from > > maintaining a project repo to maintaining a project patch, with the > > implication it has (minimize patch size, avoid changing which can be > > not changed). And I agree with previous people who spoke on this, > > git should be the tool for maintenance. > > > > That said, I already find me diffing build-mingw32ce.sh & > > build-x86.sh, expectably finding them to be cases of code > > duplication and expectably having random divergences due to this, > > and trying to patch those divergences away. So, if I finish and > > submit patch for that, we can discuss this further. > > > > But what I'd appreciate is mediawiki write access, so I at least can > > collect gnu-wince related links in a public place. My SF username is > > 'pfalcon'. Thanks. > > > > > > > > > > Danny > > > > > > On Thu, 2010-12-16 at 06:11 +0200, Paul Sokolovsky wrote: > > > > Hello, > > > > > > > > Well, ok, should have read the list archive a bit more ;-). > > > > Pedro Alves' cleanup: > > > > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839 > > > > > > > > I'd still ask for other parties' patchsets, as that one is > > > > year's old, and for gcc only apparently. > > > > > > > > On Thu, 16 Dec 2010 05:55:23 +0200 > > > > Paul Sokolovsky <pm...@gm...> wrote: > > > > > > > > > Hello, > > > > > > > > > > I'd like to ask people who worked on producing a cegcc > > > > > patchset/porting cegcc to newer versions of binutils/gcc to > > > > > share any results they have, no matter how incomplete or > > > > > preliminary they are (I in particular cc: Pavel Pavlov who > > > > > worked on this at the summer per his posts to the mailing > > > > > list). Just seeing size of patches and curious peek inside can > > > > > give info/motivation someone needs to continue the work. > > > > > > > > > > -- > > > > > Best regards, > > > > > Paul mailto:pm...@gm... > > > > > > > > > > > > > > > > > > -- > > > Danny Backx ; danny.backx - at - scarlet.be ; > > > http://danny.backx.info > > > > > > > > > > > -- > > Best regards, > > Paul mailto:pm...@gm... > > > > ------------------------------------------------------------------------------ > > Lotusphere 2011 > > Register now for Lotusphere 2011 and learn how > > to connect the dots, take your collaborative environment > > to the next level, and enter the era of Social Business. > > http://p.sf.net/sfu/lotusphere-d2d > > _______________________________________________ > > Cegcc-devel mailing list > > Ceg...@li... > > https://lists.sourceforge.net/lists/listinfo/cegcc-devel > > > > -- > Best regards, > Paul mailto:pm...@gm... -- Best regards, Paul mailto:pm...@gm... |
|
From: Paul S. <pm...@gm...> - 2010-12-17 13:47:18
|
Hello, On Thu, 16 Dec 2010 23:48:20 +0200 Paul Sokolovsky <pm...@gm...> wrote: [] > http://www.mail-archive.com/ceg...@li.../msg03053.html , > > And back to the issue at that link, I worked it around with the > following patch: > > -BOOL WINAPI Shell_NotifyIconW(DWORD,PNOTIFYICONDATAW); > +BOOL WINAPI Shell_NotifyIcon(DWORD,PNOTIFYICONDATAW); > -#define Shell_NotifyIcon Shell_NotifyIconW > +//#define Shell_NotifyIcon Shell_NotifyIconW > > But where's correct place to resolve this issue? AFAIK, headers come > from w32api/mingw32, so extra-patching them makes little sense, > besises they seem to be correct per MS docs, which say that wince has > only "W" functions. I understand that coredll is dllinked by > oridinals, so names are secondary, but maybe libcoredll.a is what > actually should provide "W" symbols? Update: turns out that .def files don't have ordinals, so, at least on the level of implibs, they are not used. I also see how this issue being handled: winuser.h: #ifndef _WIN32_WCE WINUSERAPI LONG WINAPI ChangeDisplaySettingsA(PDEVMODEA,DWORD); WINUSERAPI LONG WINAPI ChangeDisplaySettingsW(PDEVMODEW,DWORD); WINUSERAPI LONG WINAPI ChangeDisplaySettingsExA(LPCSTR,LPDEVMODEA,HWND,DWORD,LPVOID); WINUSERAPI LONG WINAPI ChangeDisplaySettingsExW(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID); #else /* _WIN32_WCE */ WINUSERAPI LONG WINAPI ChangeDisplaySettingsEx(LPCWSTR,LPDEVMODEW,HWND,DWORD,LPVOID); #endif /* _WIN32_WCE */ But that goes out of hand IMHO, as if it's not enough that MS dupped every string-receiving function, and everyone actually maintains 2 defs instead of employing some preprocessor to generate them out of common description. Duplication (triplication?) leads to apparent errors, like: #ifdef _WIN32_WCE WINUSERAPI BOOL WINAPI SetProp(HWND,LPCSTR,HANDLE); #else WINUSERAPI BOOL WINAPI SetPropA(HWND,LPCSTR,HANDLE); WINUSERAPI BOOL WINAPI SetPropW(HWND,LPCWSTR,HANDLE); #endif Note pointer type in SetProp(). So, this should be handled differently. Quick idea is to use implib aliasing, like SetPropW=SetProp That assumes that coredll.dll indeed exports A/W-less functions. Seeing's believing, but it's locked on device, google is noisy, and have no idea where my own rom dumps... > > > > > But this is from memory, I may have forgotten some aspects. > > > > Note that I can provide SVN write access on the cegcc project for > > those who want to do real work on it. > > I guess, with the current situation, scope should change from > maintaining a project repo to maintaining a project patch, with the > implication it has (minimize patch size, avoid changing which can be > not changed). And I agree with previous people who spoke on this, git > should be the tool for maintenance. > > That said, I already find me diffing build-mingw32ce.sh & > build-x86.sh, expectably finding them to be cases of code duplication > and expectably having random divergences due to this, and trying to > patch those divergences away. So, if I finish and submit patch for > that, we can discuss this further. > > But what I'd appreciate is mediawiki write access, so I at least can > collect gnu-wince related links in a public place. My SF username is > 'pfalcon'. Thanks. > > > > > > Danny > > > > On Thu, 2010-12-16 at 06:11 +0200, Paul Sokolovsky wrote: > > > Hello, > > > > > > Well, ok, should have read the list archive a bit more ;-). Pedro > > > Alves' cleanup: > > > http://article.gmane.org/gmane.comp.gnu.cegcc.devel/2839 > > > > > > I'd still ask for other parties' patchsets, as that one is year's > > > old, and for gcc only apparently. > > > > > > On Thu, 16 Dec 2010 05:55:23 +0200 > > > Paul Sokolovsky <pm...@gm...> wrote: > > > > > > > Hello, > > > > > > > > I'd like to ask people who worked on producing a cegcc > > > > patchset/porting cegcc to newer versions of binutils/gcc to > > > > share any results they have, no matter how incomplete or > > > > preliminary they are (I in particular cc: Pavel Pavlov who > > > > worked on this at the summer per his posts to the mailing > > > > list). Just seeing size of patches and curious peek inside can > > > > give info/motivation someone needs to continue the work. > > > > > > > > -- > > > > Best regards, > > > > Paul mailto:pm...@gm... > > > > > > > > > > > > > -- > > Danny Backx ; danny.backx - at - scarlet.be ; > > http://danny.backx.info > > > > > > -- > Best regards, > Paul mailto:pm...@gm... > > ------------------------------------------------------------------------------ > Lotusphere 2011 > Register now for Lotusphere 2011 and learn how > to connect the dots, take your collaborative environment > to the next level, and enter the era of Social Business. > http://p.sf.net/sfu/lotusphere-d2d > _______________________________________________ > Cegcc-devel mailing list > Ceg...@li... > https://lists.sourceforge.net/lists/listinfo/cegcc-devel -- Best regards, Paul mailto:pm...@gm... |
15 messages has been excluded from this view by a project administrator.
