On Sun, 01 Feb 2009 20:12:40 +0100, Danny Backx <danny.ba...@scarlet.be>
wrote:
> That's not a real problem, it's just configuration :-)
>
> You'll need to learn about the gcc configuration. All that kind of stuff
> is fully configurable in the gcc sources.
>
> There's a (complicated) set of sources and include files that are vital
> for you to understand if you're working on this. Look in
> (CEGCC)/src/gcc/gcc/config/arm and inspect e.g. mingw32.h .
>
> You'll find that the STARTFILE_SPEC contains magic to use
> dllcrt3%O%s
> or crt3%O%s
> or gcrt3%O%s
> depending on the command line options (e.g. -shared) passed to the
> compiler.
>
> Macros such as STARTFILE_SPEC can be overriden in some of these files,
> you need to figure out which set is being included. That is in
> (CEGCC)/src/gcc/gcc/config.gcc . Look at the arm*-*-mingw32ce* target to
> see the sequence of include files in tm_file .
>
> Danny
>
I already tried so many things that now I don't think I will solve it by
myself...
I will wait for you or for Pedro ;-)
> On Sun, 2009-02-01 at 19:59 +0100, Vincent R. wrote:
>> On Sun, 01 Feb 2009 13:59:29 +0100, Danny Backx <danny.ba...@scarlet.be>
>> wrote:
>> > On Fri, 2009-01-30 at 14:43 +0100, Vincent R. wrote:
>> >> I also tried to generate a cegcc-4.4.0 but unfortuantely it DOESN'T
>> >> WORK
>> >> because it seems
>> >> there is an issue with crtstuff. Indeed binaries starts at wrong
>> >> virtual
>> >> address !!!
>> >
>> > I've not tried your patch yet (other urgent things to do this week,
>> > sorry). The remark above caught my attention though.
>> >
>> Actually now I am studying mingw and mingw-64 and I managed to generate
>> cross-compilers.
>> I wanted to see differences with mingw32ce.
>> Actually I will post another patch because I made some modifications and
>> understood some new things.
>>
>> > What exactly is the problem, what does your toolchain pass to the
>> > linker
>> > (cc -v), what does the crt*.o look like ?
>> >
>> > Danny
>> >
>> First I started with a patch made by Pedro some time ago from a gcc with
>> revision number r140672
>> I think.The problem I had was about mingw compilation because I got :
>>
>> arm-mingw32ce-dlltool --as arm-mingw32ce-as --output-def mingwthrd.def
>> mthr.o mthr_init.o
>>
/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ld:
>> crtbegin.o: No such file: No such file or directory
>> collect2: ld returned 1 exit status
>> make: *** [mingwthrd.def] Erreur 1
>>
>>
>> That's why I thought I needed to use make instead of make all-gcc for
>> bootstrap_gcc but now I think it was a mistake.
>> When I look at mingw project, they provide two empty files for crtbegin
>> and
>> crtend and so I tried to add them
>> in mingw32ce as shown below :
>>
>> ...
>> MINGW_OBJS = crtbegin.o crtend.o CRTglob.o CRTfmode.o CRTinit.o
dllmain.o
>> gccmain.o \
>> crtst.o mthr_stub.o \
>> pseudo-reloc.o pseudo-reloc-list.o cpu_features.o
>> ...
>> crtbegin.o: crtbegin.c
>> crtend.o: crtend.c
>> ...
>>
>> but now I get another error :
>>
>> arm-mingw32ce-dlltool --as arm-mingw32ce-as --output-def mingwthrd.def
>> mthr.o mthr_init.o
>>
/opt/mingw32ce-4.4.0/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/bin/ld:
>> cannot find -lgcc
>> collect2: ld returned 1 exit status
>>
>> I still don't know why but I am investigating...
>> If you want to try maybe it would be better for you to checkout gcc with
>> revision 40672 and apply
>> Pedro's patch(see attchment).
>> You can also try the patch on the current gcc trunk BUT in this case you
>> will have to modify some stuff
>> for instance in gcc/gcc/config/arm/ you need to replace in mingw32.h,
>> wince-pe.h, wince-cegcc.h
>> LIBGCC_SPEC by REAL_LIBGCC_SPEC.
>>
>> About mingw32.h I think it would be a good idea to start to share some
>> code
>> with mingw/mingw-w64 because for
>> instance current include is aware of 64bit targets:
>>
>> #undef TARGET_VERSION
>> #if TARGET_64BIT_DEFAULT
>> #define TARGET_VERSION fprintf (stderr,"(x86_64 MinGW");
>> #else
>> #define TARGET_VERSION fprintf (stderr," (x86 MinGW)");
>> #endif
>>
>>
>> We could start to add something for Wince, for instance:
>> #undef TARGET_VERSION
>> #if TARGET_64BIT_DEFAULT
>> #define TARGET_VERSION fprintf (stderr,"(x86_64 MinGW");
>> #elif TARGET_ARM_CE
>> #define TARGET_VERSION fprintf (stderr," (arm MinGW)");
>> #endif
>> ...
>>
>>
>> > P.S. I think current behaviour of the mingw toolchain is this :
>> >
>> > - crt3.o is linked in with a command as shown below(from cc -v). Note
>> > that crt3.o is the first module passed to the linker.
>> >
>> > /opt/mingw32ce/libexec/gcc/arm-mingw32ce/4.3.2/collect2 -Bdynamic -o
>> > menu.exe
>> >
>>
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.3.2/../../../../arm-mingw32ce/lib/crt3.o
>> > -L/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.3.2
>> >
>>
-L/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.3.2/../../../../arm-mingw32ce/lib
>> > menu.o menu.rsc -laygshell -lcommctrl -lmingw32 -lgcc -lceoldname
>> -lmingwex
>> > -lcoredll -lcoredll -lmingw32 -lgcc -lceoldname -lmingwex -lcoredll
>> >
>> > - crt3.o defines a couple of symbols/functions, but it is carefully
>> > coded and ordered such that WinMainCRTStartupHandler is first in the
>> > .text segment :
>> >
>> > Disassembly of section .text:
>> >
>> > 00000000 <WinMainCRTStartupHandler>:
>> > 0: e92d40f0 push {r4, r5, r6, r7, lr}
>> > 4: e24dd00c sub sp, sp, #12 ; 0xc
>> > 8: e1a05000 mov r5, r0
>> > c: e1a06002 mov r6, r2
>> > ...
>> Hum, all I can say is the fact that when generating cegcc-4.4 dll
>> functions
>> were starting at a weird address:
>> vinc...@vincent-pc:~/projects/testDLL/src$
>> /opt/mingw32ce-4.1.0/bin/arm-mingw32ce-nm testDll-4.4.dll
>> 644d4000 b .bss
>> but exe address was ok.
>>
------------------------------------------------------------------------------
>> This SF.net email is sponsored by:
>> SourcForge Community
>> SourceForge wants to tell your story.
>> http://p.sf.net/sfu/sf-spreadtheword
>> _______________________________________________ Cegcc-devel mailing list
>> Cegcc-devel@lists.sourceforge.net
>> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
------------------------------------------------------------------------------
This SF.net email is sponsored by:
SourcForge Community
SourceForge wants to tell your story.
http://p.sf.net/sfu/sf-spreadtheword
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
