[PATCH] configure: check for libstdc++ and zlib, dynamic and static
Sat Jan 22 08:55:00 GMT 2011
On Sat, Jan 22, 2011 at 12:28 AM, Anthony Foiani
> Bryan --
> On Sat, Jan 22, 2011 at 12:25 AM, Bryan Hundven <email@example.com> wrote:
>>> Sorry about the duplicate work; I just now saw your mail, right after
>>> sending my patch to handle at least part of the same problem.
>> I like seeing that there is more then one way to fix a problem.
>> Which configuration did you build to need these fixes?
> The latter of the two you mention: powerpc-e500v2-linux-gnuspe
> (On Fedora 14 x86-64, although I don't think it matters quite so much
> for this issue, other than the "static libs are a separate package"
>> Your change makes me ask: Do we need libstdc++.a for a certain
>> configuration? Or for all?
> Unfortunately, I don't know. It seems that *something* on the host
> side wants libstdc++ for static linking; exactly what, I don't recall.
> (I suppose I can erase that package and recompile, to see what
> Interesting; looks like the static lib is a part of -devel for F13
> (and, presumably, earlier), but not on F14.
> Anyway. Running the experiment now. Will try to update this thread
> as I find out what breaks. :)
Hmm. So Debian and Fedora (<=FC13) have previously packaged
libstdc++.a in the dev packages. Maybe this points to all toolchains
needing it and we never noticed because it was always installed.
Suspicions aren't as good as testing though.
>> The only configuration that I have noticed it on so far was this
>> powerpc-405-linux-gnu and powerpc-e500v2-linux-gnuspe. I would like to
>> try a few more configurations.
>> If we really need libstdc++.a for all toolchains, then we should add
>> it to the configure file. Otherwise, we should warn about it being
>> missing for this and/or other affected configurations until a better
>> solution can be formed. (bug?)
> Perhaps. Again, I have to make apologies for the fact that I can only
> make patches for items which are show-stoppers for me; I hope that
> they're useful to others, but unfortunately I'm not in a position to
> do exhaustive fixing. :(
I think it was rhetorical. I don't know if I can say that if it came
down the possible-issue-tree this far that I can honestly say that I
_will_ be able to fix the problem, but I will try my best to at least
> Thanks for all the work you've been adding to ct-ng lately!
> Best regards,
For unsubscribe information see http://sourceware.org/lists.html#faq
More information about the crossgcc