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
-
On Sat, 2009-05-16 at 08:44 +0200, Johnny Willemsen wrote:
> > 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 d
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
Geoffroy Couprie a écrit :
> Pedro Alves a écrit :
>> On Friday 15 May 2009 01:24:54, Geoffroy Couprie wrote:
>>
>>> Hello!
>>>
>>> Here is a small patch to allow cross-compiling of CeGCC. I run
>>> "build-mingw32ce.sh --host=i586-mingw32msvc" from Linux to build a
>>> CeGCC
>>> usable on Window
On Friday 15 May 2009 15:36:12, Geoffroy Couprie wrote:
> > Dunno. First, to be sure we're running the correct executables, use the
> > prefixed ones (arm-mingw32ce-ranlib|ar). What does arm-mingw32ce-objdump
> > -x say
> > on the object and on the archive?
> >
> >
> Yes, I'm using the prefi
Hmm. Oops :-(
Thanks for the fix.
Danny
On Fri, 2009-05-15 at 17:02 +0200, Pierre Ynard wrote:
> Index: trunk/cegcc/src/w32api/include/kfuncs.h
> ===
> --- trunk/cegcc/src/w32api/include/kfuncs.h (révision 1275)
> +++ tru
After a closer look at the commits... attached patch solves the problem:
Index: trunk/cegcc/src/w32api/include/kfuncs.h
===
--- trunk/cegcc/src/w32api/include/kfuncs.h (révision 1275)
+++ trunk/cegcc/src/w32api/include/kfuncs.h
On Fri, 2009-05-15 at 15:31 +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
> > src/gcc/libstdc++-v3/docs/html/18_s
Hello,
After updating my toolchain to the latest svn revision, my application
won't work properly anymore, it seems to hang at some point. I narrowed
it down to the changes in the w32api directory. Prior to revision 1229,
it works correctly. (Between revision 1229 and 1241, it won't build.)
After
On Friday 15 May 2009 01:24:54, Geoffroy Couprie wrote:
> Hello!
>
> Here is a small patch to allow cross-compiling of CeGCC. I run
> "build-mingw32ce.sh --host=i586-mingw32msvc" from Linux to build a CeGCC
> usable on Windows (I use it under MSYS).
Applied, thanks.
> gcc, g++, objdump, strings,
On Friday 15 May 2009 04:48:05, Danny Backx wrote:
> So you are using 3 platforms, where most of us are talking about 2 :
> - Linux = create a compiler that runs on MSYS
> - MSYS = use cegcc (create WinCE/ARM apps)
> - WinCE/ARM = use applications
>
> Right ?
>
> So what is preventing you from sk
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
> I always say it sucks to reply to myself but I keep doing it.
>
> These lines are from src/mingw/mingwex/pformat.c :
> #ifdef _WIN32
> /* TODO: make this unconditional in final release...
> * (see note at head of associated `#else' block.
> */
> #include "gdtoa.h"
>
> static
> char *__pformat_
On Thu, 14 May 2009 20:44:40 +0200, "Johnny Willemsen"
wrote:
> Hi,
>
> I just found that structured exception handling (__try, __except,
> __finally)
> is not supported with cegcc. Are there plans/ideas to add this?
>
> Johnny
Hi,
about seh there are plans to add support for it and I had pro
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
> src/gcc/libstdc++-v3/docs/html/18_suppor
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
src/gcc/libstdc++-v3/docs/html/18_support/howto.html
Its s
On Fri, 2009-05-15 at 11:02 +0200, Johnny Willemsen wrote:
> > 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 af
And when single-stepping this with gdb, the application terminates
(logging see below) when executing the throw.
Danny
pavilion: {10} rsh ipaq /temp/gdbserver : /temp/excepttest
Process /temp/excepttest created; pid = -1007952498
Listening on port
Remote debugging from host 172.1
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
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.
It never makes it into the catch part though - that statement never gets
executed. I tried both with a printf statement like you
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
22 matches
Mail list logo
