Hi everyone,
HEAD isn't building for me right now. Since I haven't tried building
graphite-enabled GCC before, I may be doing something wrong, so I figured I'd
ask questions before opening any PR. (The actual questions are numbered for
those who want to skip the detail.)
I followed the
Hello Dave,
Thanks for testing Graphite on i686-pc-cygwin.
On Mon, Jan 12, 2009 at 9:52 AM, Dave Korn
wrote:
>Hi everyone,
>
> HEAD isn't building for me right now. Since I haven't tried building
> graphite-enabled GCC before, I may be doing something wrong, so I figured I'd
> ask question
Sebastian Pop wrote:
Hi Seb,
>> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
>> patches for the first two bugs if desired,
>
> I would highly appreciate this.
Righto, will get cracking.
>> but the third part has me totally confused, I don't know what to do
>>
Dave Korn wrote:
> Sebastian Pop wrote:
>
> Hi Seb,
>
>>> Anyway, TIA for any enlightenment anyone can provide. I could file PRs or
>>> patches for the first two bugs if desired,
>> I would highly appreciate this.
>
> Righto, will get cracking.
You already posted a patch for the first one
Sebastian Pop wrote:
Q3) Why is there C++ in my libppl? Have I done something wrong to get it
there in the first place, or is it supposed to work somehow?
At the end of stage 1, I can work around the problem by manually running
the final link command, but using the (native compiler's) g++ dri
On Mon, 12 Jan 2009, Roberto Bagnara wrote:
> I am not sure I understand the question (and I am not familiar with Cygwin).
> The answer to the question "Why is there C++ in my libppl" is that libppl
> is written in C++. The C interface to the PPL, libppl_c, is also written
> in C++. Your descrip
Joseph S. Myers wrote:
> On Mon, 12 Jan 2009, Roberto Bagnara wrote:
>
>> I am not sure I understand the question (and I am not familiar with Cygwin).
>> The answer to the question "Why is there C++ in my libppl" is that libppl
>> is written in C++. The C interface to the PPL, libppl_c, is also wr
On Mon, Jan 12, 2009 at 2:25 PM, Dave Korn
wrote:
> Yep. It particularly shows up on win32 because i) all references have to
> be resolved at final link time in an executable - perhaps by reference to a
> DLL, but they can't just be left dangling to be filled in at runtime by the
> loader as th
Dave Korn wrote:
Roberto, what does ldd show on the various cc1 binaries in the different
stage directories of your most recent bootstrap? I'm guessing you'll see that
the stage 2 cc1 is linked against the system libstdc++ rather than the
newly-bootstrapped one.
$ find . -name cc1
./prev-gcc
