Re: Static libc.a and weak __pthread_unwind symbol problem

[Mike Frysinger <vapier at gentoo dot org>]

On Monday, August 29, 2011 23:53:55 Bryan Ischo wrote:
> On 08/29/11 20:33, Mike Frysinger wrote:
> > On Monday, August 29, 2011 23:09:07 Bryan Ischo wrote:
> >> It is possible that what I am trying to do is invalid (use a static
> >> libc.a when creating a dynamic libgcc_s.so), but nobody has said that
> >> explicitly yet
> > 
> > it is wrong and really makes no sense.  you're bleeding glibc symbols
> > (public and private) into a completely unrelated library.
> 
> I realize that this may make no sense for a final version of the
> toolchain, but this is just an intermediate step where I don't mind
> bending some rules to get things to work.  That being said, I certiainly
> would not expect the build system to support doing things beyond the
> scope of what is correct so if what I am trying to do is not going to be
> supported by the toolchain for that reason, then I'm happy to give up on
> that approach.

the intermediate step is to build a compiler without shared libs.  they are 
not needed to build up glibc, and attempting to created shared libs with a 
static C library is going to fail.  as you've shown.

> >> I am happy to
> >> worth through the issues and fix them and to submit whatever
> >> improvements to the process that I have made either to documentation or
> >> to the code, or both.
> > 
> > then post patches to address the crosstool-ng failures
> 
> Why not improve the gnu compiler collection built-in build system to
> better support building cross-compilers without an external tool
> required?  Why don't the crosstool-ng people do what I am doing which is
> to work with the compiler toolchain itself rather than coming up with an
> external tool to do the job?  Of course some level of scripting is
> necessary but I'd prefer to put as much of the smarts as possible into
> the toolchain itself, so that external tools are not needed.  The more
> functionality is included in crosstools-ng that is not included in the
> toolchain just makes the process more and more dependent on this
> external tool.

you're clearly not familiar with the history, and are skipping over reality.  
(1) the patches *have* been posted but have gone ignored/unmerged.
(2) crosstool-ng deals with releases and making things actually work after 
they're out the door.  fixing the latest master branch doesnt fix the releases 
and thus doesnt actually make users' lives easier.

> Is it really unreasonable to expect that the gnu compiler toolchain
> should have a sane process for building cross-compilers that doesn't
> require an exernal program and sets of patches maintained outside of the
> source tree?

no it isn't unreasonable, but fact is, that is the reality we live in 
currently

also, keep responses on list.  i'm not interested in private conversations.
-mike

Attachment: signature.asc
Description: This is a digitally signed message part.