Danny Backx wrote:
> As I said I had the complete build working on mingw32ce. But not
> everything was working yet, and after I did my changes,
> And it appears that I didn't do a commit in all dirs yet (w32api and
> mingw were still missing).
>
Let's try to keep the trunk building at all times, OK ?
If the change was incomplete, then you shouldn't have changed the
default target name in the build script.
> I understood
> that you wanted the target changed to arm-mingw32ce, not
> arm-unknown-mingw32ce.
>
The idea is that building with arm-mingw32ce,
arm-pedroschipmanufacturer-mingw32ce,
arm-whatnot-mingw32ce or arm-wince-mingw32ce should give an identical toolchain.
arm-mingw32ce is a short alias to arm-unknown-mingw32ce, much like arm-linux is
an alias for arm-unknown-linux-gnu. The support is in place. If
people prefer having
the unknown there, we can do it by just changing the build script. If
people still prefer
the old arm-wince-mingw32ce name, it should still work. Relying on:
case $(host) in
*-wince-* )
CE stuff
;;
Is very much a hack that is disapproved by the config/autoconf people.
> I've now updated my tree to get your changes, they appear to work for
> me. I've just committed a change to build the C++ DLLs too; the only way
> to get this kind of stuff tested is to start using it. I've been doing
> that for a while but one person is not enough.
>
Did I mention more than once already that I'd like to follow that Danny Smith
has done with the latest MinGW gcc4.2.1 release?
"* To throw exception across dll/exe boundaries in C++, you will need to
link against the shared libgcc and libstdc++ runtime libs. To link
against shared libgcc, add -shared-libgcc to command line. To link
against shared libstdc++ add -lstdc++_s to command line. Hopefully, in
future releases, the mechanism to seletc static or shared runtime libs
can be improves. Unless you want to use auto-import to import data
objects in libstdc++.dll, also add -D_DLL to commands line or #define
_DLL in top-level headers. Again, this may chenage in future releases."
It is important for us to follow the same options MinGW uses.
1) Leverage their knowledge, understand their work. Our script was copied
Danny already, but he has something new now.
2) Consistency with the big brother. In the future when those options start
showing in MinGW ports of stuff, we'd have 0 porting effort.
3) Leave static runtime as default, so we don't pull the rug under our
users feet.
--
Pedro Alves
-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2005.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
