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: Sébastien L. <sq...@gm...> - 2011-03-04 08:15:06
|
some people are still forced to work with the "obsolete O$" ;-) In that case, http://www.unsads.com/~squalyl/cegcc/mingw32ce-build-mingw.zip is worth a try. Regards On Fri, Mar 4, 2011 at 9:08 AM, Vincent Torri <vt...@un...> wrote: > > > On Fri, 4 Mar 2011, Mauro Ziliani wrote: > > > Hi all. > > I'm working for Windows CE with Embedded Visual C++ 4.0 sp4. > > I need to swicth my work on better environment and I choose > arm-mingw32ce. > > But I'd like to avoid Cygnus, but use directly Mingw, like I does for > > others develompment. > > > > Does anyone have try to compile arm-mingw32ce with latest Mingw > > distribution? > > compilation with MSYS or cygwin is really really slow. You should > cross-compile on linux. And if you want to stay on Windows, install > virtualbox with a linux host and compile there, it will be faster > > Vincent Torri > > > ------------------------------------------------------------------------------ > What You Don't Know About Data Connectivity CAN Hurt You > This paper provides an overview of data connectivity, details > its effect on application quality, and explores various alternative > solutions. http://p.sf.net/sfu/progress-d2d > _______________________________________________ > Cegcc-devel mailing list > Ceg...@li... > https://lists.sourceforge.net/lists/listinfo/cegcc-devel > |
|
From: Vincent T. <vt...@un...> - 2011-03-04 08:08:31
|
On Fri, 4 Mar 2011, Mauro Ziliani wrote: > Hi all. > I'm working for Windows CE with Embedded Visual C++ 4.0 sp4. > I need to swicth my work on better environment and I choose arm-mingw32ce. > But I'd like to avoid Cygnus, but use directly Mingw, like I does for > others develompment. > > Does anyone have try to compile arm-mingw32ce with latest Mingw > distribution? compilation with MSYS or cygwin is really really slow. You should cross-compile on linux. And if you want to stay on Windows, install virtualbox with a linux host and compile there, it will be faster Vincent Torri |
|
From: Mauro Z. <ma...@fa...> - 2011-03-04 07:03:12
|
Hi all.
I'm working for Windows CE with Embedded Visual C++ 4.0 sp4.
I need to swicth my work on better environment and I choose arm-mingw32ce.
But I'd like to avoid Cygnus, but use directly Mingw, like I does for
others develompment.
Does anyone have try to compile arm-mingw32ce with latest Mingw
distribution?
Best regards.
Mauro Ziliani
|
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:16:17
|
Bugs (use Trac instead) item #1666403, was opened at 2007-02-22 10:17 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1666403&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: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Aldo Calpini (acalpini) Assigned to: Nobody/Anonymous (nobody) Summary: cegcc doesn't output last line without a terminating newline Initial Comment: given this simple test.c file: #include <stdio.h> int main(int argc, char **argv) { printf("1\n"); printf("2"); return 0; } compiled with: arm-wince-cegcc-gcc -o test_cegcc.exe test.c I get the following output on the PDA: \Temp> test_cegcc 1 \Temp> the same program compiled with mingw32ce with: arm-wince-mingw32ce-gcc -o test_mingw32ce.exe test.c produces instead the desired output: \Temp> test_mingw32ce 1 2\Temp> putting a \n after the "2" in the last printf works correctly with both compilers. cheers, Aldo ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:16 Message: No response, old. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2008-12-17 23:18 Message: Is this still present ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1666403&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:15:43
|
Bugs (use Trac instead) item #1889860, was opened at 2008-02-08 13:52 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1889860&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: None Group: None >Status: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Boris Brodski (boris_brodski) Assigned to: Nobody/Anonymous (nobody) Summary: DirectShow include files problem Initial Comment: If you try to include following h-files #include <windows.h> #include <dshow.h> you get /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/dshow.h:8, from ..\src\WinCETest.cpp:15: /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/amaudio.h:7:20: error: dsound.h: No such file or directory In file included from /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/dshow.h:9, from ..\src\WinCETest.cpp:15: /cygdrive/d/CeGCC/cegcc/bin/../lib/gcc/arm-wince-cegcc/4.1.0/../../../../arm-wince-cegcc/lib/../include/w32api/amvideo.h:7:19: error: ddraw.h: No such file or directory It seems, that at least ddraw.h and dsound.h files are missing. For example as a result a definition of IBaseFilter can't be found. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:15 Message: Please retry with altest w32api from git. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2009-04-28 08:17 Message: Thank you very much for reply. Unfortunately, after more that one year I can't test it any more. If #include <windows.h> #include <dshow.h> cause no compile errors you can close this feature request safely. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-04-28 07:34 Message: IBaseFilter is in w32api/include/strmif.h . Please provide complete information (preferably a patch) for the stuff you're missing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1889860&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:14:44
|
Bugs (use Trac instead) item #2137124, was opened at 2008-09-29 17:20 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2137124&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: CeGCC (arm-wince-cegcc) Group: None >Status: Closed >Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Pedro Alves (pedroalves) Summary: build-cegcc.sh doesnt build libstdc++.dll Initial Comment: Lines 21 and 22 of build-cegcc.sh script have: COMPONENTS=( binutils bootstrap_gcc w32api newlib dummy_cegccdll gcc cegccdll cegccthrddll libstdcppdll profile docs ) COMPONENTS_NUM=${#COMPONENTS} This returns COMPONENTS_NUM as 8, the number of letters in "binutils". Line 22 should be: COMPONENTS_NUM=${#COMPONENTS[*]} The same thing occurs in build-mingw32ce.sh but there the number of components is, fortuitously, 8. Thanks for your work on this project. rob...@oz... ---------------------------------------------------------------------- Comment By: Pedro Alves (pedroalves) Date: 2008-09-30 05:00 Message: Thank you for the report. I just committed the fix to build-cegcc.sh and build-mingw32ce.sh too. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2137124&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:14:00
|
Bugs (use Trac instead) item #2782228, was opened at 2009-04-27 08:34 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2782228&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: Closed >Resolution: Out of Date Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: %f problem with mingw_*printf Initial Comment: As explained in http://sourceforge.net/mailarchive/forum.php?thread_name=20090420152424.GA24491%40via.ecp.fr&forum_name=cegcc-devel, built-in mingw printf replacement functions show buggy output when %f specifiers are used. This might be linked to doubles that are not properly 8-byte aligned. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:13 Message: And where's that %f is used to start with? Not enough info, anon post, closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2782228&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:12:22
|
Bugs (use Trac instead) item #2868656, was opened at 2009-09-27 23:34 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2868656&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: CeGCC (arm-wince-cegcc) Group: None Status: Open Resolution: None Priority: 5 Private: No Submitted By: Rob Eggleton (rite) Assigned to: Nobody/Anonymous (nobody) Summary: virtual keyword causes exception? Initial Comment: Adding "virtual" to a simple method causes the following exception to be raised: "Program: A.exe Exception: 0xC00000FD Address: 00000000" This happens both on the emulator I'm using (Microsoft DeviceEmulator Manager 9.0.21022.8) and on the real device (Intel XScale 400Mhz PXA 255). The code being compiled is: #include <iostream> using std::cout; using std::endl; class Simple { public: Simple(); virtual ~Simple(); }; Simple::Simple() { } Simple::~Simple() { } int main() { cout << "Strange?" << endl; } I'm compiling the code with arm-wince-cegcc-g++ -o A.exe A.cpp If I remove "virtual" from the destructor then the code runs without an exception. This happens for any method not just the destructor. arm-wince-cegcc-g++ --version gives: arm-wince-cegcc-g++ (GCC) 4.1.0 Copyright (C) 2006 Free Software Foundation, Inc. This is free software; see the source for copying conditions. There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. Any ideas? ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:12 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-10-01 09:49 Message: The test below is with your executable on my iPAQ 214 running WM 6.0. pavilion: {121} rcp A.exe ipaq:/temp pavilion: {122} rsh ipaq /temp/A.exe Strange pavilion: {123} ---------------------------------------------------------------------- Comment By: Rob Eggleton (rite) Date: 2009-09-30 23:39 Message: I've updated to 0.59.1 (and downloaded mpfr 2.4.1). Exactly the same thing is happening. I've attached a tar ball of: the source, the output from strace when compiling, the resultant .exe file and the build (go) script. It's weird I have another app with a few thousand lines which all works fine ... but as soon as I add "virtual" it fails. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-09-30 13:04 Message: I cannot reproduce this, but I'm using the gcc-4.4 based software. Could you pick up the latest release (0.59.1) and try it ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2868656&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:11:50
|
Bugs (use Trac instead) item #2890747, was opened at 2009-11-02 07:30 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2890747&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: None Group: None Status: Open Resolution: None >Priority: 3 Private: No Submitted By: http://openid.claimid.com/vonol () Assigned to: Nobody/Anonymous (nobody) >Summary: Wrong search dirs on sygwin? Initial Comment: I run Cygwin 1.7 and installed the mingw32ce 0.59.1 package downloaded from cegcc's SF project page. The package is unarchived in /opt, meaning everything ends up in /opt/mingw32ce/... I added /opt/mingw32ce/arm-mingw32ce/bin to my path evinronment variable. Running gcc.exe/g++.exe works fine. I have no other GCC installed on my system. The problem is when I link object files compiled with the compiler into an executable. I get an error abot crt3.o not found: ld: crt3.o: No such file: No such file or directory This file is located in /opt/mingw32ce/arm-mingw32ce/lib. Running gcc -print-search-dirs give the following output: install: /opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/arm-mingw32ce/4.4.0/programs: =/opt/mingw32ce/arm-mingw32ce/bin/../libexec/gcc/arm-mingw32ce/4.4.0/:/opt/mingw32ce/arm-mingw32ce/bin/../libexec/gcc/:/opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/arm-mingw32ce/4.4.0/:/opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ libraries: =/opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/arm-mingw32ce/4.4.0/:/opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/:/opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/lib/arm-mingw32ce/4.4.0/:/opt/mingw32ce/arm-mingw32ce/bin/../lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/lib/ As far as I can tell, the correct path for crt3.o is missing. I have also had to add /opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.4.0 in order for the compiler to find cc1(plus).exe. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:11 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-11-02 08:57 Message: The output is different on my Linux box. The last element of "libraries" does evaluate to the right place for me (/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/lib/ -> /opt/mingw32ce/arm-mingw32ce/lib/crt3.o) . Does someone with a cygwin system know what's wrong ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2890747&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:10:40
|
Bugs (use Trac instead) item #2896500, was opened at 2009-11-12 01:35 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&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: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Ivan Maidanski (ivmai) Assigned to: Danny Backx (dannybackx) Summary: Patch for GCC float.h Initial Comment: Without this patch, I have to set c_include_path=/cygdrive/C/x86mingw32ce/i386-mingw32ce/include. The same problem exists in mingw-w64 project, see: https://sourceforge.net/tracker/index.php?func=detail&aid=2363741&group_id= 202880&atid=983354 The patch should be really sent to GCC but I'd like to know your opinion. I use __MINGW32__ to identify toolchains that have MS-specific float.h (i.e., for CeGCC toolchains, they are mingw32ce and x86mingw32ce but not cegcc). Should be correct, right? ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:10 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- Comment By: Ivan Maidanski (ivmai) Date: 2009-11-14 08:33 Message: > Also yes sending it to GCC makes sense. Unfortunately, it seems it doesn't... See this post: https://sourceforge.net/tracker/?func=detail&aid=2896485&group_id=202880&atid=983356 This post also suggests another solution - copy the contents of gcc float.h into the specific mingw one and remove the gcc one. > I'm not sure why you define the _NEXT_FLOAT_H_ macro though. This is just a guard against infinite recursion between a specific float.h and a gcc one (they may both do include_next each other (before checking for _FLOAT_H) in some toolchains). _NEXT_FLOAT_H_ is not used anywhere else (and is unique as reported by google codesearch). ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-11-13 23:22 Message: You're saying that the gcc float.h overrides the mingw one. Yes that does make sense. Also yes sending it to GCC makes sense. I'm not sure why you define the _NEXT_FLOAT_H_ macro though. Your proposed use of __MINGW32__ looks right. __MINGW32__ is indeed defined by both {arm,i386}-mingw32ce-gcc . arm-cegcc-gcc doesn't appear to have this situation and it doesn't define __MINGW32__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:10:25
|
Bugs (use Trac instead) item #2896681, was opened at 2009-11-12 07:28 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896681&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: Ivan Maidanski (ivmai) Assigned to: Nobody/Anonymous (nobody) Summary: __udivsi3 is imported if a DLL is created Initial Comment: If I compile my code to a DLL, __udivsi3 is imported (from libgcc_s_sjlj-1.dll). If I compile to EXE then libgcc_s_sjlj-1.dll redist is not needed. Is this a bug or a feature? (this is not observed with x86mingw32ce.) ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:10 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896681&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:09:58
|
Bugs (use Trac instead) item #2901677, was opened at 2009-11-21 02:27 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2901677&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: 4 Private: No Submitted By: Ivan Maidanski (ivmai) Assigned to: Nobody/Anonymous (nobody) Summary: Suspicious ".data" symbols ordering Initial Comment: I've discovered that it symbols in .data section (unlike .bss one) are neither in the odrer they are defined in .c file nor in the reversed order if optimization is on. I haven't seen such behavior in other compilers or gcc toolchains (I've checked VC++ 9, eVC++, MinGW, mingw-w64). The test case attached (compile it with at least -O1; to make output goes to a log file, compile it with -DUSE_LOGFILE). May be, it's not a bug but such a feature... ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:09 Message: Please describe what are issues with this. And: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2901677&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:08:55
|
Bugs (use Trac instead) item #2905279, was opened at 2009-11-28 02:55 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2905279&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: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: CeGCC 0.59.1 broken ffmpeg_svn20620 Initial Comment: CeGCC 0.59.1 broken ffmpeg.I can compile ffmpeg, but i get a Datatype misalignment when i use it. In 0.51.0, it work. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:08 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- Comment By: Pierre Ynard (linkfanel) Date: 2009-11-30 07:33 Message: Provided here is the asm output for the hl_decode_mb_complex() function in libavcodec/h264.c, which contains the offending code. Both are compiled from ffmpeg revision 20630, the first one with the revision 1314 of cegcc (gcc 4.1) and the second one with revision 1364 (gcc 4.4). The PC at the Data Abort maps to address 0x2fe7c, which apparently corresponds to 0x1e158 in the version that doesn't crash. CFLAGS -funroll-loops -mtune=arm920t -march=armv4t -O3 were used. Since I can't seem to be able to add attachments: http://www.linkfanel.net/disass-r1314.txt http://www.linkfanel.net/disass-r1364.txt ---------------------------------------------------------------------- Comment By: Pierre Ynard (linkfanel) Date: 2009-11-28 07:51 Message: I was just looking into the same issue. Since cegcc switched to gcc 4.4 in revision 1315, ffmpeg is somehow miscompiled, and crashes. For me, it happens when playing some H264 video. I get a: Data Abort: Thread=81da6c50 Proc=80298c70 'foo.exe' AKY=00020001 PC=00bd9290(libavcodec_plugin.dll+0x00189290) RA=00732c62(foo.exe+0x00722c62) BVA=24732c62 FSR=00000003 This maps to line 2643 in libavcodec/h264.c. I could provide asm extracts and more information. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-11-28 06:36 Message: Please provide more information : where does it crash, which instructions are there, how were these instructions in the version compiled with 0.51 ? Between 0.51 and 0.59 we changed gcc versions (from 4.1 to 4.4). ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2905279&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:04:37
|
Bugs (use Trac instead) item #2912803, was opened at 2009-12-11 09:35 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2912803&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: CeGCC (arm-wince-cegcc) Group: None >Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Danny Backx (dannybackx) Summary: fopen() fails with Japanese filenames - encoding mismatch Initial Comment: I've been trying to open files with Japanese characters in the filename using arm-wince-cegcc, v0.55. I've recompiled with --enable-newlib-mb to enable multi-byte support. I've succeeded eventually but have had to fix a 'bug' in the newlib library, however while I can make a simplistic patch up I need help on a proper fix. I'm using filenames in UTF-8, I've called setlocal(C_TYPE,"C-UTF-8") which succeeds. The problem seemed to occur in libc/sys/wince/cefixpath.c in the function XCEFixPathA(), which is called by fixpath(). Here's an extract for XCEFixPathA(). MultiByteToWideChar(CP_ACP, 0, pathin, -1, wpathin, MAX_PATH); XCEFixPathW(wpathin, wpathout); WideCharToMultiByte(CP_ACP, 0, wpathout, -1, pathout, MAX_PATH, NULL, NULL); It seems that the codepage CP_ACP (Windows ANSI default) can conflict with my codepage as set by setlocale(), because different multi-byte to wide-char functions are used in cefixpath.c and io.c (mbstowcs() in the function _open_r which is called by fopen). This conflict causes my UTF-8 string to get mangled up by the conversion to and from multi-byte chars in XCEFixPath(). My temporary fix has been to replace the code in XCEFixPath() with a simple / to \ replacement on an 8-bit string. Obviously this only works on ASCII or UTF-8 strings. I include my sample source code along with trace and log output from this program compiled with a patched and unpatched version of newlib. Can somebody please take a look and advise me on a better fix to this problem please? ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:04 Message: Assumed fixed. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2010-01-01 22:05 Message: Please check out the fix I just checked in, it worked for me ---------------------------------------------------------------------- Comment By: Adrian Skilling (adrianskilling) Date: 2009-12-15 06:33 Message: Sorry. This can't work since MultiByteToWideChar cannot accept a string for the locale, it only accepts a small limited set of code pages such as CP_ACP, CP_UTF7 and CP_UTF8. MultiByteToWideChar has an advantage that it can be given a code page but this advantage is not used because the code page is fixed to CP_ACP. I suggest that MultiByteToWideChar() is replaced with mbstowcs() which would then make it consistent with that used in fopen() [in _open_r() specifically). I shall try this on my version. But I can't be sure it would work well for all languages. I'll get back. ---------------------------------------------------------------------- Comment By: Adrian Skilling (adrianskilling) Date: 2009-12-15 03:10 Message: Sorry. This can't work since MultiByteToWideChar cannot accept a string for the locale, it only accepts a small limited set of code pages such as CP_ACP, CP_UTF7 and CP_UTF8. MultiByteToWideChar has an advantage that it can be given a code page but this advantage is not used because the code page is fixed to CP_ACP. I suggest that MultiByteToWideChar() is replaced with mbstowcs() which would then make it consistent with that used in fopen() [in _open_r() specifically). I shall try this on my version. But I can't be sure it would work well for all languages. I'll get back. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-12-11 22:35 Message: A trick I've seen used to figure out the locale is int xx = setlocale("C", LC_ALL); (void) setlocale(xx, LC_ALL); The first call sets locale to "C" but also tells you what it was, the second call restores. You can do this to figure out the locale in XCEFixPathA, and use xx instead of CP_ACP. Would that fix your problem ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2912803&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:03:38
|
Bugs (use Trac instead) item #2942499, was opened at 2010-01-29 12:23 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2942499&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: v1.0 (example) >Status: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: achdawai (achdawai) Assigned to: Nobody/Anonymous (nobody) Summary: arm-mingw32ce-ar fails under mingw Initial Comment: I cross compiled the mingw32ce toolchain for i586-mingw32msvc. When run on windows, the ar program fails to generate a valid archive file. This does not happen all the time. The error is: arm-mingw32ce-gcc -o binary.exe src/console/console_win32.o src/console/CommandLineToArgvW.o -L. -lfoo -lbar -lloaderfs ./libloaderfs.a: file not recognized: File format not recognized collect2: ld returned 1 exit status mingw32-make: *** [ucvm-console.exe] Error 1 On linux the same makefile compiling the same binary from the same sources, the same libs and the same flags works fine. I'm aware this information is not sufficient to isolate the bug, I'm trying to get a simple testcase. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:03 Message: Mingw problem. Please feel free to suggest a patch in separate ticket. ---------------------------------------------------------------------- Comment By: achdawai (achdawai) Date: 2010-01-29 15:05 Message: The attachement is a winmerge display showing at the left, the header of the static lib generated by the mingw version, and on the right, the result of the SAME COMMAND LINE, run on windows. I will try to push this to the upstream bug tracker but I would like a sort of "confirmation". A zip of the toolchain I compiled is available at: http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100129+gdb.zip debug version at: http://www.unsads.com/~squalyl/cegcc/mingw32ce-4.1-20100129+gdb+dbg.zip ---------------------------------------------------------------------- Comment By: achdawai (achdawai) Date: 2010-01-29 12:37 Message: Here is a build log from win32 codeblocks, showing that ALL static libs are built without a glitch, but one of them is invalid. Running arm-mingw32ce-objdump.exe on this file brings the same error : format unrecognized. -------------- Build: arm-wince in libhal --------------- arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\hal\win32\debug.c -o Debug\arm-wince\obj\src\hal\win32\debug.o arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\hal\win32\infos.c -o Debug\arm-wince\obj\src\hal\win32\infos.o arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\hal\win32\mem.c -o Debug\arm-wince\obj\src\hal\win32\mem.o arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\hal\win32\vars.c -o Debug\arm-wince\obj\src\hal\win32\vars.o arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\hal\win32\arg.c -o Debug\arm-wince\obj\src\hal\win32\arg.o arm-mingw32ce-ar.exe -r -s Debug\arm-wince\libhal.a Debug\arm-wince\obj\src\hal\win32\debug.o Debug\arm-wince\obj\src\hal\win32\infos.o Debug\arm-wince\obj\src\hal\win32\mem.o Debug\arm-wince\obj\src\hal\win32\vars.o Debug\arm-wince\obj\src\hal\win32\arg.o arm-mingw32ce-ar.exe: creating Debug\arm-wince\libhal.a Output size is 6.18 KB -------------- Build: arm-wince in libloader --------------- arm-mingw32ce-gcc.exe -O2 -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\loader\loader_win32fs.c -o Debug\arm-wince\obj\src\loader\loader_win32fs.o arm-mingw32ce-ar.exe -r -s Debug\arm-wince\libloaderfs.a Debug\arm-wince\obj\src\loader\loader_win32fs.o arm-mingw32ce-ar.exe: creating Debug\arm-wince\libloaderfs.a Output size is 2.94 KB -------------- Build: arm-wince in ucvm-console --------------- arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\console\console_win32.c -o Debug\arm-wince\obj\src\console\console_win32.o arm-mingw32ce-gcc.exe -Wall -DDEBUG -DUNDER_CE -Iinclude -Iinclude\hal\win32 -c C:\sources\ucvm\trunk\src\console\CommandLineToArgvW.c -o Debug\arm-wince\obj\src\console\CommandLineToArgvW.o arm-mingw32ce-g++.exe -LDebug\arm-wince -o Debug\arm-wince\ucvm.exe Debug\arm-wince\obj\src\console\console_win32.o Debug\arm-wince\obj\src\console\CommandLineToArgvW.o -lucvm -lhal -lloaderfs Debug\arm-wince/libloaderfs.a: file not recognized: File format not recognized collect2: ld returned 1 exit status Process terminated with status 1 (0 minutes, 5 seconds) ---------------------------------------------------------------------- Comment By: achdawai (achdawai) Date: 2010-01-29 12:26 Message: forgot to mention, I'm compiling the gcc 4.1 sources from the latest svn trunk. ---------------------------------------------------------------------- Comment By: achdawai (achdawai) Date: 2010-01-29 12:26 Message: forgot to mention, I'm compiling the gcc 4.1 sources. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2942499&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 15:01:20
|
Bugs (use Trac instead) item #2942500, was opened at 2010-01-29 12:25 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2942500&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: Closed >Resolution: Works For Me Priority: 5 Private: No Submitted By: achdawai (achdawai) Assigned to: Nobody/Anonymous (nobody) Summary: ld.exe crashes on mingw when sources are compiled with -g Initial Comment: i'm working on the mingw port of the arm-mingw32ce toolchain, using gcc 4.1 sources and the latest cegcc trunk. the arm-mingw32ce-gcc binary, when called to link object files, crashes when any linked source is compiled with the -g flag. Removing the -g flag prevents the crash from happening. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 07:01 Message: Should be retried on POSIX-compliant system. If it works there, patch is expected, preferrably to mingw project for them to not segfault. As ticket is old, closing. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2942500&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:58:35
|
Bugs (use Trac instead) item #2958451, was opened at 2010-02-24 17:19 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2958451&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: CeGCC (arm-wince-cegcc) Group: None >Status: Closed >Resolution: Wont Fix Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Nobody/Anonymous (nobody) Summary: I tried compile sed, wget , gawk Initial Comment: I use Ubuntu 9.04 and cegcc-0.59.1.tar.bz2 . I tried compile sed-4.2.1.tar.bz2 but error. ----------------------------------------------------- -Wall -mms-bitfields -MT utils.o -MD -MP -MF .deps/utils.Tpo -c -o utils.o utils.c utils.c: In function 'follow_symlink': utils.c:363: error: 'S_IFLNK' undeclared (first use in this function) utils.c:363: error: (Each undeclared identifier is reported only once utils.c:363: error: for each function it appears in.) utils.c:371: warning: implicit declaration of function 'readlink' ----------------------------------------------------------- opt/cegcc/arm-cegcc/include/sys/stat.h ------------------------------------------------------------- #ifdef __CYGWIN__ #include <cygwin/stat.h> #ifdef _COMPILING_NEWLIB #define stat64 __stat64 #endif #else struct stat { dev_t st_dev; ino_t st_ino; mode_t st_mode; nlink_t st_nlink; uid_t st_uid; gid_t st_gid; dev_t st_rdev; off_t st_size; /* SysV/sco doesn't have the rest... But Solaris, eabi does. */ #if defined(__svr4__) && !defined(__PPC__) && !defined(__sun__) time_t st_atime; time_t st_mtime; time_t st_ctime; #else time_t st_atime; long st_spare1; time_t st_mtime; long st_spare2; time_t st_ctime; long st_spare3; long st_blksize; long st_blocks; long st_spare4[2]; #endif }; #endif #define _IFMT 0170000 /* type of file */ #define _IFDIR 0040000 /* directory */ #define _IFCHR 0020000 /* character special */ #define _IFBLK 0060000 /* block special */ #define _IFREG 0100000 /* regular */ #define _IFLNK 0120000 /* symbolic link */ #define _IFSOCK 0140000 /* socket */ #define _IFIFO 0010000 /* fifo */ #define S_BLKSIZE 1024 /* size of a block */ #define S_ISUID 0004000 /* set user id on execution */ #define S_ISGID 0002000 /* set group id on execution */ #ifndef _POSIX_SOURCE #define S_ISVTX 0001000 /* save swapped text even after use */ #define S_IREAD 0000400 /* read permission, owner */ #define S_IWRITE 0000200 /* write permission, owner */ #define S_IEXEC 0000100 /* execute/search permission, owner */ #define S_ENFMT 0002000 /* enforcement-mode locking */ #define S_IFMT _IFMT #define S_IFDIR _IFDIR #define S_IFCHR _IFCHR #define S_IFBLK _IFBLK #define S_IFREG _IFREG #define S_IFLNK _IFLNK #define S_IFSOCK _IFSOCK #define S_IFIFO _IFIFO #endif /* !_POSIX_SOURCE */ #ifdef _WIN32 /* The Windows header files define _S_ forms of these, so we do too for easier portability. */ #define _S_IFMT _IFMT #define _S_IFDIR _IFDIR #define _S_IFCHR _IFCHR #define _S_IFIFO _IFIFO #define _S_IFREG _IFREG #define _S_IREAD 0000400 #define _S_IWRITE 0000200 #define _S_IEXEC 0000100 #endif #define S_IRWXU (S_IRUSR | S_IWUSR | S_IXUSR) #define S_IRUSR 0000400 /* read permission, owner */ #define S_IWUSR 0000200 /* write permission, owner */ #define S_IXUSR 0000100/* execute/search permission, owner */ #define S_IRWXG (S_IRGRP | S_IWGRP | S_IXGRP) #define S_IRGRP 0000040 /* read permission, group */ #define S_IWGRP 0000020 /* write permission, grougroup */ #define S_IXGRP 0000010/* execute/search permission, group */ #define S_IRWXO (S_IROTH | S_IWOTH | S_IXOTH) #define S_IROTH 0000004 /* read permission, other */ #define S_IWOTH 0000002 /* write permission, other */ #define S_IXOTH 0000001/* execute/search permission, other */ #define S_ISBLK(m) (((m)&_IFMT) == _IFBLK) #define S_ISCHR(m) (((m)&_IFMT) == _IFCHR) #define S_ISDIR(m) (((m)&_IFMT) == _IFDIR) #define S_ISFIFO(m) (((m)&_IFMT) == _IFIFO) #define S_ISREG(m) (((m)&_IFMT) == _IFREG) #define S_ISLNK(m) (((m)&_IFMT) == _IFLNK) #define S_ISSOCK(m) (((m)&_IFMT) == _IFSOCK) int _EXFUN(chmod,( const char *__path, mode_t __mode )); int _EXFUN(fchmod,(int __fd, mode_t __mode)); int _EXFUN(fstat,( int __fd, struct stat *__sbuf )); int _EXFUN(mkdir,( const char *_path, mode_t __mode )); int _EXFUN(mkfifo,( const char *__path, mode_t __mode )); int _EXFUN(stat,( const char *__path, struct stat *__sbuf )); mode_t _EXFUN(umask,( mode_t __mask )); #if defined(__rtems__) || defined(__CYGWIN__) && !defined(__INSIDE_CYGWIN__) int _EXFUN(lstat,( const char *__path, struct stat *__buf )); int _EXFUN(mknod,( const char *__path, mode_t __mode, dev_t __dev )); #endif -------------------------------------------------------------- I'm not use Cygwin. I tried compile wget-1.12 , but error ------------------------------------------------------------ arm-cegcc-gcc -DHAVE_CONFIG_H -I. -I../src -D_WIN32_WCE=0x0400 -O3 -Wall -mms-bitfields -MT strcasestr.o -MD -MP -MF .deps/strcasestr.Tpo -c -o strcasestr.o strcasestr.c In file included from strcasestr.c:27: ./strings.h:27:26: error: strings.h: No such file or directory make[3]: *** [strcasestr.o] Error 1 ---------------------------------------------------------------- I tried compile gawk-3.1.7 , but error. ---------------------------------------------------------------- arm-cegcc-gcc -DDEFPATH="\".:/usr/local/wince/share/awk\"" -DHAVE_CONFIG_H -DGAWK -DLOCALEDIR="\"/usr/local/wince/share/locale\"" -I. -I./libsigsegv/src -D_WIN32_WCE=0x0400 -D_WIN32_IE=0x0400 -DNO_ERRNO_H -O3 -Wall -mms-bitfields -MT replace.o -MD -MP -MF .deps/replace.Tpo -c -o replace.o replace.c In file included from replace.c:47: missing_d/system.c:19: error: expected declaration specifiers or '...' before string constant missing_d/system.c:19: error: expected declaration specifiers or '...' before numeric constant missing_d/system.c:19: error: conflicting types for 'r_fatal' missing_d/system.c:19: note: a parameter list with an ellipsis can't match an empty parameter name list declaration awk.h:1162: note: previous declaration of 'r_fatal' was here missing_d/system.c: In function 'system': missing_d/system.c:24: error: argument 's' doesn't match prototype /opt/cegcc/lib/gcc/arm-cegcc/4.4.0/../../../../arm-cegcc/include/stdlib.h:122: error: prototype declaration make[2]: *** [replace.o] -------------------------------------------------------------------- Thanks, ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 06:58 Message: As described, non-WinCE code not being compilable with CeGCC is not a bug. If you have patches for 'cegcc' target to compile various packages, please submit them one by one in separate tickets. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2010-02-26 12:58 Message: Please provide accurate information about what you're doing and what exactly makes you suspect a problem in cegcc. ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2010-02-26 01:11 Message: config.sub change because use "--host=arm-cegcc" ------------------------------------------------------- c90) basic_machine=c90-cray os=-unicos ;; cegcc) basic_machine=arm-unknown os=-cegcc ;; ---------------------------------------------------------- | -chorusos* | -chorusrdb* | -cegcc* \ ------------------------------------------------------------ PATH=/opt/cegcc/bin:$PATH wget12 ./configure CC=arm-cegcc-gcc --prefix=/usr/local/wince --host=arm-cegcc LDFLAGS="-s" CPPFLAGS="-D_WIN32_WCE=0x0400 -DNO_ERRNO_H" CFLAGS="-O3 -Wall -mms-bitfields" --disable-opie --disable-digest --disable-ntlm --disable-debug --disable-largefile --disable-rpath --disable-ipv6 --disable-nls --disable-iri gawk and sed ./configure CC=arm-cegcc-gcc --prefix=/usr/local/wince --host=arm-cegcc LDFLAGS="-s" CPPFLAGS="-D_WIN32_WCE=0x0400" CFLAGS="-O3 -Wall -mms-bitfields" "LDFLAGS: --enable-auto-import" is configure error, so I'm not use. --------------------------------------------------------- I hope use wget and emacs. automake autoconf bison install ok. But texinfo gettext ncurses pdcurses ... are error. Configure check and make error says glibc headerfile not found. I can't compile wget and emacs. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2010-02-25 08:35 Message: What is your point ? I created a small test : #include <sys/stat.h> int x() { return S_IFLNK; } arm-cegcc-gcc -c test.c compiles this without problem. So I guess you may be using something different ? Also, I am not sure why you expect a source not written for CE to compile with cegcc without a problem. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2958451&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:55:15
|
Bugs (use Trac instead) item #3141753, was opened at 2010-12-22 08:20 Message generated for change (Comment added) made by pfalcon 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: 8 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: Paul Sokolovsky (pfalcon) Date: 2011-02-05 06:55 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- Comment By: Pedro Alves (pedroalves) Date: 2010-12-22 09: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...> - 2011-02-05 14:55:06
|
Bugs (use Trac instead) item #3165793, was opened at 2011-01-26 02:19 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3165793&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: https://www.google.com/accounts () Assigned to: Nobody/Anonymous (nobody) Summary: Error creating WinCE DLL Initial Comment: Hi all, i'm trying to create a WinCE DLL. I've created the original project under VS and i ported it under Eclipse+Mingw32+Mingw32CE. At the end of the compile phase I receive: **** Internal Builder is used for build **** g++ -LC:\Documents and Settings\mora\Documenti\Visual Studio 2005\Projects\VciProjects\EosTX32\VciLib\Release -LC:\Programmi\mingw32ce\arm-mingw32ce\lib\ ..\EosTX32.def --enable-stdcall-fixup -shared -oEosTX32.dll util.o stdafx.o log.o j2534fns.o Reg.o EosTX32.o -lvcilib ld: dllcrt3.o: No such file: No such file or directory Build error occurred, build is stopped Time consumed: 156 ms. but dllcrt3.o is under :\Programmi\mingw32ce\arm-mingw32ce\lib\ I inserted into the library path. Thanks ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 06:55 Message: Thanks for your bug report! To ease maintenance of the project, we are migrating bug tracking facilities to Trac. We would appreciate if you re-posted this bug on Trac via https://sourceforge.net/apps/trac/cegcc/newticket . Please include link to this bug for reference. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=3165793&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:47:16
|
Bugs (use Trac instead) item #2721601, was opened at 2009-03-29 18:26 Message generated for change (Comment added) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2721601&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: None Group: None >Status: Closed >Resolution: Wont Fix Priority: 1 Private: No Submitted By: Death Knight® (erdem_ua) Assigned to: Danny Backx (dannybackx) Summary: x86_64 Build Initial Comment: Hi, First of all thank you for this great project. I am 64bit linux user. And I have some problems with your release. Is it possible to release x86_64 bit for linux? Thank you. ---------------------------------------------------------------------- >Comment By: Paul Sokolovsky (pfalcon) Date: 2011-02-05 06:47 Message: We don't have resources to support all distros, recommended way to deal with such issues is to build from source. ---------------------------------------------------------------------- Comment By: Death Knight® (erdem_ua) Date: 2009-04-28 15:30 Message: Like librapi dependency. I also tried install librapi2 i586 rpm for opensuse but it doesn't work. I don't know if it possible to compile cegcc in 64 bit mode, but if you release x64 bit one, I prefer x64 bit one. Thank you. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-04-28 06:49 Message: Which problems exactly ? ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2721601&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:43:37
|
Bugs (use Trac instead) item #3141753, was opened at 2010-12-22 08:20 Message generated for change (Settings changed) made by pfalcon 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: 8 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 09: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...> - 2011-02-05 14:43:37
|
Bugs (use Trac instead) item #3141752, was opened at 2010-12-22 08:19 Message generated for change (Settings changed) made by pfalcon 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: 8 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: SourceForge.net <no...@so...> - 2011-02-05 14:32:58
|
Bugs (deprecated, use Trac) item #1768189, was opened at 2007-08-06 00:48 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1768189&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: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: Nobody/Anonymous (nobody) Assigned to: Pedro Alves (pedroalves) Summary: LocalLock and LocalUnlock - winbase.h Initial Comment: Compiler: arm-wince-mingw32ce SVN version: 1039 Compiled from source under Cygwin. Problem: undefined externals after linking UPP example See http://www.ultimatepp.org and http://www.ultimatepp.org/forum/index.php?t=msg&goto=10942&#msg_10942 Possible cause: LocalLock and LocalUnlock are defined as macros in Microsoft's winbase.h - but in cegcc, these macros aren't defined. I changed winbase.h so the definitions of these functions are: #ifndef _WIN32_WCE WINBASEAPI PVOID WINAPI LocalLock(HLOCAL); WINBASEAPI BOOL WINAPI LocalUnlock(HLOCAL); WINBASEAPI HLOCAL WINAPI LocalHandle(LPCVOID); WINBASEAPI UINT WINAPI LocalFlags(HLOCAL); /* Obsolete: Has no effect. */ #else #define LocalLock(X) ((LPVOID)(X)) #define LocalUnlock(X) (0) #define LocalHandle(X) ((HLOCAL)(X)) #define LocalFlags(X) (0) #endif ---------------------------------------------------------------------- Comment By: Pedro Alves (pedroalves) Date: 2007-08-06 14:40 Message: Logged In: YES user_id=1370634 Originator: NO Hi, The Local* patch is unacceptable, since we should never copy MSFT copyrighted code while doing our headers. Luckilly, I have had implementations for those in my tree for months now - they were needed for my Qt4 port. See the changelog of the commit for more details. Anyway, thanks for triggering me to finally commit that. I'm also committing a patch quite similar to what you posted to remove the W suffix from GetCharABCWidths. Thanks for reporting! Notice that we usually request people to provide a changelog entry. Since this change was close to a one-liner, this time you'll get by ;) Cheers, Pedro Alves ---------------------------------------------------------------------- Comment By: Nobody/Anonymous (nobody) Date: 2007-08-06 06:14 Message: Logged In: NO The actual changes I made to the include files are: Index: wingdi.h =================================================================== --- wingdi.h (revision 1039) +++ wingdi.h (working copy) @@ -2797,13 +2797,13 @@ WINGDIAPI int WINAPI GetBkMode(HDC); WINGDIAPI UINT WINAPI GetBoundsRect(HDC,LPRECT,UINT); WINGDIAPI BOOL WINAPI GetBrushOrgEx(HDC,LPPOINT); -WINGDIAPI BOOL WINAPI GetCharABCWidthsA(HDC,UINT,UINT,LPABC); -WINGDIAPI BOOL WINAPI GetCharABCWidthsW(HDC,UINT,UINT,LPABC); WINGDIAPI BOOL WINAPI GetCharABCWidthsFloatA(HDC,UINT,UINT,LPABCFLOAT); WINGDIAPI BOOL WINAPI GetCharABCWidthsFloatW(HDC,UINT,UINT,LPABCFLOAT); WINGDIAPI DWORD WINAPI GetCharacterPlacementA(HDC,LPCSTR,int,int,LPGCP_RESULTSA,DWORD); WINGDIAPI DWORD WINAPI GetCharacterPlacementW(HDC,LPCWSTR,int,int,LPGCP_RESULTSW,DWORD); #ifndef _WIN32_WCE +WINGDIAPI BOOL WINAPI GetCharABCWidthsA(HDC,UINT,UINT,LPABC); +WINGDIAPI BOOL WINAPI GetCharABCWidthsW(HDC,UINT,UINT,LPABC); WINGDIAPI BOOL WINAPI GetCharWidth32A(HDC,UINT,UINT,LPINT); WINGDIAPI BOOL WINAPI GetCharWidth32W(HDC,UINT,UINT,LPINT); WINGDIAPI BOOL WINAPI GetCharWidthA(HDC,UINT,UINT,LPINT); @@ -2811,6 +2811,7 @@ WINGDIAPI BOOL WINAPI GetCharWidthFloatA(HDC,UINT,UINT,PFLOAT); WINGDIAPI BOOL WINAPI GetCharWidthFloatW(HDC,UINT,UINT,PFLOAT); #else +WINGDIAPI BOOL WINAPI GetCharABCWidths(HDC,UINT,UINT,LPABC); WINGDIAPI BOOL WINAPI GetCharWidth32(HDC,UINT,UINT,LPINT); #endif WINGDIAPI int WINAPI GetClipBox(HDC,LPRECT); @@ -3099,10 +3100,10 @@ #define EnumICMProfiles EnumICMProfilesW #define ExtTextOut ExtTextOutW #define GetCharABCWidthsFloat GetCharABCWidthsFloatW -#define GetCharABCWidths GetCharABCWidthsW #define GetCharacterPlacement GetCharacterPlacementW #ifndef _WIN32_WCE #define GetCharWidth32 GetCharWidth32W +#define GetCharABCWidths GetCharABCWidthsW #endif #define GetCharWidthFloat GetCharWidthFloatW #define GetCharWidth GetCharWidthW Index: winbase.h =================================================================== --- winbase.h (revision 1039) +++ winbase.h (working copy) @@ -1660,6 +1660,7 @@ WINBASEAPI VOID WINAPI GlobalFix(HGLOBAL); /* Obsolete: Has no effect. */ WINBASEAPI UINT WINAPI GlobalGetAtomNameA(ATOM,LPSTR,int); WINBASEAPI UINT WINAPI GlobalGetAtomNameW(ATOM,LPWSTR,int); + #ifndef _WIN32_WCE WINBASEAPI HGLOBAL WINAPI GlobalAlloc(UINT,DWORD); WINBASEAPI HGLOBAL WINAPI GlobalFree(HGLOBAL); @@ -1679,6 +1680,7 @@ # define GlobalSize(lp) LocalSize(lp) # define GlobalFlags(lp) LocalFlags(lp) #endif + WINBASEAPI VOID WINAPI GlobalMemoryStatus(LPMEMORYSTATUS); #if (_WIN32_WINNT >= 0x0500) WINBASEAPI BOOL WINAPI GlobalMemoryStatusEx(LPMEMORYSTATUSEX); @@ -1776,16 +1778,26 @@ WINBASEAPI SIZE_T WINAPI LocalCompact(UINT); /* Obsolete: Has no effect. */ WINBASEAPI HLOCAL LocalDiscard(HLOCAL); WINBASEAPI BOOL WINAPI LocalFileTimeToFileTime(CONST FILETIME *,LPFILETIME); -WINBASEAPI UINT WINAPI LocalFlags(HLOCAL); /* Obsolete: Has no effect. */ WINBASEAPI HLOCAL WINAPI LocalFree(HLOCAL); -WINBASEAPI HLOCAL WINAPI LocalHandle(LPCVOID); -WINBASEAPI PVOID WINAPI LocalLock(HLOCAL); WINBASEAPI HLOCAL WINAPI LocalReAlloc(HLOCAL,SIZE_T,UINT); WINBASEAPI SIZE_T WINAPI LocalShrink(HLOCAL,UINT); /* Obsolete: Has no effect. */ WINBASEAPI UINT WINAPI LocalSize(HLOCAL); -WINBASEAPI BOOL WINAPI LocalUnlock(HLOCAL); WINBASEAPI BOOL WINAPI LockFile(HANDLE,DWORD,DWORD,DWORD,DWORD); WINBASEAPI BOOL WINAPI LockFileEx(HANDLE,DWORD,DWORD,DWORD,DWORD,LPOVERLAPPED); + +#ifndef _WIN32_WCE +WINBASEAPI PVOID WINAPI LocalLock(HLOCAL); +WINBASEAPI BOOL WINAPI LocalUnlock(HLOCAL); +WINBASEAPI HLOCAL WINAPI LocalHandle(LPCVOID); +WINBASEAPI UINT WINAPI LocalFlags(HLOCAL); /* Obsolete: Has no effect. */ +#else +#define LocalLock(X) ((LPVOID)(X)) +#define LocalUnlock(X) (0) +#define LocalHandle(X) ((HLOCAL)(X)) +#define LocalFlags(X) (0) +#endif + + #ifdef _WIN32_WCE #define LockResource(h) ((PVOID)(h)) #else ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=1768189&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:32:51
|
Bugs (deprecated, use Trac) item #2574606, was opened at 2009-02-06 15:37 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2574606&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: None Group: None Status: Closed Resolution: Fixed Priority: 5 Private: No Submitted By: rikky (rikky) Assigned to: Danny Backx (dannybackx) Summary: windres can't detect architecture Initial Comment: Always got this error compiling cegcc: arm-cegcc-windres.exe: can't detect architecture Had to change just one line in windres.c to make it work. I use svn-revision 1214. ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-02-08 03:20 Message: Applied your patch, thanks. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2574606&group_id=173455 |
|
From: SourceForge.net <no...@so...> - 2011-02-05 14:32:48
|
Bugs (deprecated, use Trac) item #2896500, was opened at 2009-11-12 01:35 Message generated for change (Settings changed) made by pfalcon You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&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: None Group: None Status: Open Resolution: Accepted Priority: 5 Private: No Submitted By: Ivan Maidanski (ivmai) Assigned to: Danny Backx (dannybackx) Summary: Patch for GCC float.h Initial Comment: Without this patch, I have to set c_include_path=/cygdrive/C/x86mingw32ce/i386-mingw32ce/include. The same problem exists in mingw-w64 project, see: https://sourceforge.net/tracker/index.php?func=detail&aid=2363741&group_id= 202880&atid=983354 The patch should be really sent to GCC but I'd like to know your opinion. I use __MINGW32__ to identify toolchains that have MS-specific float.h (i.e., for CeGCC toolchains, they are mingw32ce and x86mingw32ce but not cegcc). Should be correct, right? ---------------------------------------------------------------------- Comment By: Ivan Maidanski (ivmai) Date: 2009-11-14 08:33 Message: > Also yes sending it to GCC makes sense. Unfortunately, it seems it doesn't... See this post: https://sourceforge.net/tracker/?func=detail&aid=2896485&group_id=202880&atid=983356 This post also suggests another solution - copy the contents of gcc float.h into the specific mingw one and remove the gcc one. > I'm not sure why you define the _NEXT_FLOAT_H_ macro though. This is just a guard against infinite recursion between a specific float.h and a gcc one (they may both do include_next each other (before checking for _FLOAT_H) in some toolchains). _NEXT_FLOAT_H_ is not used anywhere else (and is unique as reported by google codesearch). ---------------------------------------------------------------------- Comment By: Danny Backx (dannybackx) Date: 2009-11-13 23:22 Message: You're saying that the gcc float.h overrides the mingw one. Yes that does make sense. Also yes sending it to GCC makes sense. I'm not sure why you define the _NEXT_FLOAT_H_ macro though. Your proposed use of __MINGW32__ looks right. __MINGW32__ is indeed defined by both {arm,i386}-mingw32ce-gcc . arm-cegcc-gcc doesn't appear to have this situation and it doesn't define __MINGW32__. ---------------------------------------------------------------------- You can respond by visiting: https://sourceforge.net/tracker/?func=detail&atid=865514&aid=2896500&group_id=173455 |
15 messages has been excluded from this view by a project administrator.
