On Apr 12, 2007, at 10:17 PM, Daniel Berlin wrote:
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]>
wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
T
On 12 Apr 2007 15:14:01 -0700, Geoffrey Keating <[EMAIL PROTECTED]> wrote:
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++.
The FSF libstdc++ is, I believe,
binary incompatible wit
I didn't just pull this out of a hat, you know :-) Where do you think
it's going to install the library if you do that?
Yeah, I know. I said it wasn't a good patch, but I was on my way out
of the office for the evening and wanted to get Doug something and
have you look at the code too :)
On Thu, Apr 12, 2007 at 04:43:23PM -0700, Eric Christopher wrote:
> The basic idea is that the darwin code uses slibdir to set the install name
> of
> the library - including full path. Yes, this is dumb, but it's the way that
> darwin does things at the moment. :(
That much is reasonable but..
That said, though, there's something weird going on in your build that
should probably be tracked down. It didn't happen to me last time I
built...
Here's a patch that fixes it though it doesn't fix the testsuite
results yet and is likely not quite what Daniel will want...
Dan?
The basic
I would recommend using the system libstdc++ and system libgcc_s
rather than one you build yourself from FSF sources, unless you're
actually developing libstdc++. The FSF libstdc++ is, I believe,
binary incompatible with the system one, and since system libraries
use the system one there is no way
When bootstrapping a mainline compiler on i386-apple-darwin8.8.1, we
are linking libstdc++.dylib incorrectly. My understanding of the
build machinery behind libstdc++ is very poor, so here's what I've
found.
The symptom of the problem is a warning from the Darwin linker when
trying to bui