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
On Sun, 2009-02-01 at 19:59 +0100, Vincent R. wrote:
> On Sun, 01 Feb 2009 13:59:29 +0100, Danny Backx <[email protected]>
> 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
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/cegcc-devel
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
------------------------------------------------------------------------------
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
[email protected]
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
