whats happening here.
2008-09-14 Aaron W. LaFramboise [EMAIL PROTECTED]
* config/i386/t-cygming (SHLIB_C): Remove.
* config/i386/t-cygwin (SHLIB_C): Add all system libraries.
Index: gcc/config/i386/t-cygming
I'm happy to see that GRAPHITE it is in trunk now!
I don't see any documentation of prerequisites in install.texi yet;
perhaps we should add this so users can figure out what they need to do
to get this framework to work.
In fact, 'grep -i graphite gcc/doc/*' doesn't match anything, so I
Hi Jay,
Thanks for bringing this up. I mainly work on the native-ish Windows
targets (MinGW), so I'm not really a Cygwin guy, but see below.
Jay wrote:
I'm still testing this but it does seem to be two smoking guns.
The first one shot a blank but I doubt I'll find a third. :)
...
Can
Hi Øyvind,
Øyvind Harboe wrote:
I'm trying to build a mips-elf toolchain hosted on Windows using
Linux as the build machine but I'm running into the following error:
mips-elf-gcc -nostdinc -isystem /tmp/gccbuild/build/gcc/./gcc/include
-B/tmp/gccbuild/build/gcc/mips-elf/newlib/ -isystem
Quite a few files in libiberty use XNEWVEC as a replacement for
malloc(), but the they are being paired with plain free(); XDELVEC is
not being used.
Is there some reason for the inconsistency, such as some transitional
issue, or should this be fixed?
Andrew Haley wrote:
Aaron W. LaFramboise wrote:
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails
with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107
When building libjava stacktrace.o on i386-pc-mingw32, bootstrap fails with:
./sysdep/backtrace.h: In function '_Unwind_Reason_Code
fallback_backtrace(_Unwind_Reason_Code (*)(_Unwind_Context*, void*),
_Jv_UnwindState*)':
./sysdep/backtrace.h:107: error: ISO C++ forbids taking address of
I am still seeing errors such as this bootstrapping trunk with -Werror.
I thought all of this was supposed to be resolved?
../../svn/gcc/bt-load.c: In function 'migrate_btr_defs':
../../svn/gcc/bt-load.c:1415: error: ISO C does not support the 'I64'
ms_printf length modifier
What needs to
Aaron W. LaFramboise wrote:
I am still seeing errors such as this bootstrapping trunk with -Werror.
I thought all of this was supposed to be resolved?
OK, this is http://gcc.gnu.org/PR25502
Sorry for the noise.
Apparently the reason this has gone on so long is that most people
Richard Li wrote:
Right, page 211 of the C++ standard (2003) explains when copy-ctor and
dtor are allowed to be optimized away. But the two circumstances are
both like this:
A is constructed; A is copy-constructed to B; A is destructed
Here A is a temporary object in some sense, and the
Michiel de Bondt wrote:
Using strings to show my point was not a good idea. You can add a field
int number to the struct and perform similar operations (with =
instead of strcpy).
But even with strings, gcc should give an error like: strcpy(const
char*, const char*) does not exists. In case
michael.a wrote:
So in closing, I'm interested in any ideas / advice, but compromising the
existing codebase is completely out of the question. You have my
appreciation in advance naturally...
I suspect the proper solution here is something from www.boost.org. You
didn't say exactly what
Aaron Gray wrote:
One issue that might affect many some is that COM doesn't work.
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=27067 has a patch that
is pending review I guess, but probably won't go into 4.2.
Does this effect XPCOM meaning Mozilla and friends will not compile ?
It is
I discovered PR29365 today while testing 4.2.0 RC2 on a client's
codebase. This causes some of my code, based on the popular pimpl
idiom, to generate warnings, even with no warning flags specified. If
there's a way to turn it off without patching the source, I can't find it.
Given the
Jason Merrill wrote:
Sergio Giro wrote:
I perceived that many people think that the throw qualifiers, as
described by the standard, are not useful
Yes. But that's not a reason to add a slightly different non-standard
feature that would require people already using standard exception
Brian Dessent wrote:
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
Brian Dessent wrote:
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
I send a message to John Elliott's listed address yesterday, and I have
not yet received an immediate response. I will post to this list if I
receive anything from him.
So, I'd caution anyone away from basing any work on the dsPIC port until
some specific understanding is established with
François Poulain wrote:
I think so. Microchip have done a modified version of GCC-3.3 with
DSPICs support, so we have got a heavy good base to work on the
instruction set, wich is similar for PIC18. DSPIC is a 16 bit CPU, so is
memory isn't segmented.
Just as a reminder, even though the
François Poulain wrote:
If I'm right, here are copyright assignments to FSF for the Microchip's
contributions for GCC.
Unfortunately, this is not good enough. A copyright assignment is a
formal contract that must be physically signed and sent to the FSF. See
I have also recently become interested in a GCC port for the 18F.
Can someone summarize who--if anyone--is working on this, how much
progress he has made so far (Is his work based on mainline?), and any
expected future milestones?
(And who are all of the people in the CC list? Is there some
Colm O' Flaherty wrote:
Have you checked out SDCC? This may support the specific devices you're
interested in. For my part, I'm more interested in a GCC port than SDCC
though, as I feel there is an awful lot more to be gained from a gcc
port in the longer term.
As near as I can tell, the
, and so it can do special stuff.
But thank you guys for your help; it answers my question.
Aaron W. LaFramboise
that the difference is that PECOFF weak externals can be
resolved by definitions anywhere in the final link, while your new weak
references can only be overriden by definitions within the same
translation unit. Does this seem correct?
Thanks,
Aaron W. LaFramboise
Targets, such as Windows, that don't have getopt() will probably have
get the following error when compiling binutils.
gcc -DHAVE_CONFIG_H -I.
-I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I. -D_GNU_SOURCE
-I. -I/aaronwl/cs/compilers/binutils/src/cvs/src/binutils -I../bfd
awful about this is that the interesting portion, Level III
http://www.codesourcery.com/cxx-abi/abi-eh.html#imp-intro, is
basically empty.
I'm also interested in any overview-level information about the Dwarf2
unwinding mechanism.
Aaron W. LaFramboise
26 matches
Mail list logo
