On Tue, 03 Feb 2009 20:28:50 +0100, Danny Backx <danny.ba...@scarlet.be>
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.
>
> On Mon, 2009-02-02 at 23:48 +0100, Vincent R. wrote:
>> On Mon, 02 Feb 2009 23:08:31 +0100, Danny Backx <danny.ba...@scarlet.be>
>> wrote:
>> > I'm inclined to put this work (based on the current gcc from their
svn)
>> > in our repository.
>> Maybe you should wait some time we find a fix and with more testing ;-)
>
> Actually I've asked this several times, with a couple of months between
> the questions. The answer was always to wait for ... .
>
> The current implementation of cegcc has been very successful. It's
> getting very old though. We're spending time adding/fixing stuff which
> is probably already done in the original code. So we're duplicating
> efforts instead of helping to improve the original products.
>
> Sometimes you have to stop doing that and move on.
>
> Once more : is it the right time to start an experimental branch ?
>
> Danny
I completely agree with you Danny, that's why I am thinking to work with
mingw-w64 team
and add support for libce in addition to mingw-32 and mingw-64 in their
repository.
But for now here is what we can do :
1) First remove gcc-4.3 from trunk, it's useless
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.
3) In a few weeks I propose to update binutils because actually there is a
bug in current binutils
and I am waiting for a patch to fix it. (See "Stack traces and sections in
PE/COFF" in binutils ML).
Then I agree for creating a branch where we could follow gcc trunk, but it
would be easier if
everything could be integrated officially to gcc.
Index: mingw/Makefile.in
===================================================================
--- mingw/Makefile.in (révision 1210)
+++ mingw/Makefile.in (copie de travail)
@@ -177,7 +177,7 @@
TARFLAGS="$(TARFLAGS)" \
TARFILEEXT="$(TARFILEEXT)"
-CRT0S = CRT_noglob.o crtmt.o crtst.o
+CRT0S = crtbegin.o crtend.o CRT_noglob.o crtmt.o crtst.o
ifneq (,$(findstring mingw32ce,$(host_alias)))
CRT0S += crt3.o dllcrt3.o
else
@@ -258,12 +258,16 @@
$(AR) rc $@ _libm_dummy.o
$(RANLIB) $@
-libmingwthrd.a: crtmt.o mingwthrd.def
- $(DLLTOOL) $(DLLTOOL_FLAGS) --dllname $(THREAD_DLL_NAME) \
- --def mingwthrd.def --output-lib $@
- $(AR) $(ARFLAGS) $@ crtmt.o
+libmingwthrd.a: dummy_mingwthrd.o
+ $(AR) rc $@ dummy_mingwthrd.o
$(RANLIB) $@
+#libmingwthrd.a: crtmt.o mingwthrd.def
+# $(DLLTOOL) $(DLLTOOL_FLAGS) --dllname $(THREAD_DLL_NAME) \
+# --def mingwthrd.def --output-lib $@
+# $(AR) $(ARFLAGS) $@ crtmt.o
+# $(RANLIB) $@
+
# Using dllwrap would be so much easier, but Cygnus top-level configure
# Makefile.in etc don't pass the right variables yet.
xx_$(THREAD_DLL_NAME) xx_mingwthrd.def: mthr.o mthr_init.o
@@ -514,6 +518,8 @@
crt1.o: crt1.c init.c
crt2.o: crt1.c init.c
crt3.o: crt3.c
+crtbegin.o: crtbegin.c
+crtend.o: crtend.c
crtmt.o: crtmt.c
crtst.o: crtst.c
ctype_old.o: ctype_old.c
@@ -521,6 +527,7 @@
dllcrt2.o: dllcrt1.c
dllcrt3.o: dllcrt1.c
dllmain.o: dllmain.c
+dummy_mingwthrd.o: dummy_mingwthrd.c
main.o: main.c
winmain_ce.o: winmain_ce.c
oldnames.o: oldnames.c
Index: mingw/dummy_mingwthrd.c
===================================================================
Index: mingw/crtend.c
===================================================================
--- mingw/crtend.c (révision 0)
+++ mingw/crtend.c (révision 0)
@@ -0,0 +1,6 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the w64 mingw-runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
+
Index: mingw/crtbegin.c
===================================================================
--- mingw/crtbegin.c (révision 0)
+++ mingw/crtbegin.c (révision 0)
@@ -0,0 +1,6 @@
+/**
+ * This file has no copyright assigned and is placed in the Public Domain.
+ * This file is part of the w64 mingw-runtime package.
+ * No warranty is given; refer to the file DISCLAIMER within this package.
+ */
+
------------------------------------------------------------------------------
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
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
