This is the mail archive of the libc-help@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Static libc.a and weak __pthread_unwind symbol problem


On 08/29/11 21:17, Mike Frysinger wrote:
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.

OK I'll try that approach. I think that at some point in the past I was trying to do that but gave up due to other issues. But if that's the right way to do it then I will do that.
you're clearly not familiar with the history, and are skipping over reality.
(1) the patches *have* been posted but have gone ignored/unmerged.

You are right, I am not familiar with the history. It is unfortunate that the patches are not accepted and that the toolchain maintainers have not ensured that this process is more sane; but then again, I realize that people building cross-compilers are in a very small minority and that those that do so typically are doing so as part of commercial ventures and could be reasonably expected to support themselves.


I did try crosstools-ng and it did build a gcc/binutils combo for x86_64 targeting mips. Of course, that is only part of the problem, glibc needs to be built too using that compiler but ostensibly that is not hard. And to replicate what my script does, which is to build a toolchain for an arbitrary host/target combo, I will have to script multiple invocations of crosstools-ng interspersed with additional builds of glibc, etc, making the whole process likely nearly as complicate as the script I already have. And furthermore, crosstools-ng isn't able to build gcc 4.6.1 yet (at least it's not in the current download) and I don't know what kind of issues that is going to introduce.

Thanks,
Bryan


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]