On Monday 28 December 2009 17:00:11, Vincent Torri wrote:
>
> On Mon, 28 Dec 2009, Pedro Alves wrote:
>
> >> btw, feel free to mention any improvements about the port (see the README
> >> file, about the optimization flags, for example)
> >
> >> From said README:
> >
> >> 7) Compilation
> >>
> >> * Version: svn 22-Jul-2008
> >> * Architecture: mingw32ce
> >> * CPPFLAGS: -D_WIN32_WCE=0x0400 -DNO_ERRNO_H
> >> * CFLAGS: -O3 -Wall -mms-bitfields
> >
> > Is the explicit "-mms-bitfields" really needed? I
> > thought mingw32ce defaulted to -ms-bitfields?
>
> How can we know that ?
gcc/config/arm/mingw32.h
#undef TARGET_DEFAULT
#define TARGET_DEFAULT (MASK_NOP_FUN_DLLIMPORT | \
MASK_MS_BITFIELD_LAYOUT | \
^^^^^^^^^^^^^^^^^^^^^^^
MASK_RETURN_AGGREGATES_IN_MEMORY)
You could confirm this is doing what it's meant to be
doing by compiling a testcase uses structures
with bitfields, and checking that it compiles to the
same thing with and without the flag. But, yeah,
this should be documented somewhere.
>
> > Any reason -D_WIN32_WCE=0x0400 (or -D_WIN32_WCE=0x0300, I think
> > it builds fine) isn't set in zutil.h instead of
> > on the command line?
>
> Hmm, i don't know, i never thought about it. I'll check that
We're discussing this in the zlib mailing list.
>
> >> * LDFLAGS: --enable-auto-import -s
> >
> > Same for --enable-auto-import.
>
> same question :-)
I meant to delete that sentence, but it seems I forgot.
Anyway, what I really meant was to ask was if zlib is
actually auto-importing anything. Is it?
>
> > Any reason you don't use win32/Makefile.gcc instead of heavily patching the
> > top Makefile? BTW, I think used to just run:
> >
> > make CC=arm-mingw32ce-gcc AR="arm-mingw32ce-ar rc"
> > RANLIB="arm-mingw32ce-ranlib" CFLAGS="-DNO_ERRNO_H -g3 -O0"
> >
> > on the top Makefile.
>
> the Makefile.gcc compiles also the binaries (I compile only the library).
What's wrong with compiling the binaries? It's good for testing
at the least.
> It is cleaner too.
Why?
> I plan to provide a Makefile for Windows CE only, in a
> subdir of zlib
>
> > I also see that you set -D_WIN32_IE=0x0400 in the Makefile. I wish
> > people would stop doing that. _WIN32_IE is not meant for CE
> > usage. If you do need it, it's a bug in the w32api headers that
> > needs fixing (to expose functions/macros under _WIN32_WCE).
>
> Then, this should be removed from:
>
> http://cegcc.sourceforge.net/docs/details.html
It already says that you shouldn't do that, though.
> I'll remove it
Thanks. Let's see if something breaks. :-)
> >> * Porting issues:
> >
> >> - does not use the errno system, but zlib implement some dummy
> >> errno variable for the compilation on Windows CE.
> >
> > Hmmm. Is there any plan to use GetLastError instead? dummy errno
> > variables are evil. IMO, the need for NO_ERRNO_H should be cleaned
> > away.
>
> About GetLastError, i didn't plan to use it. I'll check that too. I'll try
> to use it. Indeed, using dummy errno is not good.
I'll try this, and reply over at zlib-de...@.
> > I spotted one thing extra thing should be tweaked:
> >
> > >grep "fd < 0" *
> > gzio.c: s->file = fd < 0 ? F_OPEN(path, fmode) : (FILE*)fdopen(fd,
> > fmode);
> > gzio.c: if (fd < 0) return (gzFile)Z_NULL;
> >
> > Should be changed to check for explicit -1, like:
> >
> > s->file = fd == -1 ? F_OPEN(path, fmode) : (FILE*)fdopen(fd, fmode);
> >
> > This is because file descriptors in Windows CE are really
> > handles in desguise, and they can really end up negative
> > without that being an error.
>
> I'll ask Marc about that. There should be no problem.
Awesome. I see Marc already applied the fix. :-)
--
Pedro Alves
------------------------------------------------------------------------------
This SF.Net email is sponsored by the Verizon Developer Community
Take advantage of Verizon's best-in-class app development support
A streamlined, 14 day to market process makes app distribution fast and easy
Join now and get one step closer to millions of Verizon customers
http://p.sf.net/sfu/verizon-dev2dev
_______________________________________________
Cegcc-devel mailing list
Cegcc-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/cegcc-devel
