Development of CeGCC/MinGW32ce.

Danny Backx | 2 Feb 2009 23:08

I'm inclined to put this work (based on the current gcc from their svn)
in our repository.

Upgrading to 4.4.0 once it's out shouldn't be hard.

Does anyone have ideas (objections or hurrays) about that ?

	Danny

On Mon, 2009-02-02 at 22:32 +0100, Vincent R. wrote:
> On Mon, 02 Feb 2009 16:56:17 +0100, Danny Backx <danny.backx@...>
> wrote:
> > I'm not making any promises, as I said I am a bit short on time right
> > now.
> > 
> > But what are the things we want ?
> > - gcc 4.4.x -> is it stable enough yet ?
> > - binutils 2.19 ?
> > 
> > 	Danny
> > 
> Actually my trainee and I need to work on gcc trunk if we want to have a
> chance to submit patch
> one day about seh implementation. Things are moving fast and I think it's
> good to have someone 
> regularly working with gcc trunk. gcc-4.4 is pretty stable and will be
> release soon.
> Actually I have solved all my issues with mingw and now I am using a static
> crt(no more mingwxx.dll) 
> (like mingw-w64) but unfortunately I still have an issue when working with

(Continue reading)

headers

Vincent R. | 3 Feb 2009 14:42

Subject: Re: cegcc 4.4 failure :-(

Ok here is the patch.
But before to be able to use it, I think we should add a dummy
crtbegin/crtend into mingw
(that's what is done in mingw &  mingw-w64 project) and allow us to follow
their evolutions.

If Pedro is ok, you should add two empty files crtbegin.c and crtend.c in
mingw and modify
Makefile.in :

MINGW_OBJS = crtbegin.o crtend.o ...
...
crtbegin.o: crtbegin.c
crtend.o: crtend.c

I will test but normally it won't break existing code because
STARTFILE_SPEC is not mentioned in cegcc-4.1.0
and then it will allow us to follow 
i386/mingw32.h evolution(because actually cegcc is mainly a copy/paste from
i386 for mingw part).

Then if you try this patch, you will have problem during mingw compilation
:
arm-mingw32ce-gcc -Wl,--base-file=mingwthrd.base -B./ -mdll 
-Wl,--image-base,0x6FBC0000 mthr.o mthr_init.o -Lmingwex \
		-o mingwthrd_dummy.exe

//opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ld:
cannot find -lgcc
collect2: ld returned 1 exit status

(Continue reading)

headers

Danny Backx | 3 Feb 2009 20:28

Subject: Re: cegcc 4.4 failure :-(

This one message has answers to questions/remarks from several mails.

On Tue, 2009-02-03 at 14:42 +0100, Vincent R. wrote:
> I feel a bit alone so Pedro if could take some time to give your opinion it
> would be great.

That's why I really want to put this in a public spot. Others will work
on/with this stuff if you give them a chance. That's part of the
"release early and often" philosophy.

My suggestion would be to add an "experimental" directory to the cegcc
svn, and add several directory trees to it :
  experimental/src/gcc	-> gcc from svn, to become gcc-4.4.0
  experimental/src/binutils -> binutils-2.19
  experimental/src/mingw -> mingw-64 I guess
  experimental/src/build -> new build scripts

I would focus on getting arm-mingw32ce to work, not arm-cegcc .

In parallel, the current source tree can remain for a while.

On Tue, 2009-02-03 at 00:26 +0100, Vincent Torri wrote:
> 2) I've also read on the gcc main site that there is (will be) a
> support of plugins for gcc (finally, it stops being monolythic). Does
> it mean that the port of cegcc could use that plugin framework ?

It would depend on what the framework does. Too early to tell.

On Mon, 2009-02-02 at 23:48 +0100, Vincent R. wrote:
> On Mon, 02 Feb 2009 23:08:31 +0100, Danny Backx <danny.backx@...>

(Continue reading)

headers

Vincent R. | 3 Feb 2009 20:55

Subject: Re: cegcc 4.4 failure :-(

On Tue, 03 Feb 2009 20:28:50 +0100, Danny Backx <danny.backx@...>
wrote:
> This one message has answers to questions/remarks from several mails.
> 
> On Tue, 2009-02-03 at 14:42 +0100, Vincent R. wrote:
>> I feel a bit alone so Pedro if could take some time to give your opinion
>> it
>> would be great.
> 
> That's why I really want to put this in a public spot. Others will work
> on/with this stuff if you give them a chance. That's part of the
> "release early and often" philosophy.
> 
> My suggestion would be to add an "experimental" directory to the cegcc
> svn, and add several directory trees to it :
>   experimental/src/gcc	-> gcc from svn, to become gcc-4.4.0
>   experimental/src/binutils -> binutils-2.19
>   experimental/src/mingw -> mingw-64 I guess
>   experimental/src/build -> new build scripts
> 
> I would focus on getting arm-mingw32ce to work, not arm-cegcc .
> 
> In parallel, the current source tree can remain for a while.
> 
> On Tue, 2009-02-03 at 00:26 +0100, Vincent Torri wrote:
>> 2) I've also read on the gcc main site that there is (will be) a
>> support of plugins for gcc (finally, it stops being monolythic). Does
>> it mean that the port of cegcc could use that plugin framework ?
> 
> It would depend on what the framework does. Too early to tell.

(Continue reading)

headers

Pedro Alves | 8 Feb 2009 03:59

Subject: Re: cegcc 4.4 failure :-(

On Tuesday 03 February 2009 19:55:36, Vincent R. wrote:
> 2) I made a patch for mingw to use static crt, it will be consistent with
> future cegcc-4.4
> and with mingw-w64. Now I need people to test it and if it works fine we
> could apply it to
> current svn.

Sorry, but I don't like this patch --- it's a hack.  In fact, if you browse
cegcc's history, you'll see that we used to do more of these dummy files, but
I really prefer to avoid them.

The issue you're tripping on, is that:

 - The crtbegin.o and crtend.o files are part of libgcc.
 - building mingw invokes the compiler/linker to build a fully
   linked executable, hence it needs crtbegin.o and crtend.o.
 - after gcc 4.1, the way that libgcc is built was changed.  Invoking
   "make all-gcc" doesn't build it anymore.  End result, the build script
   isn't building the target libgcc on the bootstrap gcc step.

To solve this, we need to build the target libgcc before building
mingw.  But, there's a cyclic dependency here.  To build the target
libgcc, we need mingw and w32api's headers, but we don't install them
until we've built mingw...

So, to fix this, I've added a new Makefile rule that just
installs mingw's headers (already checked in), and tweaked the
build script like this (notice the components build order change):

Index: build-mingw32ce.sh

(Continue reading)

headers

Vincent R. | 13 Feb 2009 19:44

Subject: Re: cegcc 4.4 failure :-(

Hi,

I have updated the patch to generate a cegcc based on gcc-trunk.
There have been some changes in the way to generate shared libgcc so I have
updated
config.gcc and t-wince-pe
(http://www.nabble.com/-PATCH--Fix-PR38904:-mis-named-libgcc-DLL-on-cygwin.-td21609057.html):

config.gcc:

...
+	if test x$sjlj = x0; then
+		tmake_eh_file="i386/t-dw2-eh"
+	else
+		tmake_eh_file="i386/t-sjlj-eh"
+	fi
+ 	tmake_file="${tmake_file} ${tmake_eh_file} arm/t-arm arm/t-wince-pe
arm/t-cygming arm/t-mingw32"
...

Unfortunately code generated with cegcc-4.4 seems to be invalid and is not
loaded anymore, even on WM5.
For now don't know why.
To be more precise , DLL(testDll.dll) generated with cegcc-4.4 can be
loaded by an application(testDllexe.exe) 
compiled with cegcc-4.1 but the same application compiled with cegcc-4.4
cannot load it.
Amongst differences on testDllexe.exe between 4.1.0 and 4.4.0, there are 

1) alignement

(Continue reading)

headers

Pedro Alves | 16 Feb 2009 16:49

Subject: Re: cegcc 4.4 failure :-(

Uurgh, I totally missed this message before posting the other one...

I've posted an updated patch against trunk at cegcc-devel <at> .  It should
fix the alignment issue.  ".align FOO" on ARM coff works like on elf, that
is, FOO is power 2 aligment...  I've also fixed a couple of __dllimport
issues on ARM, so I wouldn't be suprised if the malloc issue is gone,
but I haven't really spend more than 10 seconds looking at your report
yet.  (Sorry, I'm swamped at the moment).

On Friday 13 February 2009 18:44:14, Vincent R. wrote:
> Hi,
> 
> I have updated the patch to generate a cegcc based on gcc-trunk.
> There have been some changes in the way to generate shared libgcc so I have
> updated
> config.gcc and t-wince-pe
> (http://www.nabble.com/-PATCH--Fix-PR38904:-mis-named-libgcc-DLL-on-cygwin.-td21609057.html):
> 
> config.gcc:
> 
> ...
> +	if test x$sjlj = x0; then
> +		tmake_eh_file="i386/t-dw2-eh"
> +	else
> +		tmake_eh_file="i386/t-sjlj-eh"
> +	fi
> + 	tmake_file="${tmake_file} ${tmake_eh_file} arm/t-arm arm/t-wince-pe
> arm/t-cygming arm/t-mingw32"
> ...
>

(Continue reading)

headers

Vincent R. | 16 Feb 2009 18:47

Subject: Re: cegcc 4.4 failure :-(

When I try your patch from cegcc svn I have the following message :

make AS="arm-mingw32ce-as" CC="gcc" CFLAGS="-O2 -g  " CXXFLAGS=" <at> CXXFLAGS <at>  
" CPPFLAGS="  " AR="arm-mingw32ce-ar" RANLIB="arm-mingw32ce-ranlib"
LD="arm-mingw32ce-ld" DLLTOOL="arm-mingw32ce-dlltool"
exec_prefix="/opt/mingw32ce-4.4.0" bindir="/opt/mingw32ce-4.4.0/bin"
libdir="/opt/mingw32ce-4.4.0/lib"
tooldir="/opt/mingw32ce-4.4.0/arm-mingw32ce"
datadir="/opt/mingw32ce-4.4.0/share" infodir="/opt/mingw32ce-4.4.0/info"
includedir="/opt/mingw32ce-4.4.0/include" inst_bindir="" inst_includedir=""
inst_libdir="" inst_docdir="" prefix="/opt/mingw32ce-4.4.0"
build="i686-pc-linux-gnu" build_alias="" host="arm-unknown-mingw32ce"
host_alias="arm-mingw32ce" target="arm-unknown-mingw32ce" target_alias=""
TAR="tar" TARFLAGS="z" TARFILEEXT=".tar.gz" WINDRES="arm-mingw32ce-windres"
-C libce
make[1]: entrant dans le répertoire «
/home/vincent/projects/cegcc/src/scripts/build-mingw32ce-4.4.0/w32api/libce
»
gcc -c -O2 -g   -I/home/vincent/projects/cegcc/src/w32api/libce/../include 
-o largeint.o /home/vincent/projects/cegcc/src/w32api/libce/largeint.c
In file included from /usr/include/sys/select.h:46,
                 from /usr/include/sys/types.h:220,
                 from /usr/include/stdlib.h:320,
                 from
/home/vincent/projects/cegcc/src/w32api/libce/../include/objbase.h:12,
                 from
/home/vincent/projects/cegcc/src/w32api/libce/../include/ole2.h:9,
                 from
/home/vincent/projects/cegcc/src/w32api/libce/../include/windows.h:116,
                 from

(Continue reading)

headers

Pedro Alves | 16 Feb 2009 19:21

Subject: Re: cegcc 4.4 failure :-(

On Monday 16 February 2009 17:47:09, Vincent R. wrote:
> When I try your patch from cegcc svn I have the following message :
> 
> make AS="arm-mingw32ce-as" CC="gcc" CFLAGS="-O2 -g  " CXXFLAGS=" <at> CXXFLAGS <at>  

                                 ^^^

Wrong gcc here.  Hmmm, did I forget that w32api does need a
compiler to build?  Maybe I had the 4.1 based one in PATH, and missed
this issue.

> " CPPFLAGS="  " AR="arm-mingw32ce-ar" RANLIB="arm-mingw32ce-ranlib"

> gcc -c -O2 -g   -I/home/vincent/projects/cegcc/src/w32api/libce/../include 
  ^^^

This is wrong compiler being used...

> Don't understand where does it come from ...
> It was working fine before, so maybe a distro update or something like
> that.
> The problem seems to be related to winsock.h and system includes.
> 

> Damn it, I am doomed



Some more tweaking to the bootstap sequence is in order.

(Continue reading)

headers

Danny Backx | 16 Feb 2009 21:56

Subject: Re: cegcc 4.4 failure :-(

I'm getting quite far. No time today though to figure out what's wrong.
This is, I believe, with just Pedro's stuff, based on gcc-trunk as of a
couple of hours ago.

	Danny

gmake[3]: Entering directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3'
Making all in include
gmake[4]: Entering directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3/include'
gmake[4]: *** No rule to make
target
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-trunk/libstdc++-v3/config/os/mingw32/runtimeopts.h',
needed by `stamp-host'.  Stop.
gmake[4]: Leaving directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3/include'
gmake[3]: *** [all-recursive] Error 1
gmake[3]: Leaving directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3'
gmake[2]: *** [all] Error 2
gmake[2]: Leaving directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3'
gmake[1]: *** [all-target-libstdc++-v3] Error 2
gmake[1]: Leaving directory
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc'
gmake: *** [all] Error 2
dannypc: {24} 

On Mon, 2009-02-16 at 18:21 +0000, Pedro Alves wrote:

(Continue reading)

headers

Vincent R. | 16 Feb 2009 22:48

Subject: Re: cegcc 4.4 failure :-(

On Mon, 16 Feb 2009 21:56:06 +0100, Danny Backx <danny.backx@...>
wrote:
> I'm getting quite far. No time today though to figure out what's wrong.
> This is, I believe, with just Pedro's stuff, based on gcc-trunk as of a
> couple of hours ago.
> 
> 	Danny
> 
> gmake[3]: Entering directory
>
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3'
> Making all in include
> gmake[4]: Entering directory
>
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3/include'
> gmake[4]: *** No rule to make target
>
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/gcc-trunk/libstdc++-v3/config/os/mingw32/runtimeopts.h',
> needed by `stamp-host'.  Stop.
> gmake[4]: Leaving directory
>
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3/include'
> gmake[3]: *** [all-recursive] Error 1
> gmake[3]: Leaving directory
>
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3'
> gmake[2]: *** [all] Error 2
> gmake[2]: Leaving directory
>
`/home/danny/src/cegcc/svn.sf.net/cegcc/trunk/cegcc/src/build-4.4/gcc/arm-mingw32ce/libstdc++-v3'

(Continue reading)

headers

Pedro Alves | 17 Feb 2009 02:06

Subject: Re: cegcc 4.4 failure :-(

On Monday 16 February 2009 21:48:20, Vincent R. wrote:
> actually there are some issue with Pedro's patch, I don't know why but
> libstdc++-v3/configure.host
> is not patched :

Errrr, because I changed it?

> 
>  mingw32ce*)
>     os_include_dir="os/mingw32"  !!!!!! Should be os/mingw32ce
>     error_constants_dir="os/mingw32"  !!!!!! Should be os/mingw32ce

I got tired of updating the files in os/mingw32ce from
their os/mingw32 counterparts, and patches the ones in on/mingw32
for mingw32ce directly.

I need to take a moment to look at what went wrong with Danny's build and
fix the bootstrap sequence properly.  ...

> I will post a patch for people interested.

Could you please at least give me a chance to?  

--

-- 
Pedro Alves

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation

(Continue reading)

headers

Vincent R. | 16 Feb 2009 23:55

Subject: Re: cegcc 4.4 failure :-(

Pedro,

I have also noticed that you have hardcoded exception mode in t-wince-pe :

...
# This should go somewhere else.
# We are using SjLj EH.
EH_MODEL = sjlj

Wouldn't be possible to do what I suggest in a previous email and use the
same logic as mingw ?

> config.gcc:
> 
> ...
> +     if test x$sjlj = x0; then
> +             tmake_eh_file="i386/t-dw2-eh"
> +     else
> +             tmake_eh_file="i386/t-sjlj-eh"
> +     fi
> +     tmake_file="${tmake_file} ${tmake_eh_file} arm/t-arm arm/t-wince-pe
> arm/t-cygming arm/t-mingw32"
> ...
> 

in mingw32.g/wince-pe.h/wince-cegcc.h, you should replace LIBGCC_SPEC by
REAL_LIBGCC_SPEC
because it seems to be the new prefered define.

------------------------------------------------------------------------------

(Continue reading)

headers

Pedro Alves | 17 Feb 2009 02:22

Subject: Re: cegcc 4.4 failure :-(

On Monday 16 February 2009 22:55:27, Vincent R. wrote:
> I have also noticed that you have hardcoded exception mode in t-wince-pe :
> 
> ...
> # This should go somewhere else.
> # We are using SjLj EH.
> EH_MODEL = sjlj
> 
> 
> Wouldn't be possible to do what I suggest in a previous email and use the
> same logic as mingw ?
> 

Well, yes, we could, but, I don't think that anything but sjlj
will work currently.  Hey, wouldn't it be nice if that was:

> EH_MODEL = seh



--

-- 
Pedro Alves

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

(Continue reading)

headers

Vincent R. | 17 Feb 2009 13:11

Subject: Re: cegcc 4.4 failure :-(

On Tue, 17 Feb 2009 01:22:37 +0000, Pedro Alves <alves.ped@...>
wrote:
> On Monday 16 February 2009 22:55:27, Vincent R. wrote:
>> I have also noticed that you have hardcoded exception mode in t-wince-pe
>> :
>> 
>> ...
>> # This should go somewhere else.
>> # We are using SjLj EH.
>> EH_MODEL = sjlj
>> 
>> 
>> Wouldn't be possible to do what I suggest in a previous email and use
the
>> same logic as mingw ?
>> 
> 
> Well, yes, we could, but, I don't think that anything but sjlj
> will work currently.  Hey, wouldn't it be nice if that was:
> 
>> EH_MODEL = seh
> 
> 
Florent is working on it or should I say is supposed to do so  
I got no news from him, I think he might be go skiing without telling me.
Last time I talked to him, he did some parsing stuff and was emitting some
barrier
buth his problem was gcc removed his instructions during optimizations.

When testing cegcc-4.4 when compiling a lib from EFL

(Continue reading)

headers

Pedro Alves | 18 Feb 2009 16:12

Subject: Re: cegcc 4.4 failure :-(

On Tuesday 17 February 2009 12:11:47, Vincent R. wrote:

> When testing cegcc-4.4 when compiling a lib from EFL
> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -Wl,-s
> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
> evil_test_environment.o evil_test_gettimeofday.o evil_test_link.o
> evil_test_memcpy.o evil_test_mkstemp.o evil_test_realpath.o
> memcpy_glibc_arm.o  -L/home/vincent/local/wince/lib
> -L/home/vincent/toolchains/mingw32ce-4.4.0/lib
> ../../src/lib/.libs/libevil.a ../../src/lib/dlfcn/.libs/libdl.a
> /home/vincent/projects/efl/PROTO/evil/src/lib/.libs/libevil.a -lws2
> evil_suite.o:evil_suite.c:(.text+0x20): undefined reference to
> `__floatdidf'
> evil_suite.o:evil_suite.c:(.text+0x30): undefined reference to
> `__floatdidf'
> 
> Any idea why ?
> Please note that from Vincent Torri explanation, libtool error message
> prepend a _ so actually linker cannot find
> _floatdidf function.

I'll take a look.  Either that function isn't being linked in to libgcc,
or, it's being exported with the wrong underscores, maybe (CE is does not
get an extra underscore in C linkage function names, contrary to desktop Windows,
or to most other ARM targets).  Do you have a small testcase that shows
the failure?

> I may have an explanation, it seems libstdc++ shared lib is not built, I
> will check in this direction.
>

(Continue reading)

headers

Vincent R. | 19 Feb 2009 12:05

Subject: Re: cegcc 4.4 failure :-(

On Wed, 18 Feb 2009 15:12:27 +0000, Pedro Alves <alves.ped@...>
wrote:
> On Tuesday 17 February 2009 12:11:47, Vincent R. wrote:
> 
>> When testing cegcc-4.4 when compiling a lib from EFL
>> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import
>> -Wl,-s
>> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
>> evil_test_environment.o evil_test_gettimeofday.o evil_test_link.o
>> evil_test_memcpy.o evil_test_mkstemp.o evil_test_realpath.o
>> memcpy_glibc_arm.o  -L/home/vincent/local/wince/lib
>> -L/home/vincent/toolchains/mingw32ce-4.4.0/lib
>> ../../src/lib/.libs/libevil.a ../../src/lib/dlfcn/.libs/libdl.a
>> /home/vincent/projects/efl/PROTO/evil/src/lib/.libs/libevil.a -lws2
>> evil_suite.o:evil_suite.c:(.text+0x20): undefined reference to
>> `__floatdidf'
>> evil_suite.o:evil_suite.c:(.text+0x30): undefined reference to
>> `__floatdidf'
>> 
>> Any idea why ?
>> Please note that from Vincent Torri explanation, libtool error message
>> prepend a _ so actually linker cannot find
>> _floatdidf function.
> 
> I'll take a look.  Either that function isn't being linked in to libgcc,
> or, it's being exported with the wrong underscores, maybe (CE is does not
> get an extra underscore in C linkage function names, contrary to desktop
> Windows,
> or to most other ARM targets).  Do you have a small testcase that shows
> the failure?

(Continue reading)

headers

Vincent R. | 17 Feb 2009 13:59

Subject: Re: cegcc 4.4 failure :-(

On Tue, 17 Feb 2009 13:11:47 +0100, "Vincent R." <forumer@...>
wrote:
> On Tue, 17 Feb 2009 01:22:37 +0000, Pedro Alves <alves.ped@...>
> wrote:
>> On Monday 16 February 2009 22:55:27, Vincent R. wrote:
>>> I have also noticed that you have hardcoded exception mode in
t-wince-pe
>>> :
>>> 
>>> ...
>>> # This should go somewhere else.
>>> # We are using SjLj EH.
>>> EH_MODEL = sjlj
>>> 
>>> 
>>> Wouldn't be possible to do what I suggest in a previous email and use
> the
>>> same logic as mingw ?
>>> 
>> 
>> Well, yes, we could, but, I don't think that anything but sjlj
>> will work currently.  Hey, wouldn't it be nice if that was:
>> 
>>> EH_MODEL = seh
>> 
>> 
> Florent is working on it or should I say is supposed to do so  
> I got no news from him, I think he might be go skiing without telling me.
> Last time I talked to him, he did some parsing stuff and was emitting
some

(Continue reading)

headers

Vincent Torri | 17 Feb 2009 13:15

Subject: Re: cegcc 4.4 failure :-(


On Tue, 17 Feb 2009, Vincent R. wrote:

> When testing cegcc-4.4 when compiling a lib from EFL
> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import -Wl,-s
> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
> evil_test_environment.o evil_test_gettimeofday.o evil_test_link.o
> evil_test_memcpy.o evil_test_mkstemp.o evil_test_realpath.o
> memcpy_glibc_arm.o  -L/home/vincent/local/wince/lib
> -L/home/vincent/toolchains/mingw32ce-4.4.0/lib
> ../../src/lib/.libs/libevil.a ../../src/lib/dlfcn/.libs/libdl.a
> /home/vincent/projects/efl/PROTO/evil/src/lib/.libs/libevil.a -lws2
> evil_suite.o:evil_suite.c:(.text+0x20): undefined reference to
> `__floatdidf'
> evil_suite.o:evil_suite.c:(.text+0x30): undefined reference to
> `__floatdidf'
>
> Any idea why ?
> Please note that from Vincent Torri explanation, libtool error message
> prepend a _ so actually linker cannot find
> _floatdidf function.

it's a message from the linker, not libtool :)

Vincent Torri

PS: the Vincent people will rule the world

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA

(Continue reading)

headers

Vincent R. | 17 Feb 2009 13:30

Subject: Re: cegcc 4.4 failure :-(

On Tue, 17 Feb 2009 13:15:29 +0100 (CET), Vincent Torri
<vtorri@...> wrote:
> On Tue, 17 Feb 2009, Vincent R. wrote:
> 
>> When testing cegcc-4.4 when compiling a lib from EFL
>> libtool: link: arm-mingw32ce-gcc -O3 -pipe -Wl,--enable-auto-import
>> -Wl,-s
>> -o .libs/evil_suite.exe evil_suite.o evil_test_dlfcn.o
>> evil_test_environment.o evil_test_gettimeofday.o evil_test_link.o
>> evil_test_memcpy.o evil_test_mkstemp.o evil_test_realpath.o
>> memcpy_glibc_arm.o  -L/home/vincent/local/wince/lib
>> -L/home/vincent/toolchains/mingw32ce-4.4.0/lib
>> ../../src/lib/.libs/libevil.a ../../src/lib/dlfcn/.libs/libdl.a
>> /home/vincent/projects/efl/PROTO/evil/src/lib/.libs/libevil.a -lws2
>> evil_suite.o:evil_suite.c:(.text+0x20): undefined reference to
>> `__floatdidf'
>> evil_suite.o:evil_suite.c:(.text+0x30): undefined reference to
>> `__floatdidf'
>>
>> Any idea why ?
>> Please note that from Vincent Torri explanation, libtool error message
>> prepend a _ so actually linker cannot find
>> _floatdidf function.
> 
> it's a message from the linker, not libtool :)

Hum your are right sorry, I wanted to say from the linker 

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA

(Continue reading)

headers

Pedro Alves | 17 Feb 2009 02:22

Subject: Re: cegcc 4.4 failure :-(

A Monday 16 February 2009 22:55:27, Vincent R. escreveu:
> in mingw32.g/wince-pe.h/wince-cegcc.h, you should replace LIBGCC_SPEC by
> REAL_LIBGCC_SPEC
> because it seems to be the new prefered define.

Thanks, I'll take a look at that.

--

-- 
Pedro Alves

------------------------------------------------------------------------------
Open Source Business Conference (OSBC), March 24-25, 2009, San Francisco, CA
-OSBC tackles the biggest issue in open source: Open Sourcing the Enterprise
-Strategies to boost innovation and cut costs with open source participation
-Receive a $600 discount off the registration fee with the source code: SFAD
http://p.sf.net/sfu/XcvMzF8H

headers

Vincent R. | 4 Feb 2009 19:55

Subject: Re: cegcc 4.4 failure :-(

Hi,

Pedro, Danny,

This is my last contribution to cegcc project, it should allow you to
generate a cross-compiler
using the upcoming gcc-4.4. You will find instructions in the
HOWTO-cegcc-4.4.txt.
Unfortunately, I don't think it's a good thing to have a separate project
from gcc because
it add a lot of work to be able to follow evolutions and that's why cegcc
is still using 4.1, mingw and newlib
with  2 or 3 years old.
Of course we could now release a cegcc-4.4 but it would be a nonsense to do
it without updating also
mingw and I prefer to contribute directly to mingw-w64 instead of keeping a
local copy here.

That's why I am begging you to report cegcc patches into binutils/gcc so
that you allow other people to contribute
more efficiently to this platform.

Regards

Vincent R.

Attachment (patches-cegcc-4.4.tar.gz): application/x-gzip, 37 KiB

------------------------------------------------------------------------------

(Continue reading)

headers

Danny Backx | 4 Feb 2009 21:55

Subject: Re: cegcc 4.4 failure :-(

We have the same goal.

But if nobody assembles the bits and pieces and turns them into
something that's ready to use, then acceptance and use will be lower
than they could be.

In the past, a lot of effort has gone into getting stuff to work. The
time this took has made us lag behind gcc/binutils/gdb/mingw. We must
not do this again.

Pedro has already done the right thing for gdb. I've gotten one fix into
binutils.

My push recently was exactly meant to do what you want : for us to use
something more modern so we can focus on fixing problems upstream.

We had a harder time doing that in the past. I think we lacked
experience at that time. Maybe also stability.

Anyway : I've just compiled binutils 2.19. It took three trivial
configuration file changes to get a full compile. I'll try to get them
submitted.

I've used your script for that, note that it fails on the "cp -r"
commands because read-only files (in .svn directories) can only be
written once. Also the "die" command isn't available.

The bootstrap gcc build failed because gcc/gcc/config/arm/pe-stubs.c
wasn't present. Copied it from the other tree. After that, the bootstrap
build succeeds.

(Continue reading)

headers

Pedro Alves | 4 Feb 2009 23:16

Subject: Re: cegcc 4.4 failure :-(

On Wednesday 04 February 2009 20:55:28, Danny Backx wrote:
> We have the same goal.
> 

> But if nobody assembles the bits and pieces and turns them into
> something that's ready to use, then acceptance and use will be lower
> than they could be.

True.

> 
> In the past, a lot of effort has gone into getting stuff to work. The
> time this took has made us lag behind gcc/binutils/gdb/mingw. We must
> not do this again.

It's very simple to update binutils to a more recent version.  But, there
simply isn't much there that we'd benefic from.  Of interest, I can
only think of the recent addition of a new version of pseudo relocs.

Updating mingw isn't so simple as binutils, as we do have many
local changes, but it's indeed doable.  I think I'll go update
those.

> 
> Pedro has already done the right thing for gdb. I've gotten one fix into
> binutils.
> 
> My push recently was exactly meant to do what you want : for us to use
> something more modern so we can focus on fixing problems upstream.
>

(Continue reading)

headers

Danny Backx | 5 Feb 2009 23:16

Subject: Re: cegcc 4.4 failure :-(

On Wed, 2009-02-04 at 22:16 +0000, Pedro Alves wrote:
> On Wednesday 04 February 2009 20:55:28, Danny Backx wrote:
> > The next thing to fail is mingw. I'm not sure whether I want to invest
> > in that given your remarks on mingw-w64. Is your experience that it can
> > replace the src/mingw in the cegcc tree ?
> 
> I'm sorry, I can only read this with a sense that there's confusion
> on what are our local changes, and the relation between these trees.
> 
> I'm hoping you don't actually believe that you only have to replace
> one component for the other and things will magically work.

Unfortunately, the only way to do that is to buy Visual C++ or whatever
it's called nowadays.

I was wondering : if we can benefit from upgrading our mingw
installation (especially the includes, I think), which would be the
better source. Obviously all the CE specific stuff that we've been
adding needs to be integrated.

	Danny
--

-- 
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com

(Continue reading)

headers

Pedro Alves | 4 Feb 2009 20:22

Subject: Re: cegcc 4.4 failure :-(

On Wednesday 04 February 2009 18:55:32, Vincent R. wrote:

> This is my last contribution to cegcc project, it should allow you to
> generate a cross-compiler
> using the upcoming gcc-4.4. You will find instructions in the
> HOWTO-cegcc-4.4.txt.

Thanks, I'll take a look.

> Unfortunately, I don't think it's a good thing to have a separate project
> from gcc because
> it add a lot of work to be able to follow evolutions and that's why cegcc
> is still using 4.1, mingw and newlib
> with  2 or 3 years old.

Noone ever said it was easy.  But, its a large amount of work to get this in,
and, gcc is in stage 4 --- we have to wait for stage 1 to start thinking
of contributing mingw32ce there.  I think that people here believe that a
straight forward port is a silver bullet to solve bugs we know about
in 4.1 ...  Well, it's not.

> Of course we could now release a cegcc-4.4 but it would be a nonsense to do
> it without updating also
> mingw and I prefer to contribute directly to mingw-w64 instead of keeping a
> local copy here.

Honestly, I don't understand what's the benefit of mingw-w64 compared to
our tree, or even, the official mingw.  Can you explain?
It's not like we can't update our local copy from upstream mingw.

(Continue reading)

headers

Vincent Torri | 3 Feb 2009 00:26

Subject: Re: cegcc 4.4 failure :-(

On Mon, 2 Feb 2009, Danny Backx wrote:

> I'm inclined to put this work (based on the current gcc from their svn)
> in our repository.
>
> Upgrading to 4.4.0 once it's out shouldn't be hard.
>
> Does anyone have ideas (objections or hurrays) about that ?

going to 4.4.0 would be nice. Just some remarks:

1) I've answered on the mailing list of mingw about the status of gcc 
4.3.0 but i've not received any answer from the dev. But a guy, who wanted 
also such information, mentioned a post where the mingw gcc maintainer 
filed a bug in gcc bugzilla. Do you know if it would be the thing to do, 
that is patching directly gcc instead of having your own tree ?

2) I've also read on the gcc main site that there is (will be) a support 
of plugins for gcc (finally, it stops being monolythic). Does it mean that 
the port of cegcc could use that plugin framework ?

Vincent Torri

------------------------------------------------------------------------------
Create and Deploy Rich Internet Apps outside the browser with Adobe(R)AIR(TM)
software. With Adobe AIR, Ajax developers can use existing skills and code to
build responsive, highly engaging applications that combine the power of local
resources and data with the reach of the web. Download the Adobe AIR SDK and
Ajax docs to start building applications today-http://p.sf.net/sfu/adobe-com

(Continue reading)

headers

Vincent R. | 3 Feb 2009 09:41

Subject: Re: cegcc 4.4 failure :-(

Hi Vincent,

On Tue, 3 Feb 2009 00:26:55 +0100 (CET), Vincent Torri
<vtorri@...>
wrote:
> On Mon, 2 Feb 2009, Danny Backx wrote:
> 
>> I'm inclined to put this work (based on the current gcc from their svn)
>> in our repository.
>>
>> Upgrading to 4.4.0 once it's out shouldn't be hard.
>>
>> Does anyone have ideas (objections or hurrays) about that ?
> 
> going to 4.4.0 would be nice. Just some remarks:
> 
> 1) I've answered on the mailing list of mingw about the status of gcc 
> 4.3.0 but i've not received any answer from the dev. But a guy, who
wanted 
> also such information, mentioned a post where the mingw gcc maintainer 
> filed a bug in gcc bugzilla. Do you know if it would be the thing to do, 
> that is patching directly gcc instead of having your own tree ?
>
I have already generated a mingw from gcc trunk using mingw-w64 repository
and 
you could find attached the script I use.

> 2) I've also read on the gcc main site that there is (will be) a support 
> of plugins for gcc (finally, it stops being monolythic). Does it mean
that

(Continue reading)

headers

Vincent R. | 3 Feb 2009 11:49

Subject: Re: cegcc 4.4 failure :-(

I am progressing, I have found why Dll addresses were not good, actually I
started
from i386/mingw32.h and forget to remove the --enable-auto-image-base.
It seems this option is not compatible with our arm architecture ...
I will post a new patch very soon.

On Tue, 03 Feb 2009 09:41:04 +0100, "Vincent R." <forumer@...>
wrote:
> Hi Vincent,
> 
> On Tue, 3 Feb 2009 00:26:55 +0100 (CET), Vincent Torri
> <vtorri@...>
> wrote:
>> On Mon, 2 Feb 2009, Danny Backx wrote:
>> 
>>> I'm inclined to put this work (based on the current gcc from their svn)
>>> in our repository.
>>>
>>> Upgrading to 4.4.0 once it's out shouldn't be hard.
>>>
>>> Does anyone have ideas (objections or hurrays) about that ?
>> 
>> going to 4.4.0 would be nice. Just some remarks:
>> 
>> 1) I've answered on the mailing list of mingw about the status of gcc 
>> 4.3.0 but i've not received any answer from the dev. But a guy, who
> wanted 
>> also such information, mentioned a post where the mingw gcc maintainer 
>> filed a bug in gcc bugzilla. Do you know if it would be the thing to do,

(Continue reading)