What I wanted to say in my last message was the fact I thought it would be
more logical to add some missing include and implement them instead of adding #ifndef _MINGW32CE everywhere. Let's examine my case : today I need to generate a D compiler, so if I am listening to you it means I will have to modify D source and insert some #infdef and maybe change some makefiles. Now imagine a new language is created (let's call it X), it means that I will have to do same kind of modifications. I was just saying that if you provide a minimal implementation of missing posix functions using native API (mingw) it would be easier because it wouldn't be necessary to test if errno exists But this was just a suggestion/remark and if you tell me it's a bad idea I believe you. In this case I will do the modifications to the D sources. I was asking because recently I have ported ustl(embedded stl) to wince and this is what I did, I have declared errno.h, unistd, ... and I have provided implementations. Then I was able to compile it without any source code modification of ustl. So with this experience I have thought that it could be interesting to do the same but it may be a bad idea. On Thu, 19 Jun 2008 16:05:50 +0200, Danny Backx <[EMAIL PROTECTED]> wrote: > On Thu, 2008-06-19 at 13:56 +0200, Mosfet wrote: >> I would like to discuss about mingw32ce and the way it's implemented. > [..] >> I know that errno.h, signal.h and ... are not part of the original > windows >> CE platform but I think it would be better to provide these headers and > to >> implement missing posix functions in a dll(let's call it coredllex.dll > or >> posix4ce.dll). >> >> You could anwser me that in the case I want to use these functions I > should >> use cegcc and this is where I disagree because there are lots of reasons >> where I DO NEED to use native libraries : > > We provide two solutions, you say you require a third. > > That may be true but it's not something we currently provide, and I'm > not sure whether I want to spend the time to implement this third > option. > > Also I'm not sure whether you really need it. > >> + Native lib are already embedded on devices so why should I add other > lib >> to do the same things > > I don't understand this argument. > >> + Some professionnal and supported tools are only working if we are > using >> native libs(coredll.dll) for instance when you use AppVerifier, the > tools >> tells the kernel to load a HOOK DLL to be able to trace functions and it >> works only with coredll. > > If you compile stuff with cegcc then it'll link both cegcc.dll and > coredll.dll . If you can't get some tools to work then something else > must be going on. > >> + Everytime you want to generate a new wince compiler from a recent GCC > you >> need to analyze the modifications and to report yours and this not > always >> easy because sometimes software architecture is modified and you have > one >> chunk here and another one there. It's a big waste of time. > > It's not a waste of time if you try to feed back changes to the original > source trees. Also it's definitely not a waste of time if you see that > we save a lot of time for a number of developers : they don't have to do > the tool integration themselves. > >> For now I am trying to generate a D cross-compiler for wince and when I > try >> I get the following error that has something to do with errno : > [..] > >> ** x3: running ./errno.x3.exe -o arm-mingw32ce/gcc/config/errno.d >> /home/Vincent/cegcc/src/build-mingw32ce/gcc/./gcc/xgcc >> -B/home/Vincent/cegcc/src/build-mingw32ce/gcc/./gcc/ >> -B/opt/mingw32ce/arm-mingw32ce/bin/ -B/opt/mingw32ce/arm-mingw32ce/lib/ >> -isystem /opt/mingw32ce/arm-mingw32ce/include -isystem >> /opt/mingw32ce/arm-mingw32ce/sys-include -DHAVE_CONFIG_H -I . -I >> /home/Vincent/cegcc/src/gcc/libphobos/gcc >> x3: failed to get macros. >> make[3]: *** [arm-mingw32ce/gcc/config/errno.d] Error 1 > > With respect, you can't expect me to debug your problem based on this > information. > > Also, quite frankly, nothing in this error message convinces me that the > problem is in cegcc. > >> This is why in my case I would prefer to provide missing posix functions >> when using mingw32ce. >> >> Because otherwise I will have to report modifications everytime D is >> releasing a new version and since it 's a very recent language, things > are >> moving fast. > > You might want to do what I said above, and feed the changes for D on > WinCE back to the D people so their next release will work out of the > box on WinCE. > >> The problem is I am not familiar at all with GCC build system so if you > can >> tell me quickly how it could be done, it would help me. > > There's never a quick reply to a hard question. > > You might want to take a look at the cegcc/tools/errno directory. It > provides simple errno simulation. You might want to build something > similar for signals, you might be able to pull it from the newlib > sources (see src/newlib/newlib/libc/signal). > > But don't expect such solutions to just work : WinCE just doesn't > support signals and errno. > > Danny > ------------------------------------------------------------------------- Check out the new SourceForge.net Marketplace. It's the best place to buy or sell services for just about anything Open Source. http://sourceforge.net/services/buy/index.php _______________________________________________ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
