Menu
▾
▴
cegcc-devel
|
From: Vincent T. <vt...@un...> - 2010-01-23 12:37:00
|
Hey, i've just installed cegcc (mingw32ce compiler) from the svn repo. There is a limits.h in the folowin sub directories: /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/ /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/ /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/ /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/ When i include limits.h, it is the one in the third directory that is chosen, and not the one in the second (which, i think, is the correct one). Is it normal ? Vincent Torri |
|
From: Danny B. <dan...@sc...> - 2010-01-29 17:12:12
|
On Sat, 2010-01-23 at 13:33 +0100, Vincent Torri wrote:
> i've just installed cegcc (mingw32ce compiler) from the svn repo. There is
> a limits.h in the folowin sub directories:
>
> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/
> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/
> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/
> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/
>
> When i include limits.h, it is the one in the third directory that is
> chosen, and not the one in the second (which, i think, is the correct
> one). Is it normal ?
I did a quick test :
pavilion: {18} arm-mingw32ce-gcc -H -c t.c |& grep limit
. /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include/limits.h
pavilion: {19} find /opt/mingw32ce/ -name limits.h -print
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/limits.h
/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/limits.h
/opt/mingw32ce/arm-mingw32ce/include/limits.h
and find that it takes the third limits.h in this list.
When I add a limits.h in include-fixed, things change :
pavilion: {20}
touch /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
pavilion: {21} arm-mingw32ce-gcc -H -c t.c | & grep limit
. /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
pavilion: {22}
Is that different on your system ?
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
|
|
From: Vincent T. <vt...@un...> - 2010-01-29 17:47:25
|
On Fri, 29 Jan 2010, Danny Backx wrote:
> On Sat, 2010-01-23 at 13:33 +0100, Vincent Torri wrote:
>> i've just installed cegcc (mingw32ce compiler) from the svn repo. There is
>> a limits.h in the folowin sub directories:
>>
>> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/
>> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/
>> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/
>> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/
>>
>> When i include limits.h, it is the one in the third directory that is
>> chosen, and not the one in the second (which, i think, is the correct
>> one). Is it normal ?
>
> I did a quick test :
>
> pavilion: {18} arm-mingw32ce-gcc -H -c t.c |& grep limit
> . /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/include/limits.h
i get :
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
> pavilion: {19} find /opt/mingw32ce/ -name limits.h -print
> /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/limits.h
> /opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/limits.h
> /opt/mingw32ce/arm-mingw32ce/include/limits.h
i get :
/home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/limits.h
/home/torri/local/opt/mingw32ce/arm-mingw32ce/include/limits.h
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
/home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/limits.h
Vincent Torri
>
> and find that it takes the third limits.h in this list.
>
> When I add a limits.h in include-fixed, things change :
>
> pavilion: {20}
> touch /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
> pavilion: {21} arm-mingw32ce-gcc -H -c t.c | & grep limit
> . /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
> /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/limits.h
> pavilion: {22}
>
> Is that different on your system ?
>
> Danny
>
>
> --
> Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
>
>
|
|
From: Danny B. <dan...@sc...> - 2010-01-30 11:35:22
|
On Fri, 2010-01-29 at 18:47 +0100, Vincent Torri wrote: > > On Fri, 29 Jan 2010, Danny Backx wrote: > > > On Sat, 2010-01-23 at 13:33 +0100, Vincent Torri wrote: > >> i've just installed cegcc (mingw32ce compiler) from the svn repo. There is > >> a limits.h in the folowin sub directories: > >> > >> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/ > >> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/ > >> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/ > >> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/ > >> > >> When i include limits.h, it is the one in the third directory that is > >> chosen, and not the one in the second (which, i think, is the correct > >> one). Is it normal ? I reread your original message again after a full reinstall on my system. The full reinstall made the fourth limits.h - the one you're mentioning - turn up again. So I must have removed it locally because of an issue with it, and forgotten all about it :-) I just spent a while figuring out why this file is getting installed. In the gcc build system, this appears to be hardcoded, so not something I can work around easily without upsetting the gcc folks. So the next best thing appears to just remove it in the scripts/build-mingw32ce.h . I just committed such a fix, can you verify ? Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Pedro A. <pe...@co...> - 2010-01-30 17:48:45
|
On Saturday 30 January 2010 11:35:45, Danny Backx wrote: > On Fri, 2010-01-29 at 18:47 +0100, Vincent Torri wrote: > > > > On Fri, 29 Jan 2010, Danny Backx wrote: > > > > > On Sat, 2010-01-23 at 13:33 +0100, Vincent Torri wrote: > > >> i've just installed cegcc (mingw32ce compiler) from the svn repo. There is > > >> a limits.h in the folowin sub directories: > > >> > > >> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/c++/4.4.0/tr1/ > > >> /home/torri/local/opt/mingw32ce/arm-mingw32ce/include/ > > >> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/ > > >> /home/torri/local/opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/install-tools/include/ > > >> > > >> When i include limits.h, it is the one in the third directory that is > > >> chosen, and not the one in the second (which, i think, is the correct > > >> one). Is it normal ? Doesn't the gcc version include_next the mingw one? Is there actually a problem you're seeing? > I reread your original message again after a full reinstall on my > system. The full reinstall made the fourth limits.h - the one you're > mentioning - turn up again. > > So I must have removed it locally because of an issue with it, and > forgotten all about it :-) > > I just spent a while figuring out why this file is getting installed. In > the gcc build system, this appears to be hardcoded, so not something I > can work around easily without upsetting the gcc folks. > So the next best thing appears to just remove it in the > scripts/build-mingw32ce.h . > I just committed such a fix, can you verify ? Please don't. Please revert. If there's a real problem here, I'm sure it has a proper fix. Let's not get into the habbit of committing quick workarounds for not understood problems. -- Pedro Alves |
|
From: Pedro A. <pe...@co...> - 2010-01-31 13:05:35
|
On Saturday 30 January 2010 17:48:45, Pedro Alves wrote: > On Saturday 30 January 2010 11:35:45, Danny Backx wrote: > > So the next best thing appears to just remove it in the > > scripts/build-mingw32ce.h . > > I just committed such a fix, can you verify ? > > Please don't. Please revert. If there's a real > problem here, I'm sure it has a proper fix. Let's not get > into the habbit of committing quick workarounds for not > understood problems. I've reverted the scripts change in svn myself. (after wanting to look at the limits.h gcc is installed, but somehow forgetting about the hack, and building a pristine head toolchain, which of course, wipes the file. Duh. Starting over...) -- Pedro Alves |
|
From: Dave K. <dav...@go...> - 2010-01-30 18:41:26
|
On 30/01/2010 17:48, Pedro Alves wrote: > Doesn't the gcc version include_next the mingw one? Is there > actually a problem you're seeing? GCC has its own private version, which is supposed to include a private fixed version of the system's original header: http://gcc.gnu.org/ml/gcc/2004-01/msg01706.html > If there is a system limits.h, then the limits.h which gcc installs > should have the line > #include "syslimits.h" > > That file should either be the fixed version of <limits.h> installed > by fixincludes, or, if <limits.h> does not need to be fixed, it should > have the line > #include_next <limits.h> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST = true" in the t-* makefile frag, so if you guys don't get syslimits.h being generated, maybe that would fix it for you too? cheers, DaveK |
|
From: Danny B. <dan...@sc...> - 2010-01-31 10:10:57
Attachments:
chg
|
On Sat, 2010-01-30 at 18:58 +0000, Dave Korn wrote:
> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST =
> true" in the t-* makefile frag, so if you guys don't get syslimits.h being
> generated, maybe that would fix it for you too?
I must admit I didn't know I could set that variable in the t-* file.
But I think it does the wrong thing, it appears to override only the
test in the generated cegcc/src/build-mingw32ce/gcc/gcc/Makefile :
if $(LIMITS_H_TEST) ; then \
cat $(srcdir)/limitx.h $(srcdir)/glimits.h
$(srcdir)/limity.h > tmp-xlimits.h; \
else \
cat $(srcdir)/glimits.h > tmp-xlimits.h; \
fi; \
$(mkinstalldirs) $${fix_dir}; \
chmod a+rx $${fix_dir} || true; \
rm -f $${fix_dir}/limits.h; \
mv tmp-xlimits.h $${fix_dir}/limits.h; \
chmod a+r $${fix_dir}/limits.h; \
so all it appears to influence is whether glimits.h is surrounded by
limitx.h and limity.h or not.
What we need here is no limits.h coming from gcc because it already
comes from our src/mingw/include .
Inspired on all that, how does the patch attached look ?
It should be the more fundamental take on the problem.
Danny
--
Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 13:01:17
|
On Sunday 31 January 2010 12:32:21, Dave Korn wrote:
> I don't think it should be necessary to patch the build system, since it's
> already capable of doing the right thing (which is to create the private
> header and fixed syslimits), we need to understand why it isn't doing that.
>
My guess is that with the options we're building gcc,
gcc isn't looking at ($tooldir)/includes for fixincludable headers, but
at ($tooldir)/sys-includes. So it just installs its own limits.h as if
the system doesn't have one already.
I think we should be building gcc with `--with-sysroot=${PREFIX}/arm-mingw32ce/'
Might work to pass --with-headers=($tooldir)/includes to gcc too, but that
feels hackish.
Oh, and the bootstrap gcc's headers get installed at the same
place as the final gcc. If the bootstrap gcc installs headers
the final gcc doesn't, we end up with stale headers installed.
We should be installing the bootstrap compiler in a staged
dir (or better, everything)..
--
Pedro Alves
|
|
From: Dave K. <dav...@go...> - 2010-01-31 13:16:03
|
On 31/01/2010 10:11, Danny Backx wrote:
> On Sat, 2010-01-30 at 18:58 +0000, Dave Korn wrote:
>> It goes on to suggest that it might be necessary to define "LIMITS_H_TEST =
>> true" in the t-* makefile frag, so if you guys don't get syslimits.h being
>> generated, maybe that would fix it for you too?
> so all it appears to influence is whether glimits.h is surrounded by
> limitx.h and limity.h or not.
Ah, so it does.
> What we need here is no limits.h coming from gcc because it already
> comes from our src/mingw/include .
I'm fairly sure GCC *requires* its private internal version of limits.h for
correct operation, and that what you want is limits.h and syslimits.h.
> Inspired on all that, how does the patch attached look ?
> It should be the more fundamental take on the problem.
I don't think it should be necessary to patch the build system, since it's
already capable of doing the right thing (which is to create the private
header and fixed syslimits), we need to understand why it isn't doing that.
As I mentioned in another post, I'm updating my cegcc. I'll take a look at
what happens during the build.
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 14:10:26
|
On 31/01/2010 12:54, Pedro Alves wrote:
> On Sunday 31 January 2010 12:32:21, Dave Korn wrote:
>> I don't think it should be necessary to patch the build system, since it's
>> already capable of doing the right thing (which is to create the private
>> header and fixed syslimits), we need to understand why it isn't doing that.
>>
>
> My guess is that with the options we're building gcc,
> gcc isn't looking at ($tooldir)/includes for fixincludable headers, but
> at ($tooldir)/sys-includes. So it just installs its own limits.h as if
> the system doesn't have one already.
Yep, you can see it happening by cd'ing into the gcc/gcc/ build dir and
running "rm stmp-* ; make": it happens here -
> set -e; for ml in `cat fixinc_list`; do \
> sysroot_headers_suffix=`echo ${ml} | sed -e 's/;.*$//'`; \
> multi_dir=`echo ${ml} | sed -e 's/^[^;]*;//'`; \
> fix_dir=include-fixed${multi_dir}; \
> if [ -f `echo /opt/mingw32ce/lib/gcc/arm-mingw32ce/4.4.0/../../../../arm-mingw32ce/sys-include | sed -e :a -e 's,[^/]*/\.\.\/,,' -e ta`/limits.h ] ; then \
This if fails
> cat /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/limitx.h /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/glimits.h /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/limity.h > tmp-xlimits.h; \
> else \
> cat /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/glimits.h > tmp-xlimits.h; \
.. so we use the default template.
> fi; \
> /bin/sh /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/../mkinstalldirs ${fix_dir}; \
> chmod a+rx ${fix_dir} || true; \
> rm -f ${fix_dir}/limits.h; \
> mv tmp-xlimits.h ${fix_dir}/limits.h; \
> chmod a+r ${fix_dir}/limits.h; \
> done
> rm -f include-fixed/README
> cp /tmp/cegcc/cegcc/trunk/cegcc/src/gcc-4.4.0/gcc/../fixincludes/README-fixinc include-fixed/README
> chmod a+r include-fixed/README
> echo timestamp > stmp-int-hdrs
> I think we should be building gcc with `--with-sysroot=${PREFIX}/arm-mingw32ce/'
Just testing that in a non-bootstrap build of gcc only.
> Might work to pass --with-headers=($tooldir)/includes to gcc too, but that
> feels hackish.
Yeh, don't like the look of that!
> Oh, and the bootstrap gcc's headers get installed at the same
> place as the final gcc. If the bootstrap gcc installs headers
> the final gcc doesn't, we end up with stale headers installed.
> We should be installing the bootstrap compiler in a staged
> dir (or better, everything)..
Yep, it would be a good idea to install the bootstrap compiler to a DESTDIR
and then discard it altogether once it's been used. (However given that the
bootstrap and final gcc are configured so similarly, I'm not sure whether any
problems will actually have been arising in practice.)
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 14:25:55
|
On 31/01/2010 14:27, Dave Korn wrote:
> On 31/01/2010 12:54, Pedro Alves wrote:
>> I think we should be building gcc with `--with-sysroot=${PREFIX}/arm-mingw32ce/'
>
> Just testing that in a non-bootstrap build of gcc only.
Hmm, it's not quite that directly simple:
> The directory that should contain system headers does not exist:
> /opt/mingw32ce/arm-mingw32ce/usr/include
Doh. I'll try --with-headers/--with-libs instead.
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 14:55:21
|
On Sunday 31 January 2010 14:43:06, Dave Korn wrote: > > The directory that should contain system headers does not exist: > > /opt/mingw32ce/arm-mingw32ce/usr/include Hmm, or: NATIVE_SYSTEM_HEADER_DIR = /include in t-wince-pe (or some other make fragment) ? I see that config/i386/t-mingw32 has: NATIVE_SYSTEM_HEADER_DIR = /mingw/include I'm guessing a cross build of upstream MinGW is putting headers in $(tooldir)/mingw/include then. I never looked at their build scripts. I don't know if we'd have to do something for libs. If so, how does one tell gcc that? -- Pedro Alves |
|
From: Dave K. <dav...@go...> - 2010-01-31 15:05:57
|
On 31/01/2010 14:48, Pedro Alves wrote:
> On Sunday 31 January 2010 14:43:06, Dave Korn wrote:
>>> The directory that should contain system headers does not exist:
>>> /opt/mingw32ce/arm-mingw32ce/usr/include
>
> Hmm, or:
>
> NATIVE_SYSTEM_HEADER_DIR = /include
>
> in t-wince-pe (or some other make fragment) ?
>
> I see that config/i386/t-mingw32 has:
>
> NATIVE_SYSTEM_HEADER_DIR = /mingw/include
Will that work in cross?
> I'm guessing a cross build of upstream MinGW is putting
> headers in $(tooldir)/mingw/include then. I never looked
> at their build scripts.
>
> I don't know if we'd have to do something for libs. If so,
> how does one tell gcc that?
Don't think we can, but then again, gcc doesn't really do anything with the
libraries except copy them around. We may need to fix the mingw stage of the
build script to prepare a proper sysroot, or possibly just run the
install-headers stage of it and force it to install to
$prefix/$target/sys-include.
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 15:22:11
|
On 31/01/2010 14:43, Dave Korn wrote:
> Doh. I'll try --with-headers/--with-libs instead.
So, adding "--with-headers=$prefix/arm-mingw32ce/include
--with-libs=$prefix/arm-mingw32ce/lib" to the configure line for the main gcc
build gets me an installation with lots of new fixed headers in the
include-fixed dir, among which we have a limits.h with the correct header and
trailer. Preinstalling headers to $prefix/$target/sys-include would probably
do the exact same thing but seems like needless duplication. And I don't
think the --with-libs was even necessary at all from the looks of it.
I'll try a full clean build with nothing preinstalled and this patch:
Index: build-mingw32ce.sh
===================================================================
--- build-mingw32ce.sh (revision 1440)
+++ build-mingw32ce.sh (working copy)
@@ -341,6 +341,7 @@ build_gcc()
--disable-interwork \
--without-newlib \
--enable-checking \
+ --with-headers=${PREFIX}/${TARGET}/include \
--with-headers \
--disable-__cxa_atexit
;;
cheers,
DaveK
|
|
From: Dave K. <dav...@go...> - 2010-01-31 19:33:34
|
On 31/01/2010 15:39, Dave Korn wrote:
> I'll try a full clean build with nothing preinstalled and this patch:
>
> Index: build-mingw32ce.sh
> ===================================================================
> --- build-mingw32ce.sh (revision 1440)
> +++ build-mingw32ce.sh (working copy)
> @@ -341,6 +341,7 @@ build_gcc()
> --disable-interwork \
> --without-newlib \
> --enable-checking \
> + --with-headers=${PREFIX}/${TARGET}/include \
> --with-headers \
> --disable-__cxa_atexit
> ;;
That was wrong, because I forgot to remove the empty --with-headers option
on the next line. JFTR, because Pedro's patch is probably the better
approach, this worked:
Index: build-mingw32ce.sh
===================================================================
--- build-mingw32ce.sh (revision 1440)
+++ build-mingw32ce.sh (working copy)
@@ -322,7 +322,7 @@ build_gcc()
--disable-interwork \
--without-newlib \
--enable-checking \
- --with-headers
+ --with-headers=${PREFIX}/${TARGET}/include
;;
gcc-*)
${BASE_DIRECTORY}/${gcc_src}/configure \
@@ -341,7 +341,7 @@ build_gcc()
--disable-interwork \
--without-newlib \
--enable-checking \
- --with-headers \
+ --with-headers=${PREFIX}/${TARGET}/include \
--disable-__cxa_atexit
;;
esac
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 15:32:06
|
On Sunday 31 January 2010 15:23:05, Dave Korn wrote:
>
> > in t-wince-pe (or some other make fragment) ?
> >
> > I see that config/i386/t-mingw32 has:
> >
> > NATIVE_SYSTEM_HEADER_DIR = /mingw/include
>
> Will that work in cross?
Yes. Due to:
configure.ac:
CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
I also saw:
config/spu/t-spu-elf:19:NATIVE_SYSTEM_HEADER_DIR = /include
There's no native spu-elf toolchain for sure, so this looks like
some precedent.
> or possibly just run the
> install-headers stage of it and force it to install to
> $prefix/$target/sys-include.
Right, that should work too, though the --with-headers pseudo-ugly
option avoided needless copies of files in the end.
I'm not sure what is the best approach. I've just built a toolchain
with the patches below. A bunch of files showed up on include-fixed,
amonst which, there was a include-fixed/syslimits.h file.
Index: gcc/config/arm/t-wince-pe
===================================================================
--- gcc/config/arm/t-wince-pe (revision 1439)
+++ gcc/config/arm/t-wince-pe (working copy)
@@ -161,3 +161,5 @@ SHLIB_MKMAP = $(srcdir)/mkmap-flat.awk
# does not get substituted before mkmap-flat.awk is run.
SHLIB_MKMAP_OPTS = -v pe_dll=libgcc_s_$(EH_MODEL)-$(SHLIB_SOVERSION)$(SHLIB_EXT)
SHLIB_MAPFILES = $(srcdir)/libgcc-std.ver
+
+NATIVE_SYSTEM_HEADER_DIR = /include
Index: build-mingw32ce.sh
===================================================================
--- build-mingw32ce.sh (revision 1440)
+++ build-mingw32ce.sh (working copy)
@@ -192,6 +194,7 @@ build_binutils()
--host=${HOST} \
--target=${TARGET} \
--disable-nls \
+ --with-sysroot=${PREFIX}/${TARGET}/ \
--disable-werror
make ${PARALLELISM}
@@ -221,6 +224,7 @@ build_bootstrap_gcc()
--disable-shared \
--disable-interwork \
--without-newlib \
+ --without-headers \
--enable-checking || exit 1
case ${gcc_src} in
@@ -341,11 +345,11 @@ build_gcc()
--disable-interwork \
--without-newlib \
--enable-checking \
- --with-headers \
+ --with-sysroot=${PREFIX}/${TARGET}/ \
--disable-__cxa_atexit
;;
esac
-
+
# we build libstdc++ as dll, so we don't need this.
# --enable-fully-dynamic-string \
@@ -382,6 +386,7 @@ build_gdb()
--disable-win32-registry \
--disable-multilib \
--disable-interwork \
+ --with-sysroot=${PREFIX}/${TARGET}/ \
--enable-checking
export CFLAGS=${PREV_CFLAGS}
|
|
From: Dave K. <dav...@go...> - 2010-01-31 16:09:29
|
On 31/01/2010 15:31, Pedro Alves wrote:
> On Sunday 31 January 2010 15:23:05, Dave Korn wrote:
>>> in t-wince-pe (or some other make fragment) ?
>>>
>>> I see that config/i386/t-mingw32 has:
>>>
>>> NATIVE_SYSTEM_HEADER_DIR = /mingw/include
>> Will that work in cross?
>
> Yes. Due to:
>
> configure.ac:
> CROSS_SYSTEM_HEADER_DIR='$(TARGET_SYSTEM_ROOT)$${sysroot_headers_suffix}$(NATIVE_SYSTEM_HEADER_DIR)'
>
> I also saw:
> config/spu/t-spu-elf:19:NATIVE_SYSTEM_HEADER_DIR = /include
>
> There's no native spu-elf toolchain for sure, so this looks like
> some precedent.
Righto. I was a bit concerned about the comment about it having to match
SYSTEM_INCLUDE_DIR.
>> or possibly just run the
>> install-headers stage of it and force it to install to
>> $prefix/$target/sys-include.
>
> Right, that should work too, though the --with-headers pseudo-ugly
> option avoided needless copies of files in the end.
>
> I'm not sure what is the best approach.
Well, --with-headers is deprecated, and --with-sysroot is meant to be the
way to go these days, so I figure your patch is preferable if nothing untoward
crops up.
> I've just built a toolchain
> with the patches below. A bunch of files showed up on include-fixed,
> amonst which, there was a include-fixed/syslimits.h file.
I took a quick look at some of the other fixes that are getting applied, for
instance _mingw.h gets this:
@@ -242,7 +251,7 @@
#define __MINGW_ATTRIB_NONNULL(arg)
#endif /* GNUC >= 3.3 */
-#if defined(UNDER_CE) && defined(__arm__)
+#if defined(__UNDER_CE__) && defined(__arm__)
/* ARM Windows CE is not underscored. */
# define __U(SYM) _ ## SYM
# define __IMP(S) __imp_ ## S
... and many files (this is wininet.h) have changes relating to the unicode flag:
@@ -731,7 +740,7 @@ typedef struct {
DWORD dwFlags;
} INTERNET_CONNECTED_INFO, * LPINTERNET_CONNECTED_INFO;
-#ifdef UNICODE
+#ifdef __UNICODE__
typedef URL_COMPONENTSW URL_COMPONENTS;
typedef LPURL_COMPONENTSW LPURL_COMPONENTS;
typedef GOPHER_FIND_DATAW GOPHER_FIND_DATA;
Do those look sensible to you? There could conceivably be some knock-on
effect of having all the fixed headers for the first time.
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 16:39:35
|
On Sunday 31 January 2010 16:26:38, Dave Korn wrote: > -#if defined(UNDER_CE) && defined(__arm__) > +#if defined(__UNDER_CE__) && defined(__arm__) > -#ifdef UNICODE > +#ifdef __UNICODE__ > Do those look sensible to you? There could conceivably be some knock-on > effect of having all the fixed headers for the first time. Indeed. Those look harmless, and could potentially be TRT when building with strict standards. Both UNDER_CE and UNICODE are builtin defines: >arm-mingw32ce-gcc -dM -E - < /dev/null | grep UNICODE #define UNICODE 1 #define _UNICODE 1 #define __UNICODE__ 1 #define __UNICODE 1 >arm-mingw32ce-gcc -ansi -dM -E - < /dev/null | grep UNICODE #define _UNICODE 1 #define __UNICODE__ 1 #define __UNICODE 1 Or, maybe we should force the non-underscored versions to be always present, given that these are "standard" Windows defines. These look pretty busted though: --- /opt/mingw32ce-0.59/arm-mingw32ce/include/windef.h 2010-01-31 15:10:18.000000000 +0000 +++ /opt/mingw32ce-0.59/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/windef.h 2010-01-31 15:21:19.000000000 +0000 : : -#ifndef WIN32 +#ifndef __WIN32__ #define WIN32 #endif : -#ifndef _fastcall +#ifndef __fastcall__ #define _fastcall __attribute__((fastcall)) #endif I couldn't find yet where are the fixinclude rules that cause all these changes. (looking at these rules for the first time). -- Pedro Alves |
|
From: Dave K. <dav...@go...> - 2010-01-31 16:49:23
|
On 31/01/2010 16:39, Pedro Alves wrote:
> These look pretty busted though:
>
> --- /opt/mingw32ce-0.59/arm-mingw32ce/include/windef.h 2010-01-31 15:10:18.000000000 +0000
> +++ /opt/mingw32ce-0.59/lib/gcc/arm-mingw32ce/4.4.0/include-fixed/windef.h 2010-01-31 15:21:19.000000000 +0000
> :
> :
> -#ifndef WIN32
> +#ifndef __WIN32__
> #define WIN32
> #endif
This seems a strange thing to have in the first place; if WIN32 isn't
defined when you try and include a windows header, you're not compiling on a
windows system and should error, shouldn't you? Might be simplest to remove
that clause from windef.h altogether, given the compiler always defines WIN32.
> -#ifndef _fastcall
> +#ifndef __fastcall__
> #define _fastcall __attribute__((fastcall))
> #endif
Likewise this one is built into the compiler's predefines. Errm, only
incorrectly so:
> $ arm-mingw32ce-gcc -dM -E - < /dev/null | grep fast
> #define _fastcall __attribute__((__cdecl__))
> #define __fastcall __attribute__((__cdecl__))
>
> $
LOL, that made me do a double-take. Err? Is this maybe deliberate because
(WAG) fastcall doesn't mean anything on CE or some such reason?
cheers,
DaveK
|
|
From: Pedro A. <pe...@co...> - 2010-01-31 17:04:17
|
[ I'm going AFK from a couple of hours, so let me reply quickly
just half the questions ]
On Sunday 31 January 2010 17:06:32, Dave Korn wrote:
> LOL, that made me do a double-take. Err? Is this maybe deliberate because
> (WAG) fastcall doesn't mean anything on CE or some such reason?
Yes, exactly that. :-)
config/arm/wince-pe.h:
/* Let's just ignore stdcall, and fastcall. */ \
builtin_define ("__stdcall=__attribute__((__cdecl__))"); \
builtin_define ("__fastcall=__attribute__((__cdecl__))"); \
builtin_define ("__cdecl=__attribute__((__cdecl__))"); \
ISTR that's what MSVC does too (or defines empty), but I may be wrong.
CE's function call ABI is all cdecl.
--
Pedro Alves
|
|
From: Vincent T. <vt...@un...> - 2010-02-03 19:25:46
|
Hey, So, is there some fixes that has been pushed in svn ? Vincent Torri |
|
From: Vincent T. <vt...@un...> - 2010-03-14 07:55:52
|
Hey, So, is there some fixes that has been pushed in svn about that limits.h problem ? Vincent Torri |
|
From: Danny B. <dan...@sc...> - 2010-03-15 19:43:32
|
On Sun, 2010-03-14 at 08:55 +0100, Vincent Torri wrote: > So, is there some fixes that has been pushed in svn about that limits.h > problem ? > > Vincent Torri My workaround was removed, I've not taken action on this issue since. Danny -- Danny Backx ; danny.backx - at - scarlet.be ; http://danny.backx.info |
|
From: Pedro A. <pe...@co...> - 2010-03-15 19:47:40
|
On Monday 15 March 2010 19:44:01, Danny Backx wrote: > > So, is there some fixes that has been pushed in svn about that limits.h > > problem ? > > > > Vincent Torri > > My workaround was removed, I've not taken action on this issue since. I haven't had time to finish fixing the issue properly. If this botters you so much, you can use Danny's fix locally. -- Pedro Alves |
×
Want the latest updates on software, tech news, and AI?
Get latest updates about software, tech news, and AI from SourceForge directly in your inbox once a month.
Thanks for helping keep SourceForge clean.
X