Hi,
> >> Could you give a link to your bugzilla report ?
> >
> > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=43047
> >
> >> Would it be difficult to apply cegcc changes to the latest gcc
> > version
> >> (gcc-4.4.3) ?
> >
> > Maybe not difficult, but I am not sure what you hope to prove by that.
>
Hi,
When trying to compile ACE/TAO using cegcc i386 head I get this warning
below, any idea how to resolve this --export-dynamic warning? As you can see
we are not using --export-dynamic
Johnny
rm -f .shobj//libACEXML_Parser.dll.def.old .shobj//libACEXML_Parser.dll.def;
i386-mingw32ce-dlltool --
Hi,
Our daily build shows that recently the x86 toolchain doesn't compile
anymore. I don't get a gi386-mingw32ce-g++ compiler anymore.
I use:
../build-x86.sh > /home/build/cegcc.txt > /home/build/cegccbuild.txt
The full build log is at:
http://www.dre.vanderbilt.edu/~remedynl/cegccbuildwin.txt
Hi,
> How did you test it?
I got this forwarded from someone who tries to use loki with cegcc. I will
recheck his email and files to see where his problem is.
Johnny
>
>> Johnny
>>
>> http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
>> http://msdn.microsoft.com/en-us/library
Hi,
We found that in limits.h UCHAR_MAX is not defined, can someone have a look
at this?
Johnny
http://www.opengroup.org/onlinepubs/009695399/basedefs/limits.h.html
http://msdn.microsoft.com/en-us/library/296az74e%28VS.71%29.aspx
Hi,
For WinCE testing we use iBoots to remotely power off/on the WinCE device. See
http://www.dataprobe.com/
Johnny
> A couple of weeks ago I've cleaned up a bit the gcc patch against
> upstream gcc trunk (r155193, close to future gcc 4.5), ending up
> with this.
>
> I got a bit stuck with the
Hi,
> > Has anyone tried to link an executable that consists of some
> libraries
> > compiled with msvc and some with cegcc? Will that work?
>
> I seem to recall that this has popped up and got answered a long time
> ago but I cannot seem to find it in archives.
>
> I believe mingw has a similar
Hi,
Has anyone tried to link an executable that consists of some libraries
compiled with msvc and some with cegcc? Will that work?
Johnny
--
Come build with us! The BlackBerry® Developer Conference in SF, CA
is the onl
Hi,
> > > Looks like Pedros last commit changed the build in src/mingw .
> >
> > Fixed, I think.
>
> Thanks!
Thanks. I have restarted our cegcc build and will start the ACE build when
that is ready.
Johnny
--
Let Crys
Hi,
It looks this profile directory was not compiled before the latest mingw
import but got enabled as part of this import (see rev 1373, #
cegcc\src\mingw\Makefile.in)
Johnny
> -Original Message-
> From: Johnny Willemsen [mailto:jwillem...@remedy.nl]
> Sent: dinsdag 8 septembe
Hi,
On the console I got the errors that prevent svn head to compile, see below.
Johnny
i386-mingw32ce-ar: creating libmingwex.a
/home/build/cegcc/src/mingw/profile/profil.c: In function 'profile_on':
/home/build/cegcc/src/mingw/profile/profil.c:121: error: 'errno' undeclared
(first use in this
Hi,
I have a problem compiling svn head, I don't see an error but I don't get a
core dll under opt/x86mingw32ce/i386-mingw32ce/lib/
My build log:
http://www.dre.vanderbilt.edu/~remedynl/cegccbuild.txt
Anyone an idea?
Johnny
Compilation steps:
cd /home/build/cegcc/
svn up
cd /home/build/cegcc/
Hi,
The correct usage of declspec export/import has fixed several problems. We
have now been able to narrow another runtime problem we see.
We have a base class, ACE_Reactor_Impl, from that we have derived
ACE_Select_Reactor_Impl (all in the ACE library). In our code we do:
this->select_re
Hi,
> Our first test results with gcc 4.4 dynamic libraries are available. We
> do
> have some more test failures than in the static case which need to be
> investigated. One is from the Based_Pointer_Test and its output is
> below. We
> have the ACE DLL and then an own DLL. From the executable an
Hi,
Our first test results with gcc 4.4 dynamic libraries are available. We do
have some more test failures than in the static case which need to be
investigated. One is from the Based_Pointer_Test and its output is below. We
have the ACE DLL and then an own DLL. From the executable and our own DL
Hi,
> FYI - Dave Korn has been helping me to track down the problem. That's
> not been on this list lately, but on the binut...@sourceware.org list.
>
> I believe I have found and fixed the cause of the problem now.
We have done some changes to our build/tests with assistance of Danny and we
hav
Hi Danny,
> FYI - Dave Korn has been helping me to track down the problem. That's
> not been on this list lately, but on the binut...@sourceware.org list.
>
> I believe I have found and fixed the cause of the problem now.
The build of ACE and its tests is ready. The tests are running and so far
Hi,
> FYI - Dave Korn has been helping me to track down the problem. That's
> not been on this list lately, but on the binut...@sourceware.org list.
>
> I believe I have found and fixed the cause of the problem now.
GREAT
I already configured our daily build to use the DLL version. It will
Hi,
This is great news. So the next major issue to tackle is the ostream issue
with x86.
Johnny
> I think I finally figured out the problem with floating point in the
> ARM
> gcc-4.4.0 tree.
>
> The summary of the fix : there are several source files for floating
> point support. gcc/config/arm
Hi,
Danny is currently on vacation. Besides the float issue there is the
iostream exception when using x86 and shared libraries.
Johnny
> cegcc-4.4 doesn't seem to make any progress ? Could someone give a
> current
> status of what is missing/not working ?
> I can see that float issues have been
Hi,
> > > int fileno (FILE*);
> > > void *_fileno (FILE*);
> >
> > I think this will not work.
>
> Why? I'm curious; are you using fileno instead of _fileno?
I missed the _
> If you're porting some code to CE that is using the posixy
> open/read/write etc. and getting at the file descriptor wi
> Sent: maandag 6 juli 2009 12:16
> To: jwillem...@remedy.nl
> Cc: cegcc-devel@lists.sourceforge.net; danny.ba...@scarlet.be
> Subject: Re: [Cegcc-devel] TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE in
> resource files
>
> On Monday 06 July 2009 07:50:59, Johnny Willemsen wrote:
> > &g
Hi,
> > You need to either make both calls be to __main, or to __gccmain,
> never to both.
>
> I think I fixed that one already.
>
> Right now, a constructor from libstdc++ is dying when it gets called
> for the first time.
>
> It happens to get mentioned in a linker message about auto-import.
Hi,
> > > I'll try changing the definition of fileno to void *, we'll see
> what
> > > breaks :-)
> >
> > Compiling live555 now fails on some lines that use fileno(), with:
> >
> > error: invalid conversion from 'void*' to 'int'
> >
> > Just saying.
> >
>
> Yes, that was why I made it return an i
Hi,
> > Add -D_WIN32_IE=0x0500 or so to your environment.
>
> I feel like I said this a million times now.
> Please stop spreading this wrong advice. You should
> never need to define _WIN32_IE on Windows CE. If our headers
> require it to expose some definitions needed for CE, then we
> need t
Hi,
> This was clearly an error but I can explain and fix it.
>
> There were overlapping main/gccmain (or so) functions in src/mingw and
> src/gcc-4.4.0/gcc/libgcc2.c . Both were calling constructors and
> destructors.
>
> Now, here's a debug session that shows that the constructor of the
> iost
Hi,
> > My mistake. I changed configure.ac and regenerated configure, but
> then
> > only committed configure.ac .
> >
> > Can you try again ?
>
> CEGCC did compile now, thanks. I am now rebuilding ACE/TAO with this
> new
> compiler.
ACE and TAO do compile, we only have one error in one of the p
Hi,
> My mistake. I changed configure.ac and regenerated configure, but then
> only committed configure.ac .
>
> Can you try again ?
CEGCC did compile now, thanks. I am now rebuilding ACE/TAO with this new
compiler.
Johnny
--
Hi,
> My mistake. I changed configure.ac and regenerated configure, but then
> only committed configure.ac .
>
> Can you try again ?
Build is restarted.
Johnny
--
Crystal Reports - New Free Runtime and 30 Day Trial
Ch
Hi,
It still looks to fail, attached the config.log
Johnny
> -Original Message-
> From: Danny Backx [mailto:danny.ba...@scarlet.be]
> Sent: zondag 14 juni 2009 10:17
> To: Dave Korn
> Cc: cegcc-devel@lists.sourceforge.net
> Subject: Re: [Cegcc-devel] Problem compling GCC 4.4 with Cygwin
Hi,
> Johnny, can you test your build ? My change appears to do the right
> thing.
I have restarted our builds, new results tomorrow, thanks for your work
Johnny
--
Crystal Reports - New Free Runtime and 30 Day Trial
C
uot;(cached) $ECHO_C" >&6
> else
> # Double quotes because CPP needs to be expanded
> for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
> do
> ac_preproc_ok=false
> ...
>
>
>
> On Fri, 20
> # Double quotes because CPP needs to be expanded
> for CPP in "$CC -E" "$CC -E -traditional-cpp" "/lib/cpp"
> do
> ...
>
> Or, is the variable CPP set to /lib/cpp in the environment ?
>
> Danny
>
&g
" 5524 lines long, doesn't contain the word
> sanity.
>
> Danny
>
> On Thu, 2009-06-11 at 14:12 +0200, Johnny Willemsen wrote:
> > Hi,
> >
> > I am trying to compile GCC 4.4 with Cygwin but got the following
> error
> > below. Seems a path
Hi,
> Ok, I'll drop this from my todo list.
> Next priority was & is to get gdb + gdbserver to work for x86.
It seems that static already a lot works. See the link below, the run of
today was using shared.
http://download.theaceorb.nl/teststat/builds/WinCE6_CEgcc_Suse_11.1.html
The run before th
Hi,
> gcc code may user more of the stack than whatever code that msvc
> produces, thus
> dipping into the red zone more often. So far, I don't see how the 64k
> limit of the
> stack on the main thread can be avoided at all..
The only option I see (which also Danny proposed) is to create a worker
Hi,
I have compiled the test program also with msvc for the ebox4300 device. It
seems msvc has the same behavior, the stack66000 fails.
It is strange why some of our tests do fail with gcc and not with msvc due to
the stack issue. Seems we can't resolve this with cegcc, it is something in
win
Hi,
I just noticed that the svn archive also contains all files from CVS, like
the ones below and .cvsignore. Should these really be in the svn archive?
Johnny
Asrc/binutils/include/elf/CVS
Asrc/binutils/include/elf/CVS/Repository
Asrc/binutils/include/elf/CVS/Root
Asrc/binutils/
Hi,
> > So now the only problem we have with gcc-4.4 is about floating point
> I
> > suppose.
>
> I believe there are actually three, but I never spoke about the others
> :
> - (as you said) floating point on ARM
> - for libstdc++ to work right, mingw startup needs a better atexit(),
> this can
Hi,
We use libcoredll6 to get the WinCE 6 methods. We now switched a build to
GCC 4.4 but this doesn't seem to build this anymore.
We only see:
bu...@suse111-cegcc052:~/opt/x86mingw32ce/i386-mingw32ce/lib> ls -al | grep
core
-rw-r--r-- 1 build users 1211720 2009-06-03 21:05 libcoredll.a
To use l
Hi,
Thanks very much. Danny could you check Vincent patches? Maybe there are
changes that have to applied also to the gcc 4.1 x86 toolchain.
Johnny
> >> I've not looked into this sufficiently, but I got a similar problem
> >> solved in src/mingwdll/libstdc++ by changing the Makefile like this
>
-lgcc_s # -lws2
we don't link with these libries we use:
LIBS += -lcoredll -lmingw32 -lmingwex -lws2 -lsupc++ -liphlpapi
>From what I read from the web the compiler probably uses normal exception
instead of SJLJ exceptions
Johnny
>
> Danny
>
> On Mon, 2009-06-01 at 07:52 +02
Hi,
When I try the new GCC 4.4 toolchain for x86 I do get these errors when
linking the ACE library. We didn't had this issue with the previous
toolchain.
For a full build log:
http://www.dre.vanderbilt.edu/~remedynl/suse111gegcc052/index.html
Johnny
/home/build/ACE/cegcc/ACE_wrappers/ace/Guard
Hi,
> Hmm, that could be a problem either in stack probing or in the
> calculation
> layout and handling of large stack frames. I haven't tried the x86
> compiler
> yet but I'll probably take a look at it some time soon-ish.
Thanks already. Danny will probably pick up his x86 target today, the
Hi,
> > It seems -Wl,--stack=0x800 works:
> > SizeOfStackReserve 0800
> > SizeOfStackCommit 1000
> > SizeOfHeapReserve 0010
> > SizeOfHeapCommit1000
> >
> > The question is more how this is used, do we really get a 2Mb st
000147be
> Subsystem 0009(Wince CUI)
> DllCharacteristics
> SizeOfStackReserve 0020
> SizeOfStackCommit 1000
> SizeOfHeapReserve 0010
> SizeOfHeapCommit1000
> LoaderFlags
Hi
What is the default stack size for the main thread when I compile with CEGCC
x86? With MSVC I think it is 1MB. The reason I ask is that I have some tests
that seem to end because of a stack overflow. Danny, for example
tests/Bug_1890_Regression_Test.cpp.
We allocate a fairly large object on t
Hi,
> Done
Thanks. I can confirm that our multicast_test is now working without
problems. This should also fix other tests that are failing!
Johnny
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. Ca
ither these are CE-specific values, or they're CE on X86 specific.
> I've never seen the latter, so I'll change our ws2tcpip.h file to
> define
> those macros to their old values if on CE.
>
> If someone thinks this is wrong, please yell :-)
>
> Danny
>
Hi,
> The file ws2tcpip.h contains these macros, along with a bunch of
> comments. Inside some of the comments are "old value" notes, e.g. :
> #define IP_TOS 3 /* old (winsock 1.1) value 8 */
> #define IP_TTL 4 /* old value 7 */
>
> These old values match wha
Hi,
Some of our IP tests did fail and after debugging for some time I found that
setting some IP options didn't work as expected. I made the following code
to check the correct defines for the IP_* values based on the winsock.h and
ws2tcpip.h files, there were some differences between these two an
Hi,
The _DSCP_TRAFFIC_TYPE enum is lacking from CEGCC, see MSDN
Johnny
http://msdn.microsoft.com/en-us/library/aa916382.aspx
--
Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT
is a gathering of tec
logging output, it says "Pocket CMD v 6.00" so just
to know, is this an open source application?
Thanks, Pablo
On Wed, May 20, 2009 at 8:41 AM, Johnny Willemsen
wrote:
Hi,
I have just run the first TAO Hello World test with success. We used an eBox
4300 target running Windows CE 6 whi
Hi,
I have just run the first TAO Hello World test with success. We used an eBox
4300 target running Windows CE 6 which ran the TAO CORBA server. A linux
system was running the CORBA client. The client made a remote invocation
which returned the correct value. Attached the logging output of this t
Hi,
> Fixed.
Thanks.
If we do a svn up of cegcc, do we then get gcc 4.3.2 again default or gcc
4.4? We would prefer to stay on 4.3.2 until we know for sure 4.4 works for
x86
Johnny
--
Crystal Reports - New Free Runti
tested much. This is part of
> src/mingw/mingwex .
>
> Danny
>
> On Tue, 2009-05-19 at 13:42 +0200, Johnny Willemsen wrote:
> > We see a problem with readdir, we only get 1 file back instead of the
> full
> > directory when iterating. Are there known iss
Hi,
> Apologies, I overlooked that this was a separate problem.
>
> Add -D_WIN32_IE=0x0500 or so to your environment.
> When windres doesn't find something, this is usually the cause.
Great, that worked! We have now the full ACE distribution compiling with no
errors, just a few warnings left.
J
Hi,
> -lcommctrl ?
Yes, that work.
Any idea about the TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE?
Johnny
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the new simplified licensing option that enables
unli
Hi,
We see a problem with readdir, we only get 1 file back instead of the full
directory when iterating. Are there known issues with readdir?
Johnny
--
Crystal Reports - New Free Runtime and 30 Day Trial
Check out the
Hi,
A question, I have the attached resource files which doesn't compile with
i386-mingw32ce-windres.
It seems the problem is TBSTYLE_DROPDOWN | TBSTYLE_AUTOSIZE. Is this not
supported or do I miss a thing.
Compile it with:
i386-mingw32ce-windres -D_WIN32_WCE=0x600 -DUNICODE=1 -D_UNICODE=1
-D_
Hi,
> According to
> http://fpc.freedoors.org/fpc-2.2.0.source/rtl/win/sysosh.inc
> the definition should be something like the patch below says.
>
> The copyright on this stuff is LGPL so I can take it over.
>
> I'm not sure how this can cause crashes in your application though.
After the ch
Hi,
> According to
> http://fpc.freedoors.org/fpc-2.2.0.source/rtl/win/sysosh.inc
> the definition should be something like the patch below says.
>
> The copyright on this stuff is LGPL so I can take it over.
>
> I'm not sure how this can cause crashes in your application though.
Thanks. I am
Hi,
> Hmm, confusing stuff.
Yes, it is ;-)
> On http://msdn.microsoft.com/en-us/library/ms860492.aspx you'll find
> that _fileno returns an int value. I believe that _fileno and fileno
> are
> the same, but I may be mistaken.
>
> MSDN also mentions that _fileno is ISO C++ conformant, and fileno
Hi,
> If ExitProcess is a function without a return value, then
> the return statement you write in the example below is not valid. So
> the
> compile error is justified.
>
> Or am I missing something ?
Bad example code ;-), the return was a left over I shouldn't have added
Try to just call
::
Hi,
> I've looked on the internet a bit and can't find much info.
>
> We've inherited the declarations we use from another project, it is not
> CE specific. So the issue might be that some versions of Windows do
> have
> a RecursionCount field, and otherd do not.
The CRITICAL_SECTION definition
Hi,
Btw, WinCE ships with ExitProcess, see
http://msdn.microsoft.com/en-us/library/ms885217.aspx
Johnny
> We have a compile problem when trying to use ExitProcess. Using it
> without
> return works (see the example with value 3), but using it with return
> results in a compile error (see 4). I t
Hi,
The program below does compile file with msvc, but not with cegcc. We then
get the error:
exitpr.cpp: In function 'int main(int, char**)':
exitpr.cpp:6: error: invalid conversion from 'int' to 'void*'
Johnny
#include
int main (int argc, char*[])
{
FILE* a;
void * b = filen
Hi,
We have a compile problem when trying to use ExitProcess. Using it without
return works (see the example with value 3), but using it with return
results in a compile error (see 4). I think the ExitProcess should be an
inline function instead of a define.
Johnny
#include
int main (int argc,
Hi,
We have currently 20 failing test with MSVC on CE x86, but 43 with CEGCC. We
are looking at the differences and found an interesting issue. The program
below doesn't compile with the MSVC compiler (struct CRITICAL_SECTION
doesn't have member RecursionCount), but it does compile with the CEGCC
Hi,
> I think we have this, but with dll's we didn't use the lib prefix which
> also
> worked, but probably with static we need the lib prefix. We will update
> our
> build files tomorrow and try with the lib prefix.
With lib prefix and static linking the exception test as part of ACE does
work.
Hi,
> > Seems -static doesn't work yet for ACE. When I create the ACE.dll,
> and want
> > to link it with an executable using -static, which files do I now
> need? Ld
> > complains that it can't find -lACE, do I need ACE.a, ACE.lib?
>
> If you create dynamic / shared libraries / dlls, then the wa
Hi,
> I think I mixed two options at our side. I am retesting with just -
> static at
> this moment.
Seems -static doesn't work yet for ACE. When I create the ACE.dll, and want
to link it with an executable using -static, which files do I now need? Ld
complains that it can't find -lACE, do I need
Hi,
I think I mixed two options at our side. I am retesting with just -static at
this moment.
Johnny
> I am trying to use -static to workaround the exception problem. When I
> now
> create our own library (ACE), what is the file extension that it should
> use?
> We have now .a but that doesn't w
Hi,
I am trying to use -static to workaround the exception problem. When I now
create our own library (ACE), what is the file extension that it should use?
We have now .a but that doesn't work when linking our executable that uses
that ACE lib. I can start experimenting, but maybe someone has used
Hi,
> > The question is now what todo. We do support GCC 4.4 with ACE/TAO, so
> > upgrading to cegcc with gcc 4.4. will not be a big issue for us.
> Seems a
> > decision at the side of cegcc which gcc compiler to support.
>
> I see another question. I've been looking for convincing reasons and
>
Hi,
> You're going to like this.
Yes, I like this ;-)
> I have taken up a gcc-trunk copy I took a while ago (two months or so
> before the gcc-4.4 release) and got it to work.
>
> The dynamic version of the libstdc++ DLL works there.
>
> See below.
The question is now what todo. We do support
Hi,
> > Would the gcc/mingw people have an idea where to search?
>
> It appears to be a DLL issue : when I compile with -static, the test
> program does work (on ARM).
>
> Johnnym, can you test on x86 ?
With x86 also -static resolves the problem.
FWIW, mingw gcc 3.4 doesn't have this issue on
Hi,
> I suspect that the warnings from LD are accurate in this case :
>
> This should work unless it involves constant data structures
> referencing symbols from auto-imported DLLs.
We do use enable-auto-import so far as I know. Will test a few things.
Johnny
-
Hi,
> > Would the gcc/mingw people have an idea where to search?
>
> It appears to be a DLL issue : when I compile with -static, the test
> program does work (on ARM).
>
> Johnnym, can you test on x86 ?
We will test this asap on our device. There are references of throwing
exceptions from dll's
Hi,
> > This looks a real major issue, if try/catch doesn't work then a lot
> of C++
> > programs (including TAO) don't work.
>
> It looks like we end up in the default exception handler, see
> src/gcc/libstdc++-v3/docs/html/18_support/howto.html
> Its source is in
> src/gcc/libstdc++-v3/libs
Hi,
> On Fri, 2009-05-15 at 11:02 +0200, Johnny Willemsen wrote:
> > This looks a real major issue, if try/catch doesn't work then a lot
> of C++
> > programs (including TAO) don't work.
>
> It looks like we end up in the default exception handler, see
Hi,
> I've added a line in the catch phrase to assess whether it gets there.
>
> On ARM, the program doesn't cause the usual CE Error report, so I guess
> it doesn't really crash.
Does it print the next line?
terminate called after throwing an instance of 'Except'
> It never makes it into the c
Hi,
> A small reproducer is attached, gives on our x86 target:
> throw
> terminate called after throwing an instance of 'Except'
The static method is not needed, just a throw from a C++ exception causes
the abort? Maybe some configuration setting is lacking. Can someone try the
same program with
Hi,
A small reproducer is attached, gives on our x86 target:
throw
terminate called after throwing an instance of 'Except'
Johnny
> Are there any known problems with C++ exceptions?
>
> We have a test that throws a C++ exception which we catch higher up in
> the
> call chain. We now see with CE
Hi,
Are there any known problems with C++ exceptions?
We have a test that throws a C++ exception which we catch higher up in the
call chain. We now see with CEGCC x86 the following output.
Johnny
\network\temp\ACE_wrappers\tests> Reactor_Exceptions_Test
Reactor_Exceptions_Test
terminate call
Hi,
When an application crashes on CE we see a nice dialog saying that the
application has unexpected behavior. On regular windows we disable all
message boxes as below. I haven't found a way todo the same with CE, anyone
an idea to get rid of that message box?
Johnny
_CrtSetReportMode
Hi,
I just found that structured exception handling (__try, __except, __finally)
is not supported with cegcc. Are there plans/ideas to add this?
Johnny
See for example
http://msdn.microsoft.com/en-us/library/ms924251.aspx
http://code-factor.blogspot.com/2007/04/windows-ce-seh-for-arm-with-gcc.ht
Hi,
We have in ACE a Singleton template that is implemented in a C++ template
with a static member.
We are now using a test program that is linked with the ACE dll and checks
this singleton pointer. The program uses another dll that also uses ACE, but
there the singleton pointer is different, so
Hi,
> The advantage to using this library is that you don't need to use stuff
> like LoadLibrary to fetch functions that you want to use.
Great, thanks.
Johnny
--
Crystal Reports - New Free Runtime and 30 Day Trial
Che
Hi,
> > The cygwin people also use _image_base, see
> > http://www.cygwin.com/ml/cygwin-developers/2009-01/msg00014.html
>
> __image_base__ is a linker defined symbol. Since WinCE ARM doesn't
> prepend an extra underscore on C symbol names, you reference it
> from C as:
>
> extern char __image
r_objs=""
> + srv_mingw=yes
> + srv_mingwce=yes
> + ;;
> i[34567]86-*-mingw*)srv_regobj=reg-i386.o
> srv_tgtobj="win32-low.o win32-i386-low.o"
> srv_mingw=yes
doesn't include gdb (gdb isn't in our SVN any more, its regular
> releases are good enough for cegcc-arm).
>
> The gdb is in a separate file (11183360 bytes):
> http://danny.backx.info/download/cegcc/x86mingw32ce-gdb-linux.tar.gz
>
> gdbserver isn't in that yet, I still
Hi,
> That would require "a bit" of work to hook the binutils build system
> into src/mingw. I don't think that this would be a very good idea, this
> is too low level stuff.
>
> I've just committed a patch to SVN, can you review ?
Looks ok. I will do a svn update tomorrow morning and do a compl
Hi,
> I'm not too sure about this one.
I wasn't also sure about this ;-)
> You're proposing to change (in src/mingw/pseudo-reloc.c) :
> extern char __U(_image_base__);
>
> But in src/mingw/include/_mingw.h, it says :
> #ifdef UNDER_CE
> /* ARM Windows CE is not underscored. */
> # define __U(S
Hi,
After making the changes for image_base, global_ctor/dtor and profile.c the
compilation of cegcc for x86 finished with done. We have compiled dialog.c
(as listed on http://cegcc.sourceforge.net/docs/using.html) with the x86
compiler and have run it on our x86 device. The hello world dialog wit
Hi,
The file cegcc\src\profile\profile\profile.c uses errno but that code is
just disabled for ARM. I think it should check UNDER_CE because CE doesn't
have errno. Attached an updated file.
Johnny
/* profil.c -- win32 profil.c equivalent
Copyright 1998, 1999, 2000, 2001, 2002 Red Hat, Inc.
Hi,
Attached an updated file for cegcc\src\mingw. I added a mingw_ prefix to the
global methods. Now the libstdc++ does compile without problems. The problem
doesn't appear with ARM because ARM uses ELF and then the _do_global_dtors
and _do_global_ctors are not compiled as part of libgcc2.c
Johnn
Hi,
Seems this is an issue reported in the past to stdlibc++, see
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16371
Johnny
--
Stay on top of everything new and different, both inside and
around Java (TM) technology - r
a.exe
checking whether the C compiler works... yes
checking whether we are cross compiling... yes
checking for suffix of executables... .exe
Seems that some of the autoconf checks are not enabled for i386 for
libstdc++-v3
Johnny
> -Original Message-
> From: Johnny Willemsen [mai
Hi,
> The cygwin people also use _image_base, see
> http://www.cygwin.com/ml/cygwin-developers/2009-01/msg00014.html
With the following construct it doesn't link with ARM. Would it be possible
to have 2 pseudo-reloc.c files, one for ARM and one for x86, or have
ifdeffed code?
extern char _image_
1 - 100 of 111 matches
Mail list logo
