On Mon, Aug 11, 2008 at 03:53:47PM -0400, Benjamin Reed wrote:
> Jack Howarth wrote:
> | Benjamin,
> | If it is a 10.5-gcc-4.2 branch, I would assume by default it
> | would be an opt in. Besides, I would surprised if Apple doesn't switch
> | the default compiler to gcc-4.2 for Snow Leopard so
Martin Costabel wrote:
> Benjamin Reed wrote:
>> []
>> As I'm not a compiler guru, I must be missing something. Is PPL
>> something that is part of the GCC build? Googling "PPL" gives me a
>> million false positives.
>
> And "fink apropos ppl" shows nothing called "ppl".
> What *is* ppl?
>
htt
Benjamin Reed wrote:
>[]
> As I'm not a compiler guru, I must be missing something. Is PPL
> something that is part of the GCC build? Googling "PPL" gives me a
> million false positives.
And "fink apropos ppl" shows nothing called "ppl".
What *is* ppl?
--
Martin
-
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jack Howarth wrote:
|I also recall having one of my bug reports against code
| generation of the Apple gcc 4.0.1 compiler closed with a
| comment that the compiler was depreciated or such. I agree
| that we can just build ppl > 0.9 with gcc-4.2 bu
Benjamin,
The current Xcode 3.1.1 DP1 can't compile the ppl cvs.
The response from the ppl developer was...
---
Jack Howarth wrote:
>The ppl cvs only builds with the newer Apple gcc-4.2 compiler
> in Xcode 3.1. Under the default gcc 4
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
Jack Howarth wrote:
|We will have to give some serious consideration to
| using Apple gcc-4.2 compiler from Xcode >= 3.1 shortly.
| The ppl cvs which will become the next ppl release requires
| gcc > 4.0.3 to build. This means that ppl > 0.9 will n
We will have to give some serious consideration to
using Apple gcc-4.2 compiler from Xcode >= 3.1 shortly.
The ppl cvs which will become the next ppl release requires
gcc > 4.0.3 to build. This means that ppl > 0.9 will no
longer build against Apple's stock gcc 4.0.1 compiler.
It does build fine
-BEGIN PGP SIGNED MESSAGE-
Hash: RIPEMD160
Jim White wrote:
| Martin Costabel wrote:
|
|> David R. Morrison wrote:
|>
|> []
|>
|>>> (3) The problems with octave, singular-libfac and others that cannot
|>>> be built with Apple's latest g++-3.3 are too fresh in the discussion
|>>> to have to
Martin Costabel wrote:
David R. Morrison wrote:
[]
(3) The problems with octave, singular-libfac and others that cannot
be built with Apple's latest g++-3.3 are too fresh in the discussion
to have to be recalled, but they are real and urgent problems that
have to be solved. Telling people "Don't
David R. Morrison wrote:
[]
(3) The problems with octave, singular-libfac and others that cannot
be built with Apple's latest g++-3.3 are too fresh in the discussion
to have to be recalled, but they are real and urgent problems that
have to be solved. Telling people "Don't install Xcode-1.5 if y
David R. Morrison wrote:
Seems like a good case for a fink package, then.
I am suddenly reminded of a GNU libtool bug report I got about a year ago
and then completely forgot about (having, of course, promised to fix it).
GNU gcc does not grok __private_extern__ and builds libstdc++ and libgcc
On Aug 26, 2004, at 4:20 AM, Martin Costabel wrote:
[snip]
This is not a discussion about philosophy or policy, but about how to
deal with buggy software.
Absolutely correct. Thanks for the detailed response.
3. The recent versions of gcc seem to be sufficiently binary
compatible so that you can
Jack Howarth wrote:
Martin,
Just a stab in the dark, but have you considered trying to rebuild
octave with -fssa and -fssa-dce? Perhaps using the experimental dead
code elimination will work around the missing symbols.
In the test case from singular-libfac this doesn't change anything.
--
Martin
Martin,
Just a stab in the dark, but have you considered trying to rebuild
octave with -fssa and -fssa-dce? Perhaps using the experimental dead
code elimination will work around the missing symbols.
Jack
---
SF.Net ema
Jack Howarth wrote:
Martin,
Has anyone documented a few of these g++ problems and brought
them up on the darwin-development mailing list at Apple? I have
found that the Apple devtool programmers that monitor that list
can often be quite helpful. At the very least, it will bring these
problems t
Martin,
Has anyone documented a few of these g++ problems and brought
them up on the darwin-development mailing list at Apple? I have
found that the Apple devtool programmers that monitor that list
can often be quite helpful. At the very least, it will bring these
problems to their attention fo
Martin Costabel wrote:
[]
(3) The problems with octave, singular-libfac and others that cannot be
built with Apple's latest g++-3.3 are too fresh in the discussion to
have to be recalled, but they are real and urgent problems that have to
be solved.
From having a quick look over the #fink logs,
Daniel Macks wrote:
[]
I think we'd be setting ourselves up for a user support nightmare
At least we would have to think of a system how to avoid this. I also
tend to think (but I am not yet sure about this) that it would probably
be a bad idea to completely replace (for building Fink packages) A
On Thu, Aug 26, 2004 at 01:24:58AM +0200, Max Horn wrote:
> Am 25.08.2004 um 19:40 schrieb David R. Morrison:
> >
> >The troubles with g++ under XCode 1.5 and the lack of any quick
> >response from Apple, combined with earlier incidents of an analogous
> >nature, lead me to ask: would we be bette
Am 25.08.2004 um 19:40 schrieb David R. Morrison:
The troubles with g++ under XCode 1.5 and the lack of any quick
response from Apple, combined with earlier incidents of an analogous
nature, lead me to ask: would we be better off with a fink gcc package
in place of the Developer Tools? As I und
The troubles with g++ under XCode 1.5 and the lack of any quick
response from Apple, combined with earlier incidents of an analogous
nature, lead me to ask: would we be better off with a fink gcc package
in place of the Developer Tools? As I understand it, the Apple
compiler team has been good
21 matches
Mail list logo
