Re: [Cegcc-devel] VER_PLATFORM_WIN32_CE in winbase.h instead of winnt.h?
On Fri, 2008-04-18 at 14:04 -0500, Pablo Rogina wrote: > Danny, > > you recently added VER_PLATFORM_WIN32_CE to w32api/include/winnt.h > (because of building Roadmap). > > As per > http://msdn2.microsoft.com/en-us/library/ms886768.aspx > it seems that the header file is winbase.h instead. Yes, but the other VER_PLATFORM_WIN32* macros that we have are in winnt.h, and I didn't want to change things too much. > In that case, maybe the Roadmap files have the wrong #includes? I don't think so, but I may not understand why you're saying that. In our set of include files, they're always included both : windows.h +-> windef.h | +-> winnt.h +-> winbase.h Does this answer your question ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] request for a libtool patch
A Saturday 19 April 2008 04:38:37, Vincent Torri wrote: > > The canonical form to match our toolchains should be > > arm*-*-mingw32ce* and arm*-*-cegcc*, which always covers the > > old and the new forms. > > We use *-*-cegcc. Should I modify the patch so that the prefix if 'arm', > and should I put a star at the end ? The star seems useless to me > Notice that cygwin* and mingw* also have a star. The star enables things as i586-mingw32msvc (as ubuntu has, probably debian too). It enables things like arm-cegcc-wince8, arm-cegcc-newabi, etc., if we come to need them, without extra work everywhere. -- Pedro Alves - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] compilation with MSYS / MinGW
A Friday 11 April 2008 18:57:44, Vincent Torri wrote: > On Wed, 9 Apr 2008, Danny Backx wrote: > > On Wed, 2008-04-09 at 09:19 +0200, Vincent Torri wrote: > >> I've succeeded in compiling (some parts of) cegcc with msys. > >> > >> For that, i needed to do some hack and modifications. If some people are > >> interested, i can describe a bit which problems i had and what i > >> modified so that it works (i also think that those fixes will work on > >> all platform). > > > > Yes please send that. > > I tried the 0.51 version > > Here are the problems: > > * build-cegcc.sh : use relative path (../../) for each call of > configure, instead of full path. The problem is that some > programs might not understand POSIX paths in MSYS. It is the > case for gcc, for example. > > * in binutils, makeinfo is not detected correctly. I don't know > why. But, the consequence is that the creation and installation > of all the 'info' doc is broken. I had to modified by hand the > corresponding Makefile.in. What is not good at all is that even > if makeinfo is not detected, the Makefile's try to create the > 'info' documentation. > > * in cegcc/importlibs: for all script files, use /bin/sh instead > of /bin/bash. In some systems (MSYS :-) ) it might be missing, > while /bin/sh always exist. > > * in cegcc/fakecegccdll: same for the install.sh script file. > > * in src/build-cegcc/gcc-bootstrap/gcc : >./tm.h:6:30: error: config/arm/semi.h: No such file or directory > same for other files in tm.h. I have to copy the files manually. > same with: >fp-bit.c:51:23: error: coretypes.h: No such file or directory > > Note that makeinfo is correctly used when building gcc... > > * in gcc itself, the modifications of the previous point, plus: >../../../gcc/gcc/config/arm/gthr-win32.c:49:24: error: gthr-win32.h: > No such file or directory > > * in cegccdll: > > arm-wince-cegcc-gcc -o > /home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll/cegcc.dll > -L/usr/local/lib -L /home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll > -Wl,-Map,/home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll/cegcc.dll.map > -shared -nostdlib \ > -Wl,--whole-archive > /home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll/_tmp/*.o > /opt/cegcc/arm-wince-cegcc/lib/dllcrt1.o \ > -Wl,--no-whole-archive -lcegcc -lcoredll -liphlpapi \ > -Wl,--output-def=/home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll/cegcc >.dll.def \ > -Wl,--out-implib,/home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll/libce >gcc.dll.a.tmp /bin/sh.exe: /opt/cegcc/bin/arm-wince-cegcc-gcc: Bad file > number > make: *** [/home/vincent/svnroot/cegcc/src/build-cegcc/cegccdll/cegcc.dll] > Error 126 > > I don't know how to correct that error. It's missing permissions on a > file, > or a read only access and we try to write on it. I don't know. > I guess it can also be a problem with the POSIX fullname wich is > not supported. > > I stopped here, unfortunately. I think that i also compiled gdb, but > without cegccdll, i can't do anything > Most of the build-cegcc.sh problems would go away if it was rewritten to be more in line of with build-mingw32ce.sh. cegcc is still using the cegcc/importlibs dir, while it should be building w32api. As for the makeinfo problems and the headers not being found, I'd expect those to appear while building gcc for others targets, that is, it doesn't seem cegcc related. If you want to build cegcc and mingw32ce for mingw32 hosts (no dependency on cygwin), then I recomend not using msys, but either canadian compiling from linux, or using cygwin as the build environment instead of msys (which is a cygwin fork). Goggle around for mingw + "identity mount". You'll see that the mingw gcc maintainer uses something like that. -- Pedro Alves - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] compilation of directdraw programs with cegcc
A Wednesday 12 March 2008 09:13:38, Vincent Torri wrote: > so it seems that there are some problems for cegcc tools to correctly deal > with the microsoft import lib. > > Is it normal ? > It is a bug. > I know that the mingw (desktop) devs provide a static lib for ddraw (and > direct3d and opengl too). Would it be possible that a static lib for > ddraw (and d3d and ogl) be added for the cegcc (and or mingw32ce) package > ? (a bit like what mingw does) > Yes, but through src/w32api please. Let't not add more cruft to cegcc/importlibs. Take a look in src/w32api/libce. You'll notice the similarity with src/w32api/lib, but I didn't copy/adapt src/w32api/lib/directx, simply because I never wrote anything directx. -- Pedro Alves - This SF.net email is sponsored by the 2008 JavaOne(SM) Conference Don't miss this year's exciting event. There's still time to save $100. Use priority code J8TL2D2. http://ad.doubleclick.net/clk;198757673;13503038;p?http://java.sun.com/javaone ___ Cegcc-devel mailing list Cegcc-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/cegcc-devel
Re: [Cegcc-devel] request for a libtool patch
Hey,
We use *-*-cegcc. Should I modify the patch so that the prefix if 'arm',
and should I put a star at the end ? The star seems useless to me
Notice that cygwin* and mingw* also have a star. The star enables things
as i586-mingw32msvc (as ubuntu has, probably debian too). It enables
things like arm-cegcc-wince8, arm-cegcc-newabi, etc., if we come
to need them, without extra work everywhere.
Here is the patch, based on yours, that a friend and me have modified, and
which i will send to the libtool-patch ML, in case you are interested.
regards
Vincent Torri? libtool_cegcc.diff
? libtool_cegcc2.diff
? lt.diff
? patch_libtool_cvs.diff
? tests/testsuite.dir
Index: libltdl/config/ltmain.m4sh
===
RCS file: /sources/libtool/libtool/libltdl/config/ltmain.m4sh,v
retrieving revision 1.106
diff -u -r1.106 ltmain.m4sh
--- libltdl/config/ltmain.m4sh 11 Apr 2008 17:21:55 - 1.106
+++ libltdl/config/ltmain.m4sh 19 Apr 2008 16:33:59 -
@@ -363,7 +363,7 @@
case $host in
-*cygwin* | *mingw* | *pw32*)
+*cygwin* | *mingw* | *pw32* | *cegcc*)
# don't eliminate duplications in $postdeps and $predeps
opt_duplicate_compiler_generated_deps=:
;;
@@ -836,7 +836,7 @@
# On Cygwin there's no "real" PIC flag so we must build both object types
case $host_os in
-cygwin* | mingw* | pw32* | os2*)
+cygwin* | mingw* | pw32* | os2* | cegcc*)
pic_mode=default
;;
esac
@@ -1608,7 +1608,7 @@
'exit $?'
tstripme="$stripme"
case $host_os in
- cygwin* | mingw* | pw32*)
+ cygwin* | mingw* | pw32* | cegcc*)
case $realname in
*.dll.a)
tstripme=""
@@ -1714,7 +1714,7 @@
# Do a test to see if this is really a libtool program.
case $host in
- *cygwin*|*mingw*)
+ *cygwin* | *mingw*)
if func_ltwrapper_executable_p "$file"; then
func_ltwrapper_scriptname "$file"
wrapper=$func_ltwrapper_scriptname_result
@@ -1920,7 +1920,7 @@
$RM $export_symbols
eval "${SED} -n -e '/^: @PROGRAM@ $/d' -e 's/^.* \(.*\)$/\1/p'
"'< "$nlist" > "$export_symbols"'
case $host in
- *cygwin* | *mingw* )
+ *cygwin* | *mingw* | *cegcc*)
eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
eval 'cat "$export_symbols" >>
"$output_objdir/$outputname.def"'
;;
@@ -1932,7 +1932,7 @@
eval '$GREP -f "$output_objdir/$outputname.exp" < "$nlist" >
"$nlist"T'
eval '$MV "$nlist"T "$nlist"'
case $host in
- *cygwin | *mingw* )
+ *cygwin | *mingw* | *cegcc*)
eval "echo EXPORTS "'> "$output_objdir/$outputname.def"'
eval 'cat "$nlist" >> "$output_objdir/$outputname.def"'
;;
@@ -1988,7 +1988,7 @@
} lt_dlsymlist;
"
case $host in
- *cygwin* | *mingw* )
+ *cygwin* | *mingw* | *cegcc*)
$ECHO >> "$output_objdir/$my_dlsyms" "\
/* DATA imports from DLLs on WIN32 con't be const, because
runtime relocations are performed -- see ld's documentation
@@ -2074,7 +2074,7 @@
# Transform the symbol file into the correct name.
symfileobj="$output_objdir/${my_outputname}S.$objext"
case $host in
- *cygwin* | *mingw* )
+ *cygwin* | *mingw* | *cegcc*)
if test -f "$output_objdir/$my_outputname.def"; then
compile_command=`$ECHO "X$compile_command" | $Xsed -e "[EMAIL
PROTECTED]@%$output_objdir/$my_outputname.def $symfileobj%"`
finalize_command=`$ECHO "X$finalize_command" | $Xsed -e "[EMAIL
PROTECTED]@%$output_objdir/$my_outputname.def $symfileobj%"`
@@ -2449,7 +2449,7 @@
"
case $host in
# Backslashes separate directories on plain windows
- *-*-mingw | *-*-os2*)
+ *-*-mingw | *-*-os2* | *-*-cegcc*)
$ECHO "\
exec \"\$progdir\$program\" \${1+\"[EMAIL PROTECTED]"}
"
@@ -3076,7 +3076,7 @@
{
$opt_debug
case $host in
-*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+*-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-cegcc*)
# It is impossible to link a dll without this setting, and
# we shouldn't force the makefile maintainer to figure out
# which system we are compiling for in order to pass an extra
@@ -3537,7 +3537,7 @@
;;
esac
case $host in
- *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2*)
+ *-*-cygwin* | *-*-mingw* | *-*-pw32* | *-*-os2* | *-*-cegcc*)
testbindir=`$ECHO "X$dir" | $Xsed -e 's*/lib$*/bin*'`
case :$dllsearchpath: in
*":$dir:"*) ;;
@@ -3555,7 +3555,7 @@
-l*)
if test "X$arg" = "X-lc" || test "X$arg" = "X-lm"; then
case $host in
- *-*-cygwin* | *-*-mingw*
