Re: Where is DESTDIR got defined in gcc makefile?

"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 ov

Re: Error in -Wuninitialized? Should this be reported?

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 -Wu

Re: Cygwin support

"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

Re: Cygwin support

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

Re: Cygwin support

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), Y

Re: Cygwin support

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

Re: Cygwin support

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 & > L

Re: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

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

Re: about g++ compilation for class constructor/destructor

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

Re: Adding to G++: Adding a warning on throwing unspecified exceptions.

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

Re: Defining a common plugin machinery

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-

Re: Defining a common plugin machinery

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

Re: Recent libstdc++ regression on i686-linux: abi/cxx_runtime_only_linkage.cc

"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 deci

Re: gcj/sparc64?

Jay wrote: > /src/gcc/libjava/classpath/gnu/javax/swing/text/html/parser/HTML_401F.java:0: > in > ternal compiler error: Segmentation fault > Please submit a full bug report, > with preprocessed source if appropriate. > See for instructions. This stack exhaustion is PR36218 which was supposedly

Re: gcc emit wrong symbols in multiple inheritance case

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 prob

Re: gcc emit wrong symbols in multiple inheritance case

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

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

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 a

Re: Can't build correctly working crosscompiler with 4.3.0. 4.2.1 worked like charm

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

Re: Regenerating configure scripts

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_n

Re: gcc-4.1-20080303 is now available

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

Re: GCC 4.3 - Error: Link tests are not allowed after GCC_NO_EXECUTABLES

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 crossthrea

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

"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 use

Re: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

"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

Re: plugin includes for MELT

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 th

Re: libiberty/pex-unix vfork abuse?

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 spec

Re: gcc 4.2.2, libgomp under cygwin

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

Re: How to run testsuite without building a complier

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 co

Re: WARNING bootstrapping GFortran on Cygwin

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 becaus

Re: problem about generating data section in g++ 4.2

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

Re: RFC: Enabling DFP/libbid on dditional target (mingw32)

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 requir

Re: Decimal float and the Cygwin build of GFortran.

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

Re: I'm sorry, but this is unacceptable (union members and ctors)

"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 --disabl

Re: MinGW, GCC Vista,

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, nothi

Re: MinGW, GCC Vista,

[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

Re: Combined tree builds for mingw32

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 . Later, something includes > gthr-

Re: Successfull Build of gcc on Cygwin WinXp SP2

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 t

Re: Successfull Build of gcc on Cygwin WinXp SP2

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 an

Re: Cygwin build documentation error.

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, > [...] `/usr/build/cygw

Re: Accessing signgam from the middle-end for builtin lgamma

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 > tryin

Re: gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

Christian Joensson wrote: > on cygwin, with current gcc trunk, revision Tue Apr 24 20:47:06 UTC > 2007 (revision 124119M) (with Dave Korn's suggested patch to > libjava), I get a failure liike this: > > ranlib .libs/libgcj-tools.a > creating libgcj-tools.la > (cd .libs && rm -f libgcj-tools.la &

Re: Problem building gcc on Cygwin

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 configu

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

"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 matte

Re: Build report: Successful build of gcc 4.1.2 on Cygwin (Win XP Pro SP2)

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 --enable-threads

Re: Build report for gcc 4.1.1 on Cygwin

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 --prefix=/usr/lo

-fkeep-inline-functions and broken Cygwin bootstrap (was: Building GCC 4.3.0 on Cygwin...)

Dave Korn wrote: > # 405 "/usr/include/stdio.h" 3 4 [ Which is from newlib (libc/include/stdio.h) if anyone reading this doesn't have a Cygwin system handy. ] > static __inline__ int __sgetc_r(struct _reent *__ptr, FILE *__p) > { > [...] > > The critical difference is the presence or absence

Re: Can't bootstrap gcc 4.2 RC1 on cygwin: gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

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 > -L/usr/local/src/branch/obj

Re: Question for removing trailing whitespaces (not vertical tab) from source

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

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

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

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

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: D

Re: Cannot build gcc-4.1.2 on cygwin: /bin/sh: kinds.h: No such file or directory

[ 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/

Re: Cannot build gcc-4.1.2 on cygwin: /bin/sh: kinds.h: No such file or directory

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? >

Re: distributing g++

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 th

Re: build error

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-boot

Re: [cygwin] libjava/java/lang/natClass.cc:904: error: thread-local storage not supported for this target

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

Re: RFC: __cxa_atexit for mingw32

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

Re: Cross-compilation and Shared Libraries

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

Re: Crossed-Native Builds, Toolchain Relocation and MinGW

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 wi

Re: i686-pc-cygwin crash gcc-4.0 branch

Bobby McNulty wrote: > Since this is just staying on the cutting edge of programming, I am only > going to use release cygwin1.dll. > Waiting for cygwin 1.5.19 FYI, http://cygwin.com/ml/cygwin-cvs/2005-q4/msg00072.html

Re: i686-pc-cygwin crash gcc-4.0 branch

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-incl

Re: i686-pc-cygwin crash gcc-4.0 branch

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 > /usr/local/i686-pc-c

Re: warning on i686-pc-cygwin

bobby mcnulty wrote: > > This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005 You're running into PR21766.

pr 22207: Spurious 'might be used uninitialized' warnings

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 b

Re: Help on -Wl option

[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

Re: GCC 3.3.6 has been released

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,

Re: GCC 3.3.6 has been released

Gabriel Dos Reis wrote: > yes, if you spot any inconsistency I'm very happy to accept a patch > ;-) I noticed that on 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 i