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

[Brian Dessent]

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,
> how.

Might this have to do with
 which was
committed for a brief while and then subsequently reverted on
?  The
configure machinery in libjava might not be equipped to deal with this
kind of dependency and could require a "make clean".

> --disable-tls in the configure line might solve your problem.

That too.

Brian

Re: build error

[Brian Dessent]

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 --prefix=$PWD/../prefixdir
> make -s
> make install
> 
> and I got the attached compile error. Is this a known issue on an
> Althlon64 processor? Are there any work arounds?

I don't think it has anything to do with your processor, but the fact
that your build directory is a subdirectory of the source tree is
generally a no-no.  See .

Brian

Re: distributing g++

[Brian Dessent]

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 topic first:




Ranjit Mathew also has a web page somewhere describing what steps and/or
patches are necessary to get a relocatable toolchain.  But I think he
does a crossed-native (canadian) build for speed reasons, so that may
complicate the procedure.

> What are the standard practices with installing multiple versions of gcc
> on a system. I renamed this gcc to be gcc-4.1. However, it looks like it
> will still overwrite some files when I do 'make install'. Is this true?
> How do people put multiple version on the same machine?

The standard way on *nix systems is by installing them to separate
prefixes, or if using the same prefix, using --program-suffix (or
variants like --program-transform-name) and possibly
--enable-version-specific-runtime-libs.

> Second, say I wanted to tar up a release of gcc that i've built for
> others to use. When the other user downloads and untars the file on
> there filesystem in an arbitrary point, I'm assumming it won't work
> because it's not in the --prefix=.. directory. Is it possible to get
> around this? I would like a user to be able to untar it anywhere, and
> have it work just fine. If this is possible, please advise.

Again, if built right the toolchain is supposed to be relocatable, that
is it locates everything with relative paths to where the binaries are
installed.  You may have to configure it with the exact prefix
"--prefix=/mingw" for this to work, I am not sure.  And also note that
configuring a --prefix of an emulated POSIX path to a native (MinGW) app
will surely fail, you should use --prefix=`cd
/home/bobbybrasko/g++/prefixdir && pwd -W` instead if that is your goal.

Brian

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

[Brian Dessent]

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 of google-searching on "site:gcc.gnu.org kinds.h" turns up
> an email thread on the fortran@ list that refers to PR26893.  See:
>http://gcc.gnu.org/bugzilla/show_bug.cgi?id=26893
> 
> In short, from what I could tell from a quick scan of that PR, the
> problem is that you've got LD_LIBRARY_PATH set in such a way that it's
> not including the GMP header files.
> 
> If you're using the standard Cygwin-package installation of GMP, I'd
> guess this is because you haven't installed the "development" GMP
> package that includes the header files; since Cygwin puts that into a
> separate package, you need to install both.  (MPFR is the same way.)

I don't think that applies in the case of Cygwin, since Windows does not
know anything about LD_LIBRARY_PATH.  (Cygwin emulates it for dlopen()
but I don't think that's relevant here.)

I can say that I was able to successfully build and test the 4.1.2
20070129 (prerelease) version under Cygwin using the Cygwin-packaged
mpfr (2.2.1) and gmp (4.2.1) without any setting of LD_LIBRARY_PATH and
it passed all tests except for gfortran.dg/secnds.f which is a known
bug.  So unless the released 4.1.2 tarball differs from the RC1 tarball
in this area, it's something else and not a gmp/mpfr/libgfortran
problem.

In order to debug this, poster should run the faulting series of
commands and see what the errors are, i.e.:

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/
-B/usr/local/i686-pc-cygwin/lib/ -isystem
/usr/local/i686-pc-cygwin/include -isystem
/usr/local/i686-pc-cygwin/sys-include -I . -Wall -fno-repack-arrays
-fno-underscoring -c tmp$$.f90
done

Brian

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

[Brian Dessent]

[ 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/ \
> >-B/usr/local/i686-pc-cygwin/lib/ \
> >-isystem /usr/local/i686-pc-cygwin/include \
> >-isystem /usr/local/i686-pc-cygwin/sys-include \
> >-I . -Wall -fno-repack-arrays -fno-underscoring -c tmp$$.f90 || \
> >echo "exit status: $?"
> > done
> 
> exit status: 1
> exit status: 1
> exit status: 1
> exit status: 1

Well that is weird.  Exit status 1, yet no output on either stdout or
stderr?  Sounds broken.

> > If that says 128 then that means missing DLL; make sure you have
> > libgmp3, libmpfr0, and libmpfr1 packages installed.
> 
> well, running a cygcheck -s -v -r > cygcheck.out and then grepping for
> gmp and mpfr gives me this:
> 
> [EMAIL PROTECTED] /usr/local/src/branch/objdir
> $ grep gmp cygcheck.out
>   183k 2006/11/30 C:\cygwin\bin\cygmpfr-1.dll - os=4.0 img=1.0 sys=4.0
>   "cygmpfr-1.dll" v0.0 ts=2006/11/30 13:21
> gmp 4.2.1-1
> libgmp-devel4.2.1-1
> libgmp3 4.2.1-1
> 
> [EMAIL PROTECTED] /usr/local/src/branch/objdir
> $ grep mpfr cygcheck.out
>   183k 2006/11/30 C:\cygwin\bin\cygmpfr-1.dll - os=4.0 img=1.0 sys=4.0
>   "cygmpfr-1.dll" v0.0 ts=2006/11/30 13:21
> libmpfr-devel   2.2.1-1
> libmpfr12.2.1-1
> mpfr2.2.1-1
> 
> which seems right to, don't you agree? the libmpfr0 is not installed,
> what is it and why is it needed, you mean?

The lib packages contain the actual DLL files (i.e. the part
needed at runtime.)  When a library has multiple ABIs / multiple
versions to support there will be one for each ABI version of the
library.  I would think that gfortran would be linked against libmpfr1
and that libmpfr0 would not be needed, but who knows.  It would be good
to install it anyway.

And also, run cygcheck on the binaries to see what they're linked to:

cd /usr/local/src/branch/objdir/gcc && \
 for F in cc1 collect2 f951 gfortran xgcc; do cygcheck ./$F.exe; done

In my build dir this shows that only cyggmp-3.dll and cygmpfr-1.dll are
used, with no reference to cygmpfr-0.dll.

Brian

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

[Brian Dessent]

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 you put it in the toplevel configure.in or in
libgfortran/configure.ac?  I suspect it needs to be in the former,
because the latter probably shares the same config.cache and thus it
won't be checked a second time when running configure for libgfortran.

In any case, I think efforts would be better spent helping get a modern
libtool into the tree, since the one there now is ancient and I wouldn't
be surprised if the mingw/cygwin-specific parts have bitrotted from
years of neglect.  For example, this AC_LIBTOOL_WIN32_DLL macro was
removed/deprecated from libtool three years ago.

Brian

Re: AC_LIBTOOL_WIN32_DLL for libgfortran

[Brian Dessent]

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 following that thread and have been hoping for progress
on the win32 front for a while.  Seems to me like the problem with
upgrading libtool is that it's an area that touches the entire tree, and
the libtool that's there now is highly customized/forked (from what I've
read) so it seems like a very thankless job.

> > For example, this AC_LIBTOOL_WIN32_DLL macro was
> > removed/deprecated from libtool three years ago.
> 
> What should be used with a recent libtool? And where is it documented?

There is no need for any special consideration to create a DLL with
modern libtool.  One just needs --enable-shared at configure and
-no-undefined in LDFLAGS.

Brian

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

[Brian Dessent]

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: Can't bootstrap gcc 4.2 RC1 on cygwin: gcc/boehm-gc/misc.c:680: undefined reference to `_GC_get_thread_stack_base'

[Brian Dessent]

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/objdir/i686-pc-cygwin/libjava
> -L/usr/local/src/branch/objdir/i686-pc-cygwin/libjava/.libs
> ./.libs/libgcj.a
> -L/usr/local/src/branch/objdir/i686-pc-cygwin/libstdc++-v3/src
> -L/usr/local/src/branch/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
> -ldl -lz -L/usr/local/src/branch/objdir/./gcc -L/usr/local/lib -lgcc
> -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32 -lgcc
> ./.libs/libgcj.a(misc.o): In function `GC_init_inner':
> /usr/local/src/branch/objdir/i686-pc-cygwin/boehm-gc/../../../gcc/boehm-gc/misc.c:680:
> undefined reference to `_GC_get_thread_stack_base'
> collect2: ld returned 1 exit status
> make[3]: *** [jv-convert.exe] Error 1

Yes, this is unfortunately par for the course with gcc and win32, which
hasn't been able to even bootstrap all languages for many months.  Ada's
broken too, has been since October.  Sad state.  You can get gcj limping
again with something like this:

--- win32_threads.c (revision 121494)
+++ win32_threads.c (working copy)
@@ -337,6 +337,11 @@
 }
 # endif
 
+GC_PTR GC_get_thread_stack_base()
+{
+  return 0;
+}
+
 void GC_push_all_stacks()
 {
   DWORD thread_id = GetCurrentThreadId();


Brian

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

[Brian Dessent]

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 of
> -fkeep-inline-functions.  I think I remember there being some change between
> gcc-3.x and gcc-4.x in inline handling and I think that's what's biting us
> now; I think this may only arise in stage1 where we're trying to use 3.x to
> compile 4.x.

I too thought that this was related to the c99 inline changes, but I
think those only apply to "extern inline" which is not the case here.

The real cause seems to be that -fkeep-inline-functions was a no-op up
until: , which
seems to roughly correspond to when bootstrap stopped working on Cygwin.

So it looks like we need to either stop using -fkeep-inline-functions
for this file, change the definition to extern inline (or extern inline
plus __attribute__((gnu_inline))?  I'm still a little confused there),
or link against -lcygwin.  I kind of think the latter sounds wrong,
since there really is no reason that these unused function bodies should
end up in the .o file simply because it happens to have #include
 at the top.

Brian

Re: Build report for gcc 4.1.1 on Cygwin

[Brian Dessent]

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/local/gcc-4.1.1 --program-suffix=-4.1.1 
> --enable-th
> reads=win32 --with-cpu=i686 --with-arch=i686 --with-tune=i686 
> --enable-language
> s=c,c++

--enable-threads=win32 is wrong.  Cygwin uses pthreads not win32
threads.

> Another question is - is it possible to debug gcc using visual studio ?

If by possible you mean by looking at raw assembly then sure.  Otherwise
no.  The two toolchains use entirely different formats for debug symbol
information so there's really no chance this would work.  But you can
use gdb/insight just fine.

> I have seen some "no" answers on internet - but another question would be - 
> is it possible
> to create some "gcc calls dll"-style system and dll can be debugged using 
> visual studio?
> (I guess as long as data type alignment is the same in both environment this 
> could be done).

It really depends.  One debugger won't be able to unwind the call stack
of a foreign toolchain if it can't read that foreign toolchain's debug
format and the frame pointers have been eliminated.  So even if you have
debug symbols available for the module of the current frame, you could
still have a hard time making any sense of what's going on.  And this
assumes pure C, if there is C++ then things get even more ugly as the
Visual Studio and g++ C++ ABIs are quite different.

Brian

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

[Brian Dessent]

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=posix.

Brian

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

[Brian Dessent]

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

There is a very compelling reason.  If you go creating threads behind
Cygwin's back by calling the Win32 API directly, you will quickly get
very wrong results as you try to use other features of Cygwin.  In order
to correctly emulate a posix API under Windows, Cygwin has to handle all
creation and deletion of resources, including threads, and the
corresponding bookkeeping to keep track of them.

The only way this would ever work is if you didn't use any features of
Cygwin (especially any pthreads functions), and stuck to the Win32 API
entirely.  But then, that would be completely missing the point of
Cygwin, which is to provide the posix API.  If you want to use native
Win32 threads, use MinGW.  --enable-threads=win32 is the correct choice
for MinGW.

Brian

Re: Problem building gcc on Cygwin

[Brian Dessent]

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 with
--enable-bootstrap (default for native) or --disable-bootstrap and then
just "make".  Specifically, configuring with --disable-bootstrap and
then trying to do "make bootstrap" will fail.  So just use "make".  Is
there a page on gcc.gnu.org somewhere that tells you to use the above
command?  If so it should be changed.

Brian

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

[Brian Dessent]

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 && ln -s ../libgcj-tools.la 
> libgcj-tools.la)
> /bin/sh ./libtool --tag=GCJ --mode=link
> /usr/local/src/trunk/objdir/gcc/gcj
> -B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
> -B/usr/local/src/trunk/objdir/gcc/
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava -ffloat-store
> -fomit-frame-pointer -g -O2  -o jv-convert.exe
> --main=gnu.gcj.convert.Convert -rpath
> /usr/local/lib/gcc/i686-pc-cygwin/4.3.0 -shared-libgcc
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs libgcj.la
> /usr/local/src/trunk/objdir/gcc/gcj
> -B/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/
> -B/usr/local/src/trunk/objdir/gcc/ -ffloat-store -fomit-frame-pointer
> -g -O2 -o jv-convert.exe --main=gnu.gcj.convert.Convert -shared-libgcc
>  -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava/.libs
> ./.libs/libgcj.a
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src
> -L/usr/local/src/trunk/objdir/i686-pc-cygwin/libstdc++-v3/src/.libs
> -ldl -lz -L/usr/local/src/trunk/objdir/./gcc -lgcc -lcygwin -luser32
> -lkernel32 -ladvapi32 -lshell32 -lgcc
> ./.libs/libgcj.a(lt102-misc.o): In function `GC_init_inner':
> /usr/local/src/trunk/objdir/i686-pc-cygwin/boehm-gc/../../../gcc/boehm-gc/misc.c:680:
> undefined reference to `_GC_get_thread_stack_base'
> collect2: ld returned 1 exit status
> make[3]: *** [jv-convert.exe] Error 1
> make[3]: Leaving directory 
> `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory 
> `/usr/local/src/trunk/objdir/i686-pc-cygwin/libjava'
> make[1]: *** [all-target-libjava] Error 2
> make[1]: Leaving directory `/usr/local/src/trunk/objdir'
> make: *** [bootstrap] Error 2

Nothing has changed since the last time you asked this exact question:
.  It'd be better to
post this to the java list, BTW.

Brian

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

[Brian Dessent]

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 here, but how would it be different from if the compiler
> installed a header that said
> 
> #define __builtin_lgamma lgamma /* Must have MPFR installed. */

The builtin would run on the host at compile time, whereas the above
would run on the target at runtime.  I presume he's talking about using
MPFR in the host compiler to simplify lgamma(constant), not actually
causing any requirement on the target code to use or have MPFR.

Brian

Re: Cygwin build documentation error.

[Brian Dessent]

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/cygwin/i686-pc-cygwin/winsup/doc'
> gcc -g /usr/src/src/winsup/doc/doctool.c -o doctool
> ./doctool -m -d /usr/src/src/winsup/doc -d /usr/src/src/winsup/utils -d
> /usr/src/src/winsup/cygwin -s /usr/src/src/winsup/doc -o cygwin-ug-net.sgml
> /usr/src/src/winsup/doc/cygwin-ug-net.in.sgml
> xmlto html -o cygwin-ug-net/ -m /usr/src/src/winsup/doc/cygwin.dsl
> cygwin-ug-net.sgml
> usage: xmlto [OPTION]... FORMAT XML


This should go to the Cygwin list.  You're building in winsup, which is
not part of gcc, so this is totally off topic.

The answer is that you probably have a missing package, or maybe a
non-Cygwin/native version of xmlto in your PATH, but we don't know. 
Send your cygcheck output as directed in cygwin.com/problems.html.

Brian

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Brian Dessent]

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 indication of when the next version of Cygwin will be,
> and if it will have latest GCC from CVS ?

Those are two unrelated questions; Cygwin is not a monolithic thing, it
is like a distribution with packages.  The version of the Cygwin DLL is
unrelated to the version of gcc that is packaged.

To answer the former, that's up to the Cygwin maintainers, but probably
not any time soon.  The stdio.h thing is trivial to work around, you
don't need to even touch winsup or anything.  Just take the stdio.h from
newlib CVS and stick it in /usr/include.  You don't have to rebuild
Cygwin or anything.

To answer the second question, that's a much different question.  I
don't think the  Cygwin gcc maintainer would ever package a development
(non-released) version of gcc.  And on top of that, gcc v4.x is very
immature on win32 and still have a number of unresolved problems.  Thus
both the MinGW project and the Cygwin project still only offer binaries
of 3.4.x.  It remains to be seen when gcc v4 will stabilize on win32. 
Danny Smith has said that the MinGW project will release a packaged
4.2.0 when it is released, but there will likely be a lot of local MinGW
patches -- both projects rely on heavily patched sources to fix
regressions that can't/won't/haven't been addressed upstream.

Brian

Re: Successfull Build of gcc on Cygwin WinXp SP2

[Brian Dessent]

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 types are just the cygwin1.dll
which goes in /usr/bin of course.  And again, you do *not* need to mess
with any of this to make stdio.h usable for building gcc.  Just take
stdio.h from newlib HEAD and place it in /usr/include.

> The FAQ does not seem to say that. From the instructions it would seem it
> would go in the current users directory.

Read it again.  Both tar commands include -C which means "cd to this
directory before extacting."

> I am a bit confused what winsup is as well.

That is just a directory in the "src" tree that contains the code for
Cygwin, MinGW, w32api, and other miscellaneous Windows things.  But note
that you can't build Cygwin from just winsup/cygwin, as Cygwin needs
other parts of the "src" tree, such as libiberty and newlib.  When you
do a "cvs co cygwin" that is actually a CVS module that gets you a
selected subset of the entire "src" tree, including the toplevel scripts
that are shared across gcc/binutils/gdb/sim/etc.  If you later do "cvs
up" from the toplevel you'll accidently get the entire "src" tree which
you don't need, so you have to do "cvs up" in each individual directory.

Brian

Re: GCC 3.3.6 has been released

[Brian Dessent]

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 its 2.95 gcc package due to
brokenness (and lack of maintainer interest in resolving it) quite some
time ago, so it's probably misleading to state that it's available.

Brian

Re: GCC 3.3.6 has been released

[Brian Dessent]

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 +75,7 @@
   ftp://ftp.axis.se/pub/users/hp/pgccfd/";>Porting GCC for
   Dunces by Hans-Peter Nilsson [EMAIL PROTECTED]>.
 
-  http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO";>GCC Frontend
+  http://www.tldp.org/HOWTO/GCC-Frontend-HOWTO.html";>GCC Frontend
   HOWTO by Sreejith K. Menon [EMAIL 
PROTECTED]>.
 
   http://people.debian.org/~aaronl/Usenix88-lexic.pdf";>Lexical

Re: Help on -Wl option

[Brian Dessent]

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




Brian

pr 22207: Spurious 'might be used uninitialized' warnings

[Brian Dessent]

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 building with "-Wall
-Werror" impossible without having to disable some warnings.

The problem occurs with gcc 3.4.4 and is a regression from 3.3.3, which
worked fine.  The PR includes a testcase that reproduces it under Cygwin
but not Linux, so it very well may be something that is
Cygwin-specific.  If you need any further information please let me
know.

Thanks,
Brian

Re: warning on i686-pc-cygwin

[Brian Dessent]

bobby mcnulty wrote:
> 
> This bug is in the GCC source code. Filed on Monday, Oct. 10, 2005

You're running into PR21766.

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

[Brian Dessent]

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-cygwin/i
> nclude -isystem /usr/local/i686-pc-cygwin/sys-include -DHAVE_CONFIG_H
> -I. -I../.
> ./../../gcc-4_0-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c
> ../../../../gcc-4
> _0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o
> In file included from
> ../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c:
> 32:
> ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error:
> conflicti
> ng types for 'ieee_double_shape_type'

It looks like what is happening is BYTE_ORDER isn't getting defined
correctly.  This is supposed to be taken care of by the sys/param.h
header of the target, which Cygwin does provide correctly.  It looks
like for some reason gcc isn't picking this up in your case.  Are you
doing a native or a cross?  What configure options are you using?

Brian

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

[Brian Dessent]

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-branch/libstdc++-v3/libmath -I.. -O2 -g -O2 -c
> > ../../../../gcc-4
> > _0-branch/libstdc++-v3/libmath/signbit.c -o signbit.o
> > In file included from
> > ../../../../gcc-4_0-branch/libstdc++-v3/libmath/signbit.c:
> > 32:
> > ../../../../gcc-4_0-branch/libstdc++-v3/libmath/mathconf.h:167: error:
> > conflicti
> > ng types for 'ieee_double_shape_type'
>
> It looks like what is happening is BYTE_ORDER isn't getting defined
> correctly.  This is supposed to be taken care of by the sys/param.h
> header of the target, which Cygwin does provide correctly.  It looks
> like for some reason gcc isn't picking this up in your case.  Are you
> doing a native or a cross?  What configure options are you using?

This is caused by this change:
<http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/winsup/cygwin/include/endian.h.diff?r1=1.3&r2=1.4&cvsroot=src&f=h>.
 
This modified include/endian.h to only conditionally define BYTE_ORDER
etc. if __USE_BSD is defined, whereas before in newlib's
machine/endian.h
<http://sources.redhat.com/cgi-bin/cvsweb.cgi/src/newlib/libc/include/machine/endian.h?rev=1.2&content-type=text/x-cvsweb-markup&cvsroot=src>
they were defined unconditionally.

Thus if you build gcc with the 1.5.18 version of cygwin and its headers
you don't run into this, but if you try to use a snapshot that contains
this change you get the above error.

Brian

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

[Brian Dessent]

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: Antwort: Re: Antwort: Re: [PATCH]: bump minimum MPFR version, (includes some fortranbits)

[Brian Dessent]

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 its testsuite. 
Besides, Cygwin has a binary package of mpfr 2.3.1 that you can just
install, so you don't have to compile mpfr yourself at all.

Brian

Re: Cygwin support

[Brian Dessent]

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 &
> Linux/Un*x purist camps but I like it :-) )

Cygwin has been a secondary target for a number of years.  MinGW has
been a secondary target since 4.3.  This generally means that they
should be in fairly good shape, more or less.  To quote the docs:

> Our release criteria for the secondary platforms is:
> 
> * The compiler bootstraps successfully, and the C++ runtime library 
> builds.
> * The DejaGNU testsuite has been run, and a substantial majority of the 
> tests pass.

Generally the problem that the PE/COFF targets face is that because of
different semantics compared to ELF systems they often lag behind in
certain areas.  For example the lack of support for shared
libgcc/libstdc++/etc. has been a continual problem for a long time but
recent progress has moved things ahead somewhat.  Another long standing
issue is the desire to get away from SJLJ based exception handling and
move to table-based Dwarf unwinding for performance reasons, but this is
coupled with the need for working shared target libs.  But this is as
much a "system integration" problem as it is a gcc problem, as with any
large switch.

More recently I've seen Danny Smith report that the IRA merge broke
MinGW (and presumably Cygwin, since they share most of the same code)
bootstrap.  I haven't tested this myself recently so I don't know if
it's still broken or not.

The real heart of the matter though is that most of the people that
contribute to gcc aren't themselves users of these targets, and so it's
only natural that they don't know about or care about the status of any
target-specific issues.  What has worried me lately however is how much
ELF-specific design has been creeping into gcc, notably in the areas of
plugins and LTO.  If this trend continues it will result in the PECOFF
targets becoming even more of a backwater than they already are, which I
find to be a sad future for the 90%.

> Reason, I ask is I would like to start to contribute and for me Cygwin
> is the easiest target for me. But looking over things I'm not sure it
> would be the best place to start to help things out.

Well, you can certainly use Cygwin as a base for contributing, however,
unless you are doing target-specific work[1] it doesn't make a lot of
sense to do so.  Running the dejagnu testsuite on Cygwin is
excruciatingly slow due to the penalty incurred from emulating fork. 
Even with the overhead of vmware/colinux/virtualbox you're probably
looking at a reduction from 20-30 hours down to several hours for a full
testsuite run on an virtualized linux image compared to a native run
(depending on which languages are enabled.)

Brian

[1] And of course, don't get me wrong, that would be fantastic, as these
targets need all the TLC they can get.

Re: Cygwin support

[Brian Dessent]

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 postlinker to generate
> target (PE/COFF) images.

Using ELF as an intermediary format doesn't really change the situation
facing the design of plugins in any meaningful way though.  If the end
result is still PE/COFF executables and DLLs then the same problems and
restrictions still exist that would make the current proposed design
unworkable on these Windows targets.  If you recall the issue is that
plugins want unfettered access to the full symbol table of the
executable.  Doing this with PE/COFF is possible, but it binds the
plugin DLL to the specific name of the executable that it was linked
against, such that the same plugin wouldn't be loadable from cc1.exe,
cc1plus.exe, f951.exe, etc.  To get around this you'd have to either
link a separate copy of the plugin for each executable, or access the
symbols in the executable indirectly through GetProcAddress and function
pointers.

Brian

Re: Cygwin support

[Brian Dessent]

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 are never supposed to need any version of autoconf to simply build
gcc, only if you need to rebuild generated files.  If the timestamps are
correct (either by using a tarball or contrib/update_gcc to update from
SVN) then autoconf should never be invoked, otherwise something is wrong
with your setup.

> and the need to remove the -werror in
> libstdc++ build (because of minor discrepancies in cygwin headers).  All

That is what --disable-werror is for.

> be accepted.  Support for 64-bit native looks like it will be limited to
> mingw, so I no longer see a future for gcc on cygwin.

I don't know where you keep getting this conjecture from.  Porting the
Cygwin runtime library itself to x64 is a lot more work than getting a
64 bit MinGW environment working because Microsoft has already done the
work in the case of a 64 bit MSVCRT, and because there is a lot more
going on in the Cygwin runtime than in the Microsoft.  But just because
that porting work hasn't happened yet doesn't mean it won't eventually. 
Moreover, from the standpoint of gcc the two targets share virtually all
the same code and there is very little substantial difference between
them aside from miscellaneous specs file differences and driver bits, so
once that porting of the Cygwin runtime happens there should be minimal
work left on the gcc side.

Brian

Re: Cygwin support

[Brian Dessent]

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 Windows users where a single file suffices for
users of ELF systems.  (And I'm sure that the required build-system
magic to cope with that will not be particularly pretty.)

Brian

Re: Cygwin support

[Brian Dessent]

"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 far said they want
access to every aspect of the compiler from within the plugin, i.e. to
poke and prod at the full symbol table, without being tied down by a
limited, designated access route of a plugin API.  This means you'd have
to move essentially everything into this mega-DLL, leaving cc1 and
friends as merely stubs that set a flag and then call into the DLL never
to return, since anything left in cc1 would not be accessible from the
plugin.

That would present a problem to packagers.  Since the code for all the
language backends would be in this one mega-DLL, it would be impossible
to install one language's compiler without installing all of them. 
Sure, you could still split it up into separate packages for the sake of
the other runtime library support components and headers, but the user
would still be paying the price in terms of disk and memory consumption
of this mega-DLL that supports all languages when only using one of
them.

Of course this would only happen if you enabled plugin support, but from
the standpoint of the packager/disto role you wouldn't want to ship a
plugin-disabled gcc because then your users would have to go to the
trouble of building gcc themselves from source if they wanted to try a
plugin.  Not having to do that is supposed to be one of the major
reasons for developing plugins in the first place.  So you end up with
all users paying the cost of the entire compiler suite condensed into
this monolithic chunk even if only a small fraction of users are
interested in trying a plugin.

Brian

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

[Brian Dessent]

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 -Wuninitialized was designed to warn
about, which is auto variables whose lifetime begins and ends within the
scope of the function and thus it's relatively straightforward to
compute that if the first use comes before any definition, then warn. 
But a member's lifetime is not related to the scope of any member
function but to the lifetime of the object.  So it would probably
require some form of interprocedural analysis as e.g. you'd have to see
both the constructor and the member function at the same time in order
to say what is used before being initialized -- too bad if they're in
different translation units.

Moreover, the current -Wuninitialized warning is done in the middle end
as it relies on the program having been transformed into SSA form and
the dataflow equations solved.  But this member analysis pass would need
tons of C++ specific knowledge, for example public members could be
initialized in the ctor of a derived class -- which brings up a whole
other nightmare since there would be no way in general to know without
whole-program analysis whether or not this is the case, so you'd
probably only be able to ever consider private members.

Anyway, so this pass would need tons of C++ specific information (like
all the arcane rules for order of construction) and so it would probably
have to be done in the front-end.  But warnings implemented in
front-ends which require this kind of dataflow information are
notoriously fickle in that they either miss tons of legitimate cases or
warn spuriously all over the place, because the required machinery to
get it right runs later.

I'm far from a gcc expert and I could be entirely wrong but it seems to
me that all of this means that this form of warning is just not
practical to implement at all.

Brian

Re: Where is DESTDIR got defined in gcc makefile?

[Brian Dessent]

"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 overrides it.  See
.

Brian

Re: Crossed-Native Builds, Toolchain Relocation and MinGW

[Brian Dessent]

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 executables.

No, you've actually just proved Ross' point correct.  Gcc being a native
win32 app gets the actual win32 path, not any kind of posix path that
might be adjusted for MSYS mounts.  If you took the above testcase and
mounted /usr/local/test as /foobar and then ran /foobar/test.exe you
would get identical output, E:\msys\local\test\test.exe, because that is
the actual path to the binary.  In other words, native win32 binaries
are completely oblivious to any mounts created in MSYS, so using mounts
is not a viable workaround since only MSYS apps will see a distinction.

Brian

Re: Cross-compilation and Shared Libraries

[Brian Dessent]

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 view of creating executables for embedded

As far as I know, shared libstdc++ for mingw/cygwin has never worked,
you always get static no matter what you do, regardless of
--enable-shared or native/cross.  I don't know if this is because of the
archaic version of libtool that's in the tree, or some other reason.  It
sure would be nice to get a shared libstdc++ one of these days without
having to resort to hacks like manually linking together all the .o
files in the build tree.

Brian

Re: RFC: __cxa_atexit for mingw32

[Brian Dessent]

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,
> and that is why I considered it the easier option.

This change would be contained in crt?.o & dllcrt?.o, no?  So that would
mean it would get statically linked, with no additional runtime
dependency.  Assuming it was licensed the same way as the rest of the
existing CRT startup code, I don't see how anyone could complain.  It
would give us proper __cxa_atexit support for essentially free.

Brian

Re: plugin includes for MELT

[Brian Dessent]

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 API without involving
any gcc headers.  As a plugin author, this is ideal as you simply grab
this SDK and code your plugin without having to ever touch gcc sources,
and your plugin "just works" with any gcc.

This of course requires a ton more work to create and maintain, since
you have to a) invent a new API that is flexible enough to do everything
that a plugin ever might want to do, and in a way that does not
introduce too many target- or architecture-specific details; b) code
wrappers in gcc that translate the plugin API into the internal
representation; c) maintain those wrappers in the face of changing gcc
internals.  It's been my observation that whenever plugins are
discussed, the majority of gcc maintainers do not want to bear the
maintenance and support burden of this level of decoupling, so it's kind
of a pie in the sky position I think.

Brian

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

[Brian Dessent]

"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: Successfull build of gcc 4.2.3 with MinGW 5.13 in windows XP

[Brian Dessent]

"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 would be
if you're using Cygwin as a build environment (but with MinGW tools
first in the PATH, i.e. not using Cygwin gcc.)  In that case the Cygwin
'ln -s' would be used and would create Cygwin symlinks, but the MinGW
tools won't be able to recognise them.  But the poster said he was using
MSYS so that doesn't appear to be relevant here.

Brian

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

[Brian Dessent]

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 across month boundaries very gracefully.  Let me see if I
can summarize the history of the issue for posterity.

Target libraries like libstdc++ need to know a lot of details about the
system they are being configured for -- what C library functions and
capabilities are present, and so on.  The library can get this
information either by performing configure tests that link test
programs, or by having the needed answers somehow supplied in another
form.

The problem is that with embedded bare-metal newlib targets (i.e.
*-elf), the amount of functionality that the target has depends
significantly on the board support package (BSP) which typically
consists of things like startup code (crt*.o), linker scripts, and low
level syscall implementations (or stubs thereof.)  Since these are
things outside the scope of gcc and newlib, it means without some
external source (be it from the hardware vendor or using generic stubs
from libgloss) that a bare metal gcc target cannot link.  And that is
what the GCC_NO_EXECUTABLES error means: some configure script is trying
to do a link test but linking was earlier determined to be impossible
due to no linker script (or crt*.o or whatever) being present.

This presents a dilemma if you want to build a bare metal gcc with
anything but plain C support.  The libstdc++ configury in particular
dealt with this by special casing newlib bare metal cross targets, such
that a fixed list of capabilities known to be present in newlib were
coded into crossconfig.m4 such that no link tests were necessary.

At some point last year, this stopped working: bare metal newlib targets
were again failing with GCC_NO_EXECUTABLES when trying to configure
libstdc++.  The reason was related to an upgraded libtool and
AC_LIBTOOL_DLOPEN which wanted to check for dlopen() support in the
target, and thus why you see the error about searching for shl_load(). 
Ideally, since it's common for bare metal targets to not even have
shared libraries it should be possible to avoid the question of dlopen()
support by just specifying --disable-shared, but apparently this doesn't
work because AC_LIBTOOL_DLOPEN has to be called before libtool has been
initialized with AM_PROG_LIBTOOL.

The controversy and bulk of the long thread came about how to rectify
this.  The first workaround, which started the whole long thread was a
Blackfin-specific patch that papered over the problem by making -msim
implicit when -mfdpic or
-mid-shared-library was given, which artificially allowed link tests to
succeed.  Obviously that doesn't help with other targets but I think it
was enough to get the discussion rolling as to what the real nature of
the problem was.

One proposed remedy was apparently to have the user add libgloss to
their tree, and add code to detect this and pass the appropriate flags
down when configuring target libraries, allowing link tests to work. 
But there was objection to this because people were uncomfortable with
letting link tests succeed without the user having specified a BSP,
since that increases the potential for a user to build a toolchain whose
configuration does not match with what the actual hardware supports.

Another idea (the one in the link in your message) was to disable that
particular libtool test when cross compiling.  That was not acceptable
because it violates the philosophy that cross compilers should produce
identical code to native compilers for a given target.  If simply the
fact that you built gcc as a cross caused a change in behavior, then the
utility of cross compilation would be substantially decreased.

Yet another idea was presented to provide a framework wherein the user
could provide a config.cache-like file that would simulate the results
of all of the configure tests having been performed.  It seems that
people generally thought that was a good idea in the abstract but there
was some worry that since it required supplying answers to all configure
tests that it would be hard to come up with a suitable "generic" one to
ship with gcc.  There seemed to be agreement that it should remain an
optional feature that the user could use if he had a suitable
config.cache, but not something to make the default building of a
toolchain work again.

There was one additional solution discussed: disable libtool's checking
of dlopen() for newlib targets:
  I think
everyone agreed that this was a suitable compromise, and that the way
forward was to revert the libgloss hacks, implement the config.cache
idea as an optional alternative, and commit the patch to disable
dlopen() checking on newlib.

However nothing seemed to ever actually get committed

Re: gcc-4.1-20080303 is now available

[Brian Dessent]

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 that means they can no longer benefit from
backported fixes that get put on the branch since distros also tend to
have a number of local out-of-tree patches that are not necessarily
GPLv3.  The whole point of keeping an old release branch open would be
specifically to make their lives easier, but instead you'd be
multiplying the amount of work they'd have to do.  Now they must choose
between: a) ignoring all backports past the last GPLv2 point on the
branch, b) separately reimplementing each backport as a GPLv2 patch, or
c) auditing their whole local tree and deleting/reimplementing anything
not GPLv3 compatible.  It's an especially futile idea when the sole
reason for doing the v3 update is to be able to cut a final release off
the branch and then close it.  But anyone that wants the code on the
branch can easily just check it out or use a snapshot, there's no need
to go to all the trouble just to make a release.

Brian

Re: Regenerating configure scripts

[Brian Dessent]

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
>  AC_LIBTOOL_DLOPEN
>fi
> then it works as expected.
> 
> This is weird.  I see the former idiom everywhere in configure.
> The tests can't all be failing.

I think both are wrong.  You should be testing whether it equals the
value "yes", not whether or not the variable is set, because
$with_newlib can equally be blank or set to "no" in a non-newlib case.

Brian

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

[Brian Dessent]

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 not too far off.  "readlink -m" would be
closer if needed.

Denys Vlasenko wrote:

> What happened to the good old concept of looking up executables'
> location in $PATH if they have no slashes on the name?
> 
> (Oh well)^2. Recompiling with --with-as="/usr/bin/$CROSS-as"...

Why do you think it's necessary to specify this?  Configure will
automatically find and use $tooldir/bin/as (= $prefix/$target/bin/as) or
$target-as in PATH.

Brian

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

[Brian Dessent]

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 argue that it's not, since simply using the same $prefix
JustWorks(tm) without worrying about modifying PATH or any --with-foo.

Brian

Re: gcc emit wrong symbols in multiple inheritance case

[Brian Dessent]

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 ?  If so it has regressed as that
was supposedly fixed in 4.3.

Brian

Re: gcc emit wrong symbols in multiple inheritance case

[Brian Dessent]

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 problem gcc
> generate a " U [EMAIL PROTECTED]" for indeed existing
> definition of "__attribute__((__stdcall__)) bottom:fun1()" .

The "U" lines are correct and aren't the problem; those are call sites
to the properly mangled symbol name.  What's incorrect is that gcc emits
the function definitions (the 'T' lines) without the proper stdcall name
mangling.  If gcc used the proper mangling for the definitions then the
undefined call sites would no longer be undefined and would not show up
in the objdump output any more.

Brian

Re: gcj/sparc64?

[Brian Dessent]

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 fixed on
mainline.  Two problems: the fix needs to be extended to Cygwin as well
as MinGW, and you're not building mainline.

> I wish Windows code was PIC, then wouldn't worry about base addresses and
> the cost of relocs.. (even if AMD64 is mostly PIC, the data still isn't, e.g. 
> vtables).

With --enable-auto-image-base this becomes nearly a non-issue.  Libtool
has been enabling that by default on PE for a long time.  There was also
a patch several years ago to support a variant of ELF-style PIC on
Windows, but it was never reviewed nor commented on.  The ABI
implications probably make this infeasible anyway.  In any case this has
zero to do with the topic of this thread.

Brian

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

[Brian Dessent]

"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 with another.  Why should --target=i686-*-linux imply
-march=686 when, say, --target=i686-*-freebsd or --target=i686-*-elf
still implies -march=386?  If you want to imply a default -march from
the target specification (and I think that's a perfectly good thing to
want to do) then it should apply to all x86 targets equally.  If that's
too radical of a change then just bumping the universal default to 486
seems like the next best thing -- at least that's consistent.

Brian

Re: Defining a common plugin machinery

[Brian Dessent]

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 implementation into a "library/DLL" having a "stub"
> > main() that just calls the library implementation. Then both the
> > application AND the plugins can link with this library/DLL in a way that
> > will work on Windows.
> > Or are we going for the quick solution of using -rdynamic and not
> > supporting this platform (Not my preferred option)?
> 
> AFAIK you can fix w32 issues with DEF files.

Well, that is another way to do it.  You don't have to use a .def file
or __declspec(dllexport) markup, you can also use
-Wl,--export-all-symbols which doesn't require any source code
modifications.

But there is another more sinister problem on PE hosts with having the
plugin link to symbols from the executable: this hard codes the name of
the executable in the plugin, as essentially the executable is now a
library to which the plugin is linked.  Obviously this is a deal-breaker
because the plugin needs to be loadable from cc1, cc1plus, f951, etc.
unless you want to link a separate copy of the plugin for each language.

An alternative is to have the plugin resolve the symbols in the
executable at runtime, using the moral equivalent of dlsym.  This also
makes linking the plugin a lot easier because you don't have to worry
about resolving the executable's symbols at link-time (which you would
otherwise have to do with an import library for the executable.) 
However, this makes life more difficult for the writer of the plugin as
they have to deal with all those function pointers.  It is possible to
ameliorate this with macros that set up each function pointer to a
wrapper that looks up the actual function the first time it's called and
then sets the pointer to that address, essentially a poor-man's PLT. 
But with this method you still have to maintain a list of every
functions/variable used in order to instantiate a copy of the wrapper
macro for it.

Moving the compiler itself into a shared library of course avoids all of
the above, but I'm not sure I understand how this would work w.r.t. the
different language backends.  Would the shared library just contain
everything, and somehow just determine its behavior based on whether it
was loaded by cc1 or cc1plus or f951 etc.  Or would there be a separate
shared library for each?  (Which would really be useless and not solve
anything for PE hosts because it would be back to requiring a number of
copies of the plugin, one for each language backend.)

Is it really that far fetched to have the plugin not directly access
anything from the executable's symbol table but instead be passed a
structure that contains a defined set of interfaces and callbacks?  By
using this strategy you also insulate the plugin from the gcc internals,
such that you can define this struct in a separate header that goes in
the plugin SDK, without requiring that the SDK drags in a bunch of
internal crap from the build directory.  With judicious use of callbacks
you can even achieve some degree of plugin binary compatibility.  For
example you have gcc provide function pointers for
getters/setters/walkers/enumerators for internal structures in this
struct that is passed to the plugin.  The plugin is then insulated from
internal representation changes since the callback lives in gcc too and
gets rebuilt when the internal representation changes.

Now, I understand that maintaining a stable binary API for plugins is
probably not the number one priority, i.e. past discussions have
concluded that this is too much work and pain to maintain.  And maybe
that's true.  But I'm just suggesting that you can in fact kill two
birds with one stone here: insulate the plugin from internal
representation details *and* overcome portability problems with non-ELF
hosts.  

Brian

Re: Defining a common plugin machinery

[Brian Dessent]

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:" header in your message to the
list address and you won't be included in CC by most email clients when
someone does reply-to-all.

> I'm not sure that pre-compiled headers (pch) should even work with
> plugins. The reasonable solution is to disable them when any plugin is
> used (what should happen if plugins are not used when the pch is
> generated, but used when it is reloaded or viceversa; I don't know if
> this situation is hard to detect. Likewise, what should happen when the
> compilation of the header & the compilation of the source including the
> pch both dlopen-ed a different variant of the "same" plugin?). At least,
> having pch working with plugins should be postponed after the first
> approved (i.e. merged into the trunk) plugin imlementation.

There's already an existing requirement that the compiler options used
when precompiling the .gch must match or be compatible with those used
when using the .gch, so in essence the above is already forbidden by the
fact that adding or removing -fplugin= would render the .gch unusable. 
I seem to recall that the .gch file records the entire set of options
used when it was built and gcc refuses to consider the file if it does
not exactly match, however the documentation seems to imply that only
certain options are automatically checked/rejected while others are the
responsibility of the user to enforce:
.

Brian

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

[Brian Dessent]

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 shared between the
language front-ends, so if you introduce C++ there you now require a
pre-existing C++ bootstrap compiler even for people that have no
interest or need for C++ language support and are only building a C (or
Fortran or Java or Ada) compiler.  A lot of people have a problem with
that because some systems may not have or even want anything more than a
C compiler.

You could of course limit use of C++ to the C++ frontend, similar to how
the Ada frontend is written in Ada.  But I don't think that would do
much to alleviate the issue that you're complaining about because it
would still have to use all the same macros to represent trees and types
and so on to the language independent parts of the compiler.

Nevertheless it's a topic that keeps coming up and there are a number of
people that would like the advantages of better compile time type
checking and so on.  This debate always rages on because there is
constant fear that it will open the door for the more exotic and
unmaintainable C++ features to sneak in, in addition to the higher
bootstrap requirements.  At the moment there is slow progress in getting
things to the point where gcc can at least be built with a C++
compiler.  See also the gcc-in-cxx branch.

> What I'd like to add is something that I've seen many people request,
> and something I really want to use:
> Adding a -W option to check that all function calls and throws comply
> with the throw() clause of the function they are launched from.

You really ought to read the past threads on this topic, for example:






The general consensus is that doing this at compile time cannot give you
anything useful, because the compiler can only see one compilation unit
at a time and so the only thing it can know of all the downstream
functions that are in other CUs is what is provided in the exception
specifiers of the prototypes.  You're essentially trusting that all
exception specifiers for every function in the program and *all* library
code are always present and always correct which is a huge leap of faith
that I don't think is supported by reality.  For example the Boost
rationale basically says they are unusable in practical code except in
special cases:
.

> 1) Is my task a sensible one? Is there anything I have got fundamentally 
> wrong?
> 2) Is there anyone currently doing this? I'd hate to simply duplicate
> their effort.

You should certainly look at EDoc++, mentioned in the above threads.

> I can't find much readable documentation about the source. Does anyone
> have any good documentation links about the overall program flow
> through g++, files/functions etc? I need a primer.

Don't neglect the wiki: 

> 7) To someone new to the g++ source the included documentation seems
> pretty poor and cryptic. README mentions non-existant files,
> INSTALL/README says it's obsolete and redirects to a file "index.html"
> which doesn't yet exist. And why does the documentation have all these
> .texi, .info and (unlinked) manpage .1/.7 files. What's wrong with
> .txt, .html or similar? Shouldn't documentation be available from the
> download instead of having to go online to actually find out how to
> build and read the documentation itself - the documentation doesn't
> really take up much space. In this age do manpages actually have any
> advantages?

The documentation's canonical form is texinfo, i.e. gcc/doc/*.texi. 
Everything else (HTML, PDF, DVI, .info, manpages) is auto-generated from
the texinfo, e.g. "make html", "make pdf", etc.  Whether the generated
files are in your tree depends on whether you're working from a SVN
checkout or a release tarball, but the texinfo sources are always there.

Brian

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

[Brian Dessent]

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 to demangle the names you can't see the
difference in the labels, but they really are different symbols.

It just happens that in most cases the two versions have identical
bodies, and they could theoretically be condensend into a single copy
with two labels or two entry points.  But doing this has ABI
compatibility implications.  It's a non-trivial problem to solve, and a
long-standing wart.  See .

Brian

Re: Combined tree builds for mingw32

[Brian Dessent]

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-default.h; on this platform that pulls in , which
> eventually #define's min.  Then later we get , which now sees
> the definition.

Wouldn't the cleanest way to handle this just be to make it a policy
that any header that #includes windows.h must either first #define
NOMINMAX or immediately #undef min and max afterward?  If gthr-default.h
gets it via config/gthr-win32.h then it seems it would be simple to just
do this at the two places where that file includes windows.h.

> Hmm, there are three 's in the src repository:
> 
> /space/fsf/commit/src/newlib/libc/include/ctype.h
> /space/fsf/commit/src/winsup/cygwin/include/ctype.h
> /space/fsf/commit/src/winsup/mingw/include/ctype.h
> 
> That third one does not define _U.  It uses _UPPER instead.  Does this
> mean --with-newlib does not work for mingw32?  (Note, you can't build
> without it either.)

Well MinGW doesn't use any part of newlib so using --with-newlib sounds
like it's technically incorrect.  The right way is probably to add
something that does the equivalent of
--with-headers=$top_srcdir/winsup/mingw/include (and also --with-libs?)
if it detects the $target mingw* and a combined tree.  I think there is
something similar to this already present for using winsup/cygwin in a
combined tree.

Brian

Re: MinGW, GCC Vista,

[Brian Dessent]

[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 work on Vista as a result.

This is not a gcc issue in the slightest, it's a MinGW issue.  And it
has been fixed there some time ago.  Once you install the fixed MinGW
runtime and recompile gcc it works fine.  There are binaries (at least
for the gcc.exe driver frontend, the primary one affected) posted on the
MinGW mailing list, but nobody has gotten around to posting rebuilt
binaries at the SF download area.

Brian

Re: MinGW, GCC Vista,

[Brian Dessent]

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 less.

I may have overstated the nature of the change, as it still requires
#defining a symbol to get a change in behavior:

#ifdef __USE_MINGW_ACCESS
/*  Old versions of MSVCRT access() just ignored X_OK, while the version
shipped with Vista, returns an error code.  This will restore the
old behaviour  */
static inline int __mingw_access (const char* __fname, int __mode)
  { return  _access (__fname, __mode & ~X_OK); }
#define access(__f,__m)  __mingw_access (__f, __m)
#endif

So the default behavior is still the broken wartyness of X_OK.

> Obviously, I don't have any say or control over MinGW; I'm just
> providing feedback as a long-term MinGW user.  When I want a UNIX-like
> environment on Windows, I use Cygwin; when I want an alternative to
> VisualStudio for "native" Windows applications, I use MinGW.  I'd prefer
> that code I write with MinGW also work with VisualStudio and vice versa.

There is a long precedent for MinGW implementing/augmenting the MSVCRT
interface in the form of libmingwex for C99 complex math for example.

> In my opinion, this is a GCC bug: there's no such thing as X_OK on
> Windows (it's not in the Microsoft headers, or documented by Microsoft
> as part of the API), and so GCC shouldn't be using it.  The Vista
> runtime library chooses to issue an error when you set random bits in
> the mode provided to access, which is its privilege.
> 
> There's a simple GCC change to fix this: have libiberty wrap the access
> function and mask out X_OK on non-Cygwin Windows.  It's reasonable to
> put this change in libiberty, since it's job is to provide portability
> between systems.

This is also true, so I suppose it's not entirely correct to say that
this is not a gcc issue in the slightest.  This above should indeed go
into libiberty as the long term solution.  But no change today will
affect the MinGW system compiler (gcc 3.4.5 with a large amount of local
patches) which must be rebuilt one way or another, either by a patched
/mingw/include/io.h or by auditing all the source code and removing
X_OK, and the former is clearly less work than the latter.  And the
__USE_MINGW_ACCESS feature can apply to porting other arbitrary packages
to Vista, without any source auditing.

Brian

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

[Brian Dessent]

"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 --disable-multilib
if you're building FSF gcc.

Brian

Re: Decimal float and the Cygwin build of GFortran.

[Brian Dessent]

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 on linux. 
See e.g.  or
libdecnumber/configure.ac:

  case $target in
powerpc*-*-linux* | i?86*-*-linux* | x86_64*-*-linux*)
  enable_decimal_float=yes
  ;;
*)
  enable_decimal_float=no
  ;;
  esac

If it didn't print the warning in the past I don't think you can
conclude much of anything, other than the lack of a warning was a bug
that was fixed.  Whether or not the library actually works on Cygwin if
you force it to build is something you'd have to determine through
experimentation, however it seems clear that its maintainers don't
expect it to, or at least haven't tested it there.

Brian

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

[Brian Dessent]

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 of the libc/libm that AFAIK
is only currently implemented by glibc (and thus the current limitation
to linux):

http://www.open-std.org/jtc1/sc22/wg14/www/docs/n1176.pdf

- float.h support for macros like DEC{32,64,128}_MANT_DIG,
DEC{32,64,128}_{MIN,MAX}_EXP, et al.
- math.h support for HUGE_VAL_D{32,64,128}, DEC_INFINITY, DEC_NAN,
quantized{32,64,128}, et al.
- rounding defines FE_DEC_{TOWARDZERO,TONEAREST,...} and
fe_dec_{get,set}round()
- stdlib.h support for strtod{32,64,128}()
- wchar.h support for wcstod{32,64,128}()
- %H, %D, %DD printf specifiers
- %DF, %DD, %DL scanf specifiers

Brian

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

[Brian Dessent]

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
semantics in 4.2.  The motivation for this aspect of the change comes
about from the realization that anonymous namespaces are implemented by
adding a randomly-generated string to the mangled name so that they're
guaranteed to be unique to their translation unit.  So it would be
impossible or at least extremely cumbersome to actually refer to such a
symbol from another module, and thus giving them hidden visibility just
cuts down on useless indirection and overhead.

http://gcc.gnu.org/gcc-4.2/changes.html
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=21581
http://gcc.gnu.org/ml/gcc-patches/2006-06/msg01511.html
http://gcc.gnu.org/ml/gcc-patches/2006-03/msg01322.html

Brian

Re: WARNING bootstrapping GFortran on Cygwin

[Brian Dessent]

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 this is a new feature that was just merged.  The specific
patch that added it seems to be
.

+AC_ARG_ENABLE(fixed-point,
+[  --enable-fixed-pointenable fixed-point arithmetic extension to
C],
+[
+],
+[
+  case $target in
+mips*-*-*)
+  enable_fixed_point=yes
+  ;;
+*)
+  AC_MSG_WARN(fixed-point is not supported for this target,
ignored)
+  enable_fixed_point=no
+  ;;
+  esac
+])

It does seem a bit spurious to AC_MSG_WARN on all non-supported targets,
even if the user didn't attempt any --enable-fixed-point, but you can at
least silence it with --disable-fixed-point.

> Should I 'tune' the build adding something in 'configure' ?

Pretty sure this requires hardware support, e.g. on a DSP. Not the kind
of thing they make configure switches for... :)

Brian

Re: How to run testsuite without building a complier

[Brian Dessent]

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 contrib/test_installed script.

Brian

Re: gcc 4.2.2, libgomp under cygwin

[Brian Dessent]

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 directories should still work fine.)
> 
> 
> Now I am a bit confused. What is still missing?
> Because target-libgomp is of course required for the openmp-support.

Cygwin is not a target where libgomp is enabled by default, though it
probably should be since it strives for POSIX.  You have to
--enable-libgomp explicitly if you want to build it.

Brian

Re: libiberty/pex-unix vfork abuse?

[Brian Dessent]

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 specialization
in Cygwin, but it is broken and has not been enabled in quite a long
time.

Brian