Re: getting gcc mailing list archives
Hi Ho! I successfully got replies from gcc.gnu.org for the following requests: [EMAIL PROTECTED] [EMAIL PROTECTED] [EMAIL PROTECTED] I guess your e-mail is not registered at [EMAIL PROTECTED] In other words, the e-mail address with which you sent the request is not subscribed to [EMAIL PROTECTED] In spite of having your e-mail address registered at [EMAIL PROTECTED], you still need to subscribe your e-mail address to gcc@gcc.gnu.org if you want to retrieve something from that mailing list. Please tell us if your e-mail address has already been subscribed to gcc@gcc.gnu.org and you still cannot retrieve anything with [EMAIL PROTECTED] so that we can debug the problem. Best regards, Eus --- On Sat, 6/28/08, Eus <[EMAIL PROTECTED]> wrote: > Hi Ho! > > --- On Fri, 6/27/08, Mojmir Svoboda <[EMAIL PROTECTED]> wrote: > > > *sigh*, i do not like to look like total stupid but this is > > what i do: > > 1. i want everything from > > http://gcc.gnu.org/ml/gcc/2008-06/msg00385.html > > so i open the raw message, see some line like > > From gcc-return-147334-listarch-gcc=gcc dot gnu dot org > > at gcc ... > > and guess that the number 147334 is the archive id > > Yup, you guessed it right! > > > 2. send empty mail to > > [EMAIL PROTECTED] > > Humm... 147334 to 147434 means 101 instead of 100. What about if you try a > lower number of indices? > > > 3. ...and nothing happens ;) > > Just three days ago I successfully got what I wanted with [EMAIL PROTECTED] > although I have never tried [EMAIL PROTECTED] > > > what am i doing wrong, please? > > I think, none. I also try [EMAIL PROTECTED] just now. So, I'll tell you > tomorrow if I have something. > > > many thanks for your time, > > mojmir > > Your welcome. > > Best regards, > Eus
Re: Failure building GFortran (Cygwin)
Oops, I have discovered this, in libiberty/ChangeLog
2008-06-19 Eric Blake <[EMAIL PROTECTED]>
Adjust strsignal to POSIX 200x prototype.
* strsignal.c (strsignal): Remove const.
Cheers,
Angelo.
Paul Richard Thomas ha scritto:
Angelo,
I have seen this too - I thought that it was due to the VERY strange
way in which I was doing the build:-)
Andd 'const' to strsignal.c:408 and the build will go through.
Paul
On Sat, Jun 28, 2008 at 2:09 PM, Angelo Graziosi
<[EMAIL PROTECTED]> wrote:
Last week I flagged some problems with 4.4-20080620 snapshot [1], now the
current snapshot fails in a different manner:
[...]
make[2]: Entering directory `/work/build'
make[3]: Entering directory `/work/build'
rm -f stage_current
make[3]: Leaving directory `/work/build'
Comparing stages 2 and 3
warning: ./cc1-checksum.o differs
Comparison successful.
if false; then \
rm -rf stage2-*; \
echo timestamp > stage2-lean; \
fi
[...]
make[4]: Leaving directory `/work/build/i686-pc-cygwin/libgfortran'
make[3]: Leaving directory `/work/build/i686-pc-cygwin/libgfortran'
make[2]: Leaving directory `/work/build/i686-pc-cygwin/libgfortran'
Checking multilib configuration for libiberty...
mkdir -p -- i686-pc-cygwin/libiberty
Configuring in i686-pc-cygwin/libiberty
[...]
/work/build/./gcc/xgcc -B/work/build/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2
-I. -I/work/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic /work/gcc/libiberty/strerror.c -o strerror.o
if [ x"" != x ]; then \
/work/build/./gcc/xgcc -B/work/build/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2
-I. -I/work/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic /work/gcc/libiberty/strsignal.c -o
pic/strsignal.o; \
else true; fi
/work/build/./gcc/xgcc -B/work/build/./gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/
-B/usr/local/gfortran/i686-pc-cygwin/lib/ -isystem
/usr/local/gfortran/i686-pc-cygwin/include -isystem
/usr/local/gfortran/i686-pc-cygwin/sys-include -c -DHAVE_CONFIG_H -g -O2
-I. -I/work/gcc/libiberty/../include -W -Wall -Wwrite-strings -Wc++-compat
-Wstrict-prototypes -pedantic /work/gcc/libiberty/strsignal.c -o strsignal.o
/work/gcc/libiberty/strsignal.c:408: error: conflicting types for
'strsignal'
/usr/include/string.h:78: error: previous declaration of 'strsignal' was
here
make[2]: *** [strsignal.o] Error 1
make[2]: Leaving directory `/work/build/i686-pc-cygwin/libiberty'
make[1]: *** [all-target-libiberty] Error 2
make[1]: Leaving directory `/work/build'
make: *** [all] Error 2
The above happens on Cygwin, using gcc-core, gcc-fortran tarballs and
configuring
${gcc_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}" \
--infodir="${info_dir}" \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-decimal-float=bid \
--enable-libgomp \
--enable-threads \
--enable-sjlj-exceptions \
--enable-version-specific-runtime-libs \
--enable-nls \
--enable-checking=release \
--disable-fixed-point \
--disable-libmudflap \
--disable-shared \
--disable-win32-registry \
--with-system-zlib \
--without-included-gettext \
--without-x
Cheers,
Angelo.
---
[1] http://gcc.gnu.org/ml/fortran/2008-06/msg00250.html
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
I had the same problem on my PowerPC Linux machine and the workaround I'm using now is to run make with the additional flag STAGE1_CFLAGS=-O. The problem (thanks to Andreas Schwab and Michael Matz for help) is that .glink and .text is too far away from each other (> 32 MB in the non-optimized case) and therefore building of e.g. cc1-dummy fails. Adding -Wl,--relax to the cc1-dummy build helped for that binary but I found no way to get this properly into the Makefiles (and make LDFLAGS="-Wl,--relax" gave an error in configure later on), Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126 pgpJksHtS5xPs.pgp Description: PGP signature
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
> Andreas Jaeger writes: Andreas> I had the same problem on my PowerPC Linux machine and the workaround Andreas> I'm using now is to run make with the additional flag STAGE1_CFLAGS=3D-O. Andreas> The problem (thanks to Andreas Schwab and Michael Matz for help) is that Andreas> .glink and .text is too far away from each other (> 32 MB in the Andreas> non-optimized case) and therefore building of e.g. cc1-dummy fails. Andreas> Adding -Wl,--relax to the cc1-dummy build helped for that binary but I Andreas> found no way to get this properly into the Makefiles (and make Andreas> LDFLAGS=3D"-Wl,--relax" gave an error in configure later on), Can you add cc1-dummy$(exeext) : override LDFLAGS += -Wl,--relax to an appropriate tmake_file in gcc/config/rs6000 ? David
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
David Edelsohn <[EMAIL PROTECTED]> writes: >> Andreas Jaeger writes: > > Andreas> I had the same problem on my PowerPC Linux machine and the workaround > Andreas> I'm using now is to run make with the additional flag > STAGE1_CFLAGS=3D-O. > Andreas> The problem (thanks to Andreas Schwab and Michael Matz for help) is > that > Andreas> .glink and .text is too far away from each other (> 32 MB in the > Andreas> non-optimized case) and therefore building of e.g. cc1-dummy fails. > Andreas> Adding -Wl,--relax to the cc1-dummy build helped for that binary but > I > Andreas> found no way to get this properly into the Makefiles (and make > Andreas> LDFLAGS=3D"-Wl,--relax" gave an error in configure later on), > > Can you add > > cc1-dummy$(exeext) : override LDFLAGS += -Wl,--relax > > to an appropriate tmake_file in gcc/config/rs6000 ? It should be put in a host_xmake_file fragment. Andreas. -- Andreas Schwab, SuSE Labs, [EMAIL PROTECTED] SuSE Linux Products GmbH, Maxfeldstraße 5, 90409 Nürnberg, Germany PGP key fingerprint = 58CA 54C7 6D53 942B 1756 01D3 44D5 214B 8276 4ED5 "And now for something completely different."
RE: Failure building GFortran (Cygwin)
Angelo Graziosi wrote on 29 June 2008 11:38: > Oops, I have discovered this, in libiberty/ChangeLog > > 2008-06-19 Eric Blake <[EMAIL PROTECTED]> > > Adjust strsignal to POSIX 200x prototype. > * strsignal.c (strsignal): Remove const. You may need to build and install cygwin from CVS[*] to get the corresponding newlib fix and install it into your system headers in /usr/include. Or you could patch your /usr/include/string.h locally. See http://sourceware.org/ml/newlib/2008/msg00342.html for the other half of Eric's patch. cheers, DaveK [*] - You may not want to do that because of the 1.5 -> 1.7 WIP, in which case you could rebuild your current DLL from its source package and backport the patch linked above. -- Can't think of a witty .sigline today
Re: Failure building GFortran (Cygwin)
The point isn't that to find workarounds. The point is, so as stand the things, unless a new Cygwin 1.5.25-16 (or 1.5.26-1 ?), the build of GFortran-trunk and friends is *officially* broken for cygwin-users. Thanks, Angelo. Dave Korn ha scritto: Angelo Graziosi wrote on 29 June 2008 11:38: Oops, I have discovered this, in libiberty/ChangeLog 2008-06-19 Eric Blake <[EMAIL PROTECTED]> Adjust strsignal to POSIX 200x prototype. * strsignal.c (strsignal): Remove const. You may need to build and install cygwin from CVS[*] to get the corresponding newlib fix and install it into your system headers in /usr/include. Or you could patch your /usr/include/string.h locally. See http://sourceware.org/ml/newlib/2008/msg00342.html for the other half of Eric's patch. cheers, DaveK [*] - You may not want to do that because of the 1.5 -> 1.7 WIP, in which case you could rebuild your current DLL from its source package and backport the patch linked above.
Re: Failure building GFortran (Cygwin)
CC'ed to Eric. This may require some configury patches somewhere. Ian Angelo Graziosi <[EMAIL PROTECTED]> writes: > The point isn't that to find workarounds. > > The point is, so as stand the things, unless a new Cygwin 1.5.25-16 > (or 1.5.26-1 ?), the build of GFortran-trunk and friends is > *officially* broken for cygwin-users. > > > Thanks, >Angelo. > > > Dave Korn ha scritto: >> Angelo Graziosi wrote on 29 June 2008 11:38: >> >>> Oops, I have discovered this, in libiberty/ChangeLog >>> >>> 2008-06-19 Eric Blake <[EMAIL PROTECTED]> >>> >>> Adjust strsignal to POSIX 200x prototype. >>> * strsignal.c (strsignal): Remove const. >> >> You may need to build and install cygwin from CVS[*] to get the >> corresponding newlib fix and install it into your system headers in >> /usr/include. Or you could patch your /usr/include/string.h locally. See >> >> http://sourceware.org/ml/newlib/2008/msg00342.html >> >> for the other half of Eric's patch. >> >> cheers, >> DaveK >> >> [*] - You may not want to do that because of the 1.5 -> 1.7 WIP, in which >> case you could rebuild your current DLL from its source package and backport >> the patch linked above.
Re: Failure building GFortran (Cygwin)
Ian Lance Taylor wrote: CC'ed to Eric. This may require some configury patches somewhere. Ian Angelo Graziosi <[EMAIL PROTECTED]> writes: The point isn't that to find workarounds. The point is, so as stand the things, unless a new Cygwin 1.5.25-16 (or 1.5.26-1 ?), the build of GFortran-trunk and friends is *officially* broken for cygwin-users. Thanks, Angelo. Dave Korn ha scritto: Angelo Graziosi wrote on 29 June 2008 11:38: Oops, I have discovered this, in libiberty/ChangeLog 2008-06-19 Eric Blake <[EMAIL PROTECTED]> Adjust strsignal to POSIX 200x prototype. * strsignal.c (strsignal): Remove const. You may need to build and install cygwin from CVS[*] to get the corresponding newlib fix and install it into your system headers in /usr/include. Or you could patch your /usr/include/string.h locally. See http://sourceware.org/ml/newlib/2008/msg00342.html for the other half of Eric's patch. cheers, DaveK [*] - You may not want to do that because of the 1.5 -> 1.7 WIP, in which case you could rebuild your current DLL from its source package and backport the patch linked above. A PR should be opened for this. Has that been done? Is it marked as a regression and as a blocker? Who has responsibility to fix this? Regards, Jerry
salut
Consultez ou Ajoutez GRATUITEMENT et FACILEMENT des annonces immobilières! http://www.LouerVendreAuMaroc.com Portail numéro 1 de l'immobilier au maroc -- Si vous ne voulez pas recevoir nos newsletters,http://canada-design.com/news/?p=unsubscribe&uid=73d1638bdff413326ac97786a62bb89a Envoyer ce message � quelqu'un http://canada-design.com/news/?p=forward&uid=73d1638bdff413326ac97786a62bb89a&mid=34 -- Powered by PHPlist, www.phplist.com --
salut
Consultez ou Ajoutez GRATUITEMENT et FACILEMENT des annonces immobilières! http://www.LouerVendreAuMaroc.com Portail numéro 1 de l'immobilier au maroc -- Si vous ne voulez pas recevoir nos newsletters,http://canada-design.com/news/?p=unsubscribe&uid=30ea6f685c5e573d3806a965b60a663a Envoyer ce message � quelqu'un http://canada-design.com/news/?p=forward&uid=30ea6f685c5e573d3806a965b60a663a&mid=34 -- Powered by PHPlist, www.phplist.com --
RE: how can I contribute ?
Please send me the paper also, I am also willing to contribute. I am right now,going through whole of gcc wiki. Regards, Dinesh Gurumurthy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Edelsohn Sent: Thursday, June 26, 2008 4:23 AM To: Fabien CHÊNE Cc: Diego Novillo; gcc@gcc.gnu.org Subject: Re: how can I contribute ? I will send it privately. David NOTICE: If received in error, please destroy and notify sender. Sender does not intend to waive confidentiality or privilege. Use of this email is prohibited when received in error.
Re: Linking very large application with GCC trunk on powerpc-linux leads to relocation error of crtbegin/end.o
On Sun, Jun 29, 2008 at 03:08:43PM +0200, Andreas Schwab wrote: > David Edelsohn <[EMAIL PROTECTED]> writes: > > >> Andreas Jaeger writes: > > > > Andreas> I had the same problem on my PowerPC Linux machine and the > > workaround > > Andreas> I'm using now is to run make with the additional flag > > STAGE1_CFLAGS=3D-O. > > Andreas> The problem (thanks to Andreas Schwab and Michael Matz for help) > > is that > > Andreas> .glink and .text is too far away from each other (> 32 MB in the > > Andreas> non-optimized case) and therefore building of e.g. cc1-dummy fails. > > Andreas> Adding -Wl,--relax to the cc1-dummy build helped for that binary > > but I > > Andreas> found no way to get this properly into the Makefiles (and make > > Andreas> LDFLAGS=3D"-Wl,--relax" gave an error in configure later on), > > > > Can you add > > > > cc1-dummy$(exeext) : override LDFLAGS += -Wl,--relax > > > > to an appropriate tmake_file in gcc/config/rs6000 ? > > It should be put in a host_xmake_file fragment. I'm not a build machinery expert - if anybody has a patch, I'll happily test it, I'm building on Linux/Powerpc64. Adding the above line to rs6000/x-linux64 did not help me. Btw. we would need it for other files - like gnat1 - as well, Andreas -- Andreas Jaeger, Director Platform / openSUSE, [EMAIL PROTECTED] SUSE LINUX Products GmbH, GF: Markus Rex, HRB 16746 (AG Nürnberg) Maxfeldstr. 5, 90409 Nürnberg, Germany GPG fingerprint = 93A3 365E CE47 B889 DF7F FED1 389A 563C C272 A126
