Dear All,
I have found a build problem with an application which I have reduced to the
following test case:
$ cat foomain.cc
//
// g++ foomain.cc foo01.cc foo02.cc -o foo.out
//
// g++ -c foomain.cc
// g++ -c foo01.cc
// g++ -c foo02.cc
//
// g++ foomain.o foo01.o foo02.o -o foo.out
//
int main(
Usually I do weekly builds of GCC snapshots on Cygwin, but current
snapshot (http://gcc.gnu.org/ml/gcc/2013-04/msg00091.html) fails with:
...
g++ -c -DIN_GCC_FRONTEND -DIN_GCC_FRONTEND -g -DIN_GCC
-fno-exceptions -fno-rtti -fasynchronous-unwind-tables -W -Wall
-Wwrite-strings -Wcast-qual-DHA
The current snapshot [*] fails to build on Cygwin as follow:
[...]
/work/gcc-4.9-20130414/Work/./gcc/xgcc
-B/work/gcc-4.9-20130414/Work/./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
Il 16/04/2013 10.10, Dave Korn ha scritto:
On 15/04/2013 15:50, Angelo Graziosi wrote:
The current snapshot [*] fails to build on Cygwin as follow:
/work/gcc-4.9-20130414/libgcc/config/i386/cygming-crtbegin.c:120:1:
error: unrecognizable insn:
}
^
(insn 15 14 16 5 (set (reg:SI 63
Il 22/04/2013 15.03, Dave Korn ha scritto:
On 22/04/2013 13:51, Angelo Graziosi wrote:
Il 16/04/2013 10.10, Dave Korn ha scritto:
This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
From comment 5 and 9 something should be fixed but with current
snapshot, 4.9-20130421, it
Il 22/04/2013 15.13, Angelo Graziosi ha scritto:
Il 22/04/2013 15.03, Dave Korn ha scritto:
On 22/04/2013 13:51, Angelo Graziosi wrote:
Il 16/04/2013 10.10, Dave Korn ha scritto:
This is now http://gcc.gnu.org/bugzilla/show_bug.cgi?id=56975
From comment 5 and 9 something should be
For the sake of completeness...
Bootstrapping trunk r199624 fails on Cygwin as follows:
$ /work/gcc-trunk-r199624/configure --prefix=/usr/local/gfortran
--program-suffix=-4.9 --enable-languages=c,c++,fortran
--enable-checking=release --enable-threads=posix --enable-libgomp
--enable-bootstrap
right fix...
I would be grateful if someone could take care of this.
TIA,
Angelo.
Il 04/06/2013 0.07, Angelo Graziosi ha scritto:
For the sake of completeness...
Bootstrapping trunk r199624 fails on Cygwin as follows:
$ /work/gcc-trunk-r199624/configure --prefix=/usr/local/gfortran
--pr
Arjen Markus wrote:
I am trying to compile GCC 4.8.1 under Cygwin.
../.././gcc/ada/gcc-interface/Make-lang.in:677: *** target pattern
contains no `%'. Stop.
make[3]: Leaving directory
`/cygdrive/d/gcc-src/gcc-4.8.1/host-i686-pc-cygwin/gcc'
Makefile:4160: recipe for target `all-stage1-gcc' failed
Ciao Arjen,
Il 19/06/2013 21.01, Arjen Markus ha scritto:
As for the build experiment itself:
- I downloaded the 4.8.1 source
- I configured the Makefiles with this command:
./configure --prefix=d:/gcc-src/gcc
Hmm... Cygwin doesn't like the path in the DOS style, "d:/...". At least
it shou
Il 20/06/2013 12.00, Arjen Markus ha scritto:
So, I tried again. The problem I reported before has gone, but I still
get a file permission problem later on.
I have not been able to solve it, even though my laptop is now
connected to the domain, I have instructed
the build process to use my home
Hi Arjen,
Il 20/06/2013 21.41, Arjen Markus ha scritto:
I found a reference to this sort of problems in the Cygwin FAQs, but
this turned out to be a dead-end too.
So I thought, I'd try MinGW/MSYS instead.
It started off fairly well, however:
- For some reason the gcc compiler did not like the
Il 21/06/2013 16.06, Arjen Markus ha scritto:
Hi Angelo,
well, after a somewhat bumpy start on the Cygwin list, I did get the
information I needed.
It turned out that the directories and files I had created under
Windows had the permission 000 according to Cygwin, but I could still
read the file
I want to flag the failure in bootstrapping gfortran-4.4.0-20080425 [1],
observed on Cygwin.
---
[...]
# Now that we have built all the objects, we need to copy
# them back to the GCC directory. Too many things (other
# in-tree libraries, and DejaGNU) know about
FX ha scritto:
Cygwin native built gfortran 4.4 was already broken, even when it was
making it through bootstrap and testsuite. All comments I've received
told me I was wasting my time with it.
Where is that bug reported? cygwin is secondary target, I think it
should really be unbroken, with
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
Paul Richard Thomas ha scritto:
Andd 'const' to strsignal.c:408 and the build will go through.
Paul,
thanks for suggestions. Now it builds fine...
But... have you seen the warnings like this:
[...]
/work/build/./prev-gcc/xgcc -B/work/build/./prev-gcc/
-B/usr/local/gfortran/i686-pc-cygwin
hought 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
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
n C++'?
Isn't xgcc a C compiler?
I am enabling only C,Fortran!
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 b
Dave Korn ha scritto:
Angelo Graziosi wrote on 05 July 2008 12:16:
For the sake of completeness I want to flag that the current snapshot
4.4-20080704 has new failures:
/work/gcc/gcc/ggc-page.c -o ggc-page.o
cc1: warnings being treated as errors
/work/gcc/gcc/ggc-page.c: In function
Ian Lance Taylor wrote:
It's valid, but it's not the right patch. The right patch is to use
XNEW and XCNEW from include/libiberty.h.
Gabriel Dos Reis in [1] wrote:
> The idiom is to use XCNEWVAR(T) for xcalloc(1, sizeof(T)),
> XNEWVAR(T) for xmalloc(sizeof(T)),...
Gulp! I am a little confu
Ian Lance Taylor ha scritto:
Angelo Graziosi <[EMAIL PROTECTED]> writes:
Ian Lance Taylor wrote:
It's valid, but it's not the right patch. The right patch is to use
XNEW and XCNEW from include/libiberty.h.
Gabriel Dos Reis in [1] wrote:
The idiom is to use XCNEWVAR(
--disable-shared \
--disable-win32-registry \
--with-system-zlib \
--without-included-gettext \
--without-x
=======
gcc/ChangeLog:
2
Gabriel Dos Reis ha scritto:
On Tue, Jul 8, 2008 at 3:48 AM, Angelo Graziosi
<> wrote:
Ian Lance Taylor ha scritto:
This is OK, with a ChangeLog entry, if it passes bootstrap with the
appropriate configure option.
The following bootstraps rev. 137613, having configured as
${g
Eric Blake ha scritto:
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
According to Jerry DeLisle on 6/29/2008 11:45 AM:
| Ian Lance Taylor wrote:
|> CC'ed to Eric. This may require some configury patches somewhere.
|>
| Adjust strsignal to POSIX 200x prototype.
| * strsignal.c (s
I have seen that when I build, on Cygwin (1.5), configuring as:
--
${gcc_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
-
Trying to build gcc-4.5-20090723 on Cygwin 1.5, configuring with:
${gcc_dir}/configure --prefix="${prefix_dir}" \
--exec-prefix="${eprefix_dir}" \
--sysconfdir="${sysconf_dir}" \
--libdir="${lib_dir}" \
--libexecdir="${libexec_dir}" \
--mandir="${man_dir}"
Ian Lance Taylor ha scritto:
Angelo Graziosi writes:
What it the best? DPD or BID?
You neglected to mention which version of gcc you are building. The
decimal float support is relatively new.
Oops... it is the most updated for 4.3, 4.4 and 4.5
If you are using an x86 processor, as
heir names, like libstdc++*-gdb.py,
allowed on Cygwin?
Cheers,
Angelo.
---
[1] http://gcc.gnu.org/ml/gcc/2009-07/msg00443.html
Angelo Graziosi ha scritto:
Trying to build gcc-4.5-20090723 on Cygwin 1.5, configuring with:
${gcc_dir}/configure --prefix="${prefix_dir}" \
Dave Korn ha scritto:
Angelo Graziosi wrote:
...are the files with an '*' in their names, like libstdc++*-gdb.py,
allowed on Cygwin?
No, it's a glob match, the makefile expects there to be something to match
that pattern but there isn't so the shell returns it verbatim
Ralf Wildenhues ha scritto:
* Angelo Graziosi wrote on Sun, Jul 26, 2009 at 09:59:35AM CEST:
Dave Korn ha scritto:
Angelo Graziosi wrote:
...are the files with an '*' in their names, like libstdc++*-gdb.py,
allowed on Cygwin?
No, it's a glob match, the makefile expe
Ralf Wildenhues ha scritto:
* Tom Tromey wrote on Mon, Jul 27, 2009 at 06:03:54PM CEST:
"Ralf" == Ralf Wildenhues writes:
Ralf> OK to install this trivial patch if it passes the build I'm running
Ralf> right now, as well as a normal and a DESTDIR install I'll be doing
Ralf> afterwards?
I th
Dave Korn wrote:
Bootstrap failure on Cygwin:
/gnu/gcc/releases/4.3.4/gcc-4.3.4-RC-20090727/host-i686-pc-cygwin/gcc/xgcc -B/gn
u/gcc/releases/4.3.4/gcc-4.3.4-RC-20090727/host-i686-pc-cygwin/gcc/ -B/opt/gcc-t
ools/i686-pc-cygwin/bin/ -B/opt/gcc-tools/i686-pc-cygwin/lib/ -isystem /opt/gcc-
tools
To have multiple versions of GCC installed, I usually build, on Cygwin,
configuring as:
prefix_dir_name="usr/local/gfortran"
prefix_dir="/${prefix_dir_name}"
dataroot_dir="${prefix_dir}/share"
eprefix_dir="${prefix_dir}"
sysconf_dir="${prefix_dir}/etc"
lib_dir="${eprefix_dir}/lib"
libexec_dir="
Ian Lance Taylor ha scritto:
Angelo Graziosi writes:
Is there a way to send libiberty.a where go the other libs (i.e
/usr/local/gfortran/lib/gcc/i686-pc-cygwin/4.4.1/, for example)?
Really libiberty should not be installed at all by default.
I suspected that. :-)
Why, then, 'make in
Eric Niebler wrote:
I am running into the same problem (cannnot build latest snapshot on cygwin). I
have built and installed the latest binutils from head (see attached config.log
for details). But still the build fails. Any help?
This is strange! Recent snapshots (4.3, 4.4, 4.5) build OB bot
At least on Cygwin (1.7), the current GCC snapshot (20090917) fails to
build:
[...]
/tmp/build/./gcc/xgcc -B/tmp/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/i
Allan McRae ha scritto:
Angelo Graziosi wrote:
At least on Cygwin (1.7), the current GCC snapshot (20090917) fails to
Seems to be the same as http://gcc.gnu.org/bugzilla/show_bug.cgi?id=41395
Allan
Indeed!
Thanks,
Angelo.
Dave Korn wrote:
A phase of development when we stop adding new code and merging new features
for a while and go into bug-fix only mode to let trunk stabilise when there
are significant numbers of high-impact open PRs impeding the smooth progress
of development.
+1
Cheers,
Angelo.
Dave Korn wrote:
> Patch prepared, I'll finish writing it up and submit to the newlib list
> later tonight, but first I'm going to have a celebratory beer or two on
> the way home...
I have applied the patch
(http://sourceware.org/ml/newlib/2007/msg00292.html) an GCC-4.3
(core+gfortran) builds (
Aaron Gray wrote:
> Successfully built latest gcc on Win XP SP2 with cvs built cygwin.
CVS Cygwin contains CVS newlib, i.e. already the patched version of
sdtdio.h, so if you use cvs built cygwin you should not patch anything.
To build GCC 4.3, you should simply move the new stdio.h on /usr/in
On Tue, 1 May 2007, Aaron Gray wrote:
> >> You can also use the current Cygwin snapshot which comes with the new
> >> stdio.h.
> >
> > Great, where do I get Cygwin snapshots ?
>
Here:
http://cygwin.com/snapshots/
The snapshots should be installed following this:
http://cygwin.com/faq
I have build GFortran under Cygwin configuring with:
./configure --prefix=${prefix_dir} \
--enable-languages=c,fortran \
--enable-bootstrap \
--enable-libgomp \
--enable-threads \
On Wed, 4 Jul 2007, Brian Dessent wrote:
> Angelo Graziosi wrote:
>
> > ./configure --prefix=${prefix_dir} \
>
> According to the documentation you should not do this (build in the same
> dir as the source.)
Obviously I forgot to say:
cd ${build_
I want to flag that some changes in GCC 4.3.0 20070816 rev 127568:
* Makefile.in (REVISION): New.
(REVISION_c): New.
(REVISION_s): New.
(version.o): Also depend on $(REVISION). Add
-DREVISION=$(REVISION_s).
* version.c (version_string): Add REVISIO
With GFortran 4.3.0-20070821 trunk-127680 there is this warning:
[ -f stage_final ] || echo stage3 > stage_final
make[1]: Entering directory `/tmp/gcc/build'
make[2]: Entering directory `/tmp/gcc/build'
make[2]: Leaving directory `/tmp/gcc/build'
make[2]: Entering directory `/tmp/gcc/build'
Conf
The current snapshot 4.5-20090507 fails to bootstrap on Cygwin:
[...]
/tmp/build/./prev-gcc/xgcc -B/tmp/build/./prev-gcc/
-B/usr/local/gfortran/i686-pc-cygwin/bin/ -c -g -O2 -DIN_GCC -W -Wall
-Wwrite-strings -Wstrict-prototypes -Wmissing-prototypes
I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:
---
[...]
make[2]: Entering directory `/tmp/build'
Configuring stage 2 in ./intl
Configuring stage 2 in ./libiberty
Configuring stage 2 in ./l
Dave Korn ha scritto:
Angelo Graziosi wrote:
I want to flag the following failure I have seen on Cygwin 1.5 trying to
build current 4.5-20090625 gcc snapshot:
So what's in config.log? And what binutils are you using?
The config logs are attached, while binutils is the current in
C
Steve Kargl ha scritto:
Can you guys learn to trim the cc list? This issue
has absoutely nothing to do with gfortran. Yet,
for...@gcc.gnu.org is being spammed with your email.
Really... it was discovered because someone has the 'bad' habit to build
gfortran... :-)
Have a nice day.
An
Testing the mingw64-i686* packages found at
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW (Cygwin cross
compiler, see[*]), I have obtained an ICE:
$ cat ICE_test.cpp
void foo(char const* upattern, int color)
{
static short bitmap_data[8];
for (int i = 0; i < 8; i++)
{
bitmap_da
Il 10/09/2010 19.31, Steve Kargl ha scritto:
The ideal solution would be incorporating libquad into libgfortran
The ideal solution would be building GCC enabling QP with
./configure... --enable-quad
if the system allow for QP: in this case, perhaps, QP should be enabled
by default.
Cia
Il 11/09/2010 1.42, Steve Kargl ha scritto:
On Sat, Sep 11, 2010 at 01:05:23AM +0200, Angelo Graziosi wrote:
Il 10/09/2010 19.31, Steve Kargl ha scritto:
The ideal solution would be incorporating libquad into libgfortran
The ideal solution would be building GCC enabling QP with
./configure
Il 10/10/2010 15.31, NightStrike ha scritto:
On Thu, Sep 16, 2010 at 12:54 PM, JonY wrote:
On 7/16/2010 08:46, Yaakov (Cygwin/X) wrote:
On Fri, 2010-07-16 at 02:06 +0200, Angelo Graziosi wrote:
Testing the mingw64-i686* packages found at
ftp://ftp.cygwinports.org/pub/cygwinports/temp/MinGW
Trying to bootstrap rev. 166873, on Cygwin, configuring with:
/tmp/gcc-4.6-r166873/configure --prefix=/usr/local/gfortran
--program-suffix=-4.6 --enable-languages=c,c++,fortran
--enable-checking=release --enable-threads=posix --enable-libgomp
--disable-bootstrap --disable-libmudflap --disable-
Il 17/11/2010 21.06, Tobias Burnus ha scritto:
Why does everyone think that I and Fortran have something to do with it
if something breaks?* ;-)
The issue is known and a fix, which seemingly works on Darwin, exists.
See: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=46510
Angelo Graziosi wrote
Current trunk, rev. 169888, fails to bootstrap on Cygwin with this error:
[...]
/tmp/gcc-4.6-r169888/libgcc/config/libbid/bid_decimal_globals.c:47:18:
fatal error: fenv.h: No such file or directory
compilation terminated.
make[2]: *** [bid_decimal_globals.o] Error 1
make[2]: *** Waiting for unf
Il 07/02/2011 19.48, Charles Wilson ha scritto:
On 2/7/2011 1:41 PM, Angelo Graziosi wrote:
Current trunk, rev. 169888, fails to bootstrap on Cygwin with this error:
[...]
/tmp/gcc-4.6-r169888/libgcc/config/libbid/bid_decimal_globals.c:47:18:
fatal error: fenv.h: No such file or directory
59 matches
Mail list logo
