[PATCH] configure: check for libstdc++ and zlib, dynamic and static

Bryan Hundven bryanhundven@gmail.com
Sat Jan 22 08:55:00 GMT 2011

On Sat, Jan 22, 2011 at 12:28 AM, Anthony Foiani
<anthony.foiani@gmail.com> wrote:
> Bryan --
> On Sat, Jan 22, 2011 at 12:25 AM, Bryan Hundven <bryanhundven@gmail.com> wrote:
>> Tony,
>>> 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.
> Heh.
>> 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"
> problem.)
>> 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
> dies...)
> 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
understand it.

> Thanks for all the work you've been adding to ct-ng lately!


> Best regards,
> Tony


For unsubscribe information see http://sourceware.org/lists.html#faq

More information about the crossgcc mailing list