Goswin von Brederlow wrote:
In Foo the variable is just uninitialized, in Bar it is definetly used
uninitialized and in Baz it might be used uninitialized. Is there any
-W switch to make g++ detect such errors or is that a shortcomming of
-Wuninitialized?
Your example is just not what
Amker.Cheng wrote:
Here the destination directory is $(DESTDIR)$(libexecsubdir)/, but
where is DESTDIR defined?
I did not find any definition of this variable in both toplevel and
gcc's makefile.
It's intentionally not defined anywhere as it's expected to remain unset
unless the user
Andy Scott wrote:
Looking over the bugzilla data base and archives of this (and other)
lists I was wondering about the level of support there is for GCC on
Cygwin. (I realise that it is weird half-way house to many people and
so does get a fair amount of abuse from both the Windoze
Paul Brook wrote:
If you really want to solve this then you could always stop using PE/COFF.
The ARM EABI (and in particular the arm-none-symbianelf target) demonstrates
how this can be done. Basically the toolchain generates ELF objects,
executables and DSOs, then you feed them through a
Tim Prince wrote:
bootstrap failures are due to a broken #ifdef specific to cygwin in the
headers provided with cygwin,
If you mean the strsignal change in libiberty, that's been fixed in CVS
for a long time.
the requirement for a specific version of
autoconf (not available in setup),
You
Andrew Haley wrote:
So do that, then. Where's the problem?
I suppose it's not a problem if the alternative is no plugin support at
all. It just seems a little ugly for the plugin author to have to
distribute 'n' trivially different but substantially identical copies of
their plugin binary for
Joseph S. Myers wrote:
As I understand it, there is an alternative - put all the shared code in a
DLL on Windows if configuring with plugins enabled, and link both the
plugins and cc1, cc1plus etc. with that DLL. If people wish to enable
The problem with that approach is that people have so
Nils Pipenbrinck wrote:
Cygwin comes with a GCC 3.4.somewhat out of the box. To compile MPFR you
need a 4.1 compiler. So you have to double compiling everything. And
I don't know where you get that assertion but it's not true. mpfr built
with gcc 3.4 works just fine and passes all tests in
drag chan wrote:
my question is why every constructor/destructor of class A have a
couple of same code blocks in the object file?
The ABI requires two separate versions of the ctor and dtor, one for
when the object being initialized is a base class and one where it's
not. Because you used -C
Simon Hill wrote:
http://gcc.gnu.org/onlinedocs/gccint/index.html. (Of course I was
horrified to see it's not written in C++, and it's loaded with macros
--- why??).
You seem to refer to g++ as if it's a separate program from gcc but it's
really not. All of the middle- and back-end code is
Ralf Wildenhues wrote:
* Windows (cygwin/mingw)
As i understand the issue (I am not very familiar with this) you can't
have unresolved references in a plugin back to the GCC executable. I.e.
Building GCC with -rdynamic will not work on this platform. Do we move
most of the GCC
Basile STARYNKEVITCH wrote:
(a meta question: do we need to reply-to all, or should the gcc@ list be
enough to discuss plugins, and the only destination of this interesting
discussion?).
Reply-to-all is the common standard on the list. If you don't want a
personal copy then set the Reply-to:
H.J. Lu wrote:
For Linux/x86, if gcc is configured for xxx-*-linux, the default arch should
be xxx for both 32bit and 64bit, where xxx can be i[3456]86, pentium, ...
x86-64. Is someone working on such a patch?
IMHO making this Linux specific just replaces one confusing and
arbitrary decision
Bo Yang wrote:
When we produce an exe from a single c++ file, there is no linking
need, so there is no problem. But when we separate the definition and
That's not how it works, the linker is always required to produce an
executable.
And Obviously, this is not a linker error, it is the
Benjamin Smedberg wrote:
For what it's worth, Bo is my intern in the Google SoC and has traced this
back to being a code-generation error (missed stdcall mangling) in the mingw
backend. I will work with him to narrow the problem and reformulate the
question..
Isn't this
Denys Vlasenko wrote:
(Is it necessary to do this /../../../../ thing?)
A useful trick to make this easier for a human to read is to pipe the
output through
sed -e :a -e s,[^/]*/\.\.\/,, -e ta
I don't guarantee that this will always result in the correct semantics
in all situations but it's
Denys Vlasenko wrote:
Only in my case, $prefix contain neither as nor ld. gcc lives in
Okay, so prepend /usr/app/binutils-2.18-x86_64-linux-uclibc/bin to PATH
and gcc will find and use x86_64-linux-uclibc-{as,ld} without any of
--with-{as,ld}.
it's much better for sanity that way.
I would
Michael Eager wrote:
I've noticed a problem with the patch:
if test ${with_newlib+set} = set; then
AC_LIBTOOL_DLOPEN
fi
The test always succeeds. When $with_newlib is yes,
${with_newlib+set} is set.
If I change this to the old style test
if test x$with_newlib = x; then
NightStrike wrote:
What exactly is the downside to upgrading the license? I'm not
familiar with the implications of doing so.
As I understand it, the concern is that many distros use the 4.1 branch
as the base for their main gcc system compiler. If suddenly the branch
gets upgraded to GPLv3
Hans Kester wrote:
I searched for this error and found:
http://gcc.gnu.org/ml/gcc/2007-09/msg00421.html
Wasn't this patched? How do I fix this?
It wasn't actually fixed. That was a very long thread and it's easy to
get confused, particularly since the mailing list archives don't
crossthread
Weddington, Eric wrote:
This is a very old issue. MinGW/MSYS does not support links. The easiest
way around this is to just copy the file.
But MSYS's 'ln -s' command makes copies of files for exactly this
reason, so the question remains why it's necessary to hack it to be cp.
Brian
Weddington, Eric wrote:
You're definitely the expert on this. Has MSYS always done this? Or was
there an older version that didn't that the OP might be using?
I'm fairly sure it has been implemented like that since the beginning.
One possible reason why you might need to force cp to be used
Basile STARYNKEVITCH wrote:
I'm trying to understand how other plugin related effort deals with
this.
In an ideal world, you create a plugin API/ABI that is decoupled from
any of the internals of the main program and which has its own headers
and interface. Plugin authors simply code to that
Andreas Schwab wrote:
Typically in a multithreaded environment vfork is mapped to fork anyway.
...which is what I don't understand about this whole thread. It seems
Dave is seeing some strange behavior in Cygwin, but Cygwin's vfork =
fork, there is no difference. There used to be a vfork
Joerg Frochte wrote:
*** This configuration is not supported in the following subdirectories:
target-libmudflap target-libgomp target-libffi target-zlib
target-libjava t
arget-libada gnattools target-libstdc++-v3 target-libgfortran zlib
target-libobj
c target-boehm-gc
(Any other
Mohamed Shafi wrote:
I want to know whether its possible to run the gcc testsuite without
actually building the complier.
I have the dejagnu framework, compiler executables and i have the gcc
test suite. So is it possible to run the testsuite without building
the complier?
Use the
Angelo Graziosi wrote:
configure: WARNING: fixed-point is not supported for this target
^
checking whether make sets $(MAKE)... yes
...
This warning was absent with the bootstrap I did 20070819 trunk-127626.
That's because
Ling-hua Tseng wrote:
If I compile this file with g++ 4.2 by the following command:
g++ -c test.cxx
and then use this command to check symbol:
nm test.o
I cannot find the global varible `test' in symbol table:
This was an intentional change as part of the overhaul of C++ visibility
Danny Smith wrote:
Or
am I missing a more fundamental reason for the limited range of targets
supporting DFP?
Enabling it in gcc would just enable the compiler parts, but the decimal
float C extension proposed standard includes a lot more than that,
there's a whole checklist of stuff required
Angelo Graziosi wrote:
./configure --prefix=${prefix_dir} \
According to the documentation you should not do this (build in the same
dir as the source.)
A few months ago this did not happen (same building procedure).
The warning is correct because libdecnumber is only supported
michael.a wrote:
gcc version 4.0.3 (Ubuntu 4.0.3-1ubuntu5)
This belongs on gcc-help not here.
Debian-based distros use a 32/64 bit /usr/lib configuration that is
backwards from what the rest of the world uses and requires a patched
gcc to multilib correctly. You'll probably need to
[EMAIL PROTECTED] wrote:
Do you guys know if the problem with the access() standard library function
has
been worked around?
Windows vista has an updated MSVCRT.DLL which returns false for access() using
X_OK, this parameter was previously ignored, and returned true. MinGW / GCC
does not
Mark Mitchell wrote:
I'm disappointed to hear that MinGW made this change. As a MinGW user,
I don't want MinGW to interpose anything between me and the MSVCRT
libraries. I want MinGW to give me headers and import libraries for the
Microsoft DLLs, with all their warts; nothing more, nothing
Daniel Jacobowitz wrote:
The failing command is trying to compile the PCH. This means that
we're including a large number of libstdc++ headers in a row. One of
the first ones pulls in c++config.h, which has #undef max; but so far,
nothing has included windows.h. Later, something includes
Aaron Gray wrote:
I am getting errors on building Cygwin. It appears to be something to do
with the documentation.
Am I missing something simple such as a package like cygwin-doc and if so
where do I get it ?
Error text below...
Many thanks in advance,
[...]
Aaron Gray wrote:
JFTR, the patch is only required for building gcc, not for building
winsup.
As Brian says, we'll deal with any winsup problems on the cygwin list.
Sorry for adding to the confusion as I am actually trying to build GCC CVS
on Cygwin :)
Can you give me any
Aaron Gray wrote:
Thank you. I am a bit unsure of where abouts (what directory) do you install
the snapshot ?
Again, this has nothing to do with gcc, take it the Cygwin list. If you
are using the full snapshots (cygwin-inst-$date.tar.bz2) they should be
unpacked in the root (/). The other
Dave Korn wrote:
On 25 April 2007 18:55, Kaveh R. GHAZI wrote:
I'd like to work on using MPFR to handle builtin lgamma.
In what sense is it a builtin if it requires a library to be installed and
emits a call to a library function ??? I may not have understood what you're
trying to do
Tom Dickens wrote:
make CFLAGS='-O' LIBCFLAGS='-g -O2' LIBCXXFLAGS='-g -O2
-fno-implicit-templates' bootstrap
I don't know if 4.1.2 includes the toplevel bootstrap changes or not
(it's kind of old), but I don't think you should be doing make
bootstrap. The new method is to either configure
Jesper de Jong wrote:
/home/jesper/gcc-4.1.2/configure --enable-threads=win32
Where do people keep getting this idea that Cygwin uses win32 threads?
It doesn't, and you've most likely built a compiler that is subtly
broken in some way. Cygwin uses pthreads, this should be
Aaron W. LaFramboise wrote:
I don't really see any compelling reason that win32 threads shouldn't
work on Cygwin. As far as I know, nothing about this choice is
ultimately exposed to the user. In fact, Win32 threads are quite likely
to yield superior performance anywhere where it matters.
Tarmo Pikaro wrote:
Tried to compile gcc 4.1.1 (and .2) under windows / cygwin environment - and
end up with error:
This is more a question for gcc-help.
Used command lines:
$ ./configure
Christian Joensson wrote:
/usr/local/src/branch/objdir/gcc/gcj
-B/usr/local/src/branch/objdir/i686-pc-cygwin/libjava/
-B/usr/local/src/branch/objdir/gcc/ -ffloat-store -fomit-frame-pointer
-g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc
Kai Tietz wrote:
Ok, I will try for this. I have to find a different editor, which is not
too smart as to remove trailing whitespaces ...
Or just add -w to the diff options when generating the patch.
Brian
FX Coudert wrote:
There is effort to get that done, as you can see in the recent (few
days ago) thread starting here:
http://gcc.gnu.org/ml/gcc/2007-03/msg00293.html
Please feel free to step into this other discussion and help/give
advice about how achieve this goal.
Yeah, I've been
FX Coudert wrote:
I tried adding AC_LIBTOOL_WIN32_DLL to configure.ac (just before
AM_PROG_LIBTOOL) and -no-undefined to libgfortran_la_LDFLAGS, as is
indicated in the autobook and other online resources. but configure
(on a cross-compiler from i686-linux to i386-pc-mingw32) still says:
Did
Brooks Moses wrote:
Í just tried to build gcc-4.1.2 for cygwin... but failed. My old way
of test building does not seem to work anymore for me.
[...]
grep '^#' kinds.h kinds.inc
/bin/sh: kinds.h: No such file or directory
[...]
Any ideas of what might be going wrong?
A quick bit
[ adding gcc@ back to CC ]
Christian Joensson wrote:
for k in 4 8 10 16; do
echo real (kind=$k) :: x tmp$$.f90
echo end tmp$$.f90
/usr/local/src/branch/objdir/./gcc/gfortran \
-B/usr/local/src/branch/objdir/./gcc/ \
-B/usr/local/i686-pc-cygwin/bin/ \
Bob Rossi wrote:
Since i've used a prefix, I'm assumming gcc wants to be installed where
I told it to be. I'm wondering 2 things.
It's not supposed to be that way. The toolchain is supposed to be
relocatable for MinGW targets. I don't know if it currently is, but
read the past threads on the
Consider posting this kind of question to gcc-help@ instead.
[EMAIL PROTECTED] wrote:
I just ran these commands:
svn -q checkout svn://gcc.gnu.org/svn/gcc/trunk gcc
mkdir builddir
cd builddir
CFLAGS=-g ../gcc/configure --enable-languages=c,c++ --enable-checking \
--disable-bootstrap
Andrew Haley wrote:
That __thread variable is surrounded by HAVE_TLS. There is a
configure test which simply compiles this line:
__thread int foo;
and that configure test must succeed for HAVE_TLS to be set. So, to
fix this we need to find out if that program did compile, and if so,
Danny Smith wrote:
is a good thing: replace an ISO standard-conformant and perfectly
adequate atexit function already supplied by OS vendor with a new
version, perhaps with some licensing strings attached. I expect the
fake cxa_atexit hack I illustrated earlier would meet less resistance,
Ranjit Mathew wrote:
I just noticed that even with --disable-static --enable-static,
Do you mean --disable-static --enable-shared?
a Linux-to-MinGW cross compiler (mainline) still created static
libraries for the C++ and Java runtimes. Is this by design or is it
a bug? From the point of
Dave Murphy wrote:
[EMAIL PROTECTED] /e
$ gcc /usr/local/test/test.c -o /usr/local/test/test.exe
[EMAIL PROTECTED] /e
$ /usr/local/test/test.exe
E:\msys\local\test\test.exe
[EMAIL PROTECTED] /e
$
As you can see the paths are translated by the shell before being passed
to windows
Brian Dessent wrote:
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/i
nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H
-I. -I../.
./../../gcc-4_0
Bobby McNulty wrote:
I have been noticing the following error in trunk and in branch.
I get no such error when compiling the trunk.
/home/sherlock/gcc/o/gcc/xgcc -B/home/sherlock/gcc/o/gcc/
-B/usr/local/i686-pc-c
ygwin/bin/ -B/usr/local/i686-pc-cygwin/lib/ -isystem
bobby mcnulty wrote:
This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005
You're running into PR21766.
I hope it's not bad etiquette to ping a PR but I would greatly
appreciate it if someone could take a quick look at PR 22207 which has
gone for several months with no replies.
The problem involves bogus might be used uninitialized warnings in STL
headers, but only at -O2 and above. This makes
[EMAIL PROTECTED] wrote:
My compilation exited with the message :
Please read the documentation for ld's --enable-auto-import for details.
WHERE CAN I FIND INFORMATION ON THIS OPTION ?!!!
I could find anything on gcc or ld or -Wl related pages.
Did you even try looking in the ld
Gabriel Dos Reis wrote:
yes, if you spot any inconsistency I'm very happy to accept a patch
;-)
I noticed that on http://gcc.gnu.org/install/specific.html#windows it
states:
A port of GCC 2.95.2 and 3.x is included with the Cygwin environment.
However, the Cygwin project had to remove its
Gabriel Dos Reis wrote:
yes, if you spot any inconsistency I'm very happy to accept a patch
;-)
Also, the link GCC Frontend HOWTO on readings.html is 404 compliant.--- readings.html.orig 2005-05-29 11:23:38.405875000 -0700
+++ readings.html 2005-05-29 11:24:03.405875000 -0700
@@ -75,7
61 matches
Mail list logo
