[uClibc] where did the wrappers go?
Charlie Brady
charlieb-uclibc at e-smith.com
Wed Dec 24 03:05:20 UTC 2003
On Tue, 23 Dec 2003, Carl Miller wrote:
> > > - "ld --nostdinc" apparently can't be trusted to only look where you tell
> > > it for libraries.
[BTW, I meant "gcc --nostdlib".]
> > > Let's start with my first question: why do we need binutils specially
> > > built for uclibc? (I can't see anything different in Mr Hill's binutils,
> > > other than the names of the executables).
...
> And don't forget:
> http://sources.redhat.com/ml/crossgcc/2003-12/msg00144.html
> http://sources.redhat.com/ml/crossgcc/2003-12/msg00150.html
>
> (that same set of patches, minus the ones to crosstool, were also posted
> to this list at roughly the same time)
>
> Heh-heh, yes, trying to simplify toolchain building, though by making
> binutils, gcc, and crosstool specifically recognize uClibc, rather than
> by making library-agnostic tools. That's a far more ambitious goal, I
> think. My hat's off to you if you can pull it off. Though that is a
> good point -- the binutils patches I posted don't actually change anything
> other than target tuple recognition. The generated binutils, once built,
> should behave exactly the same whether configured for *-*-linux-uclibc or
> *-*-linux-gnu.
And Steven Hill's RPMs don't do anything like that to binutils. AFAICT,
the only thing different about the binutils in his RPM are the pathnames
of the executables.
I'm trying to understand which patches are essential to building working
executables and which are simply a convenience. Everything that I've seen
so far can be handled by using a non-standard spec file at run time (via
--spec xxxx). One possible exception is the issue that Erik refers to of
persistent searches of /lib and /usr/lib, which only happens with native
compilers, and only because of special case code in gcc/gcc.c - which
isn't necessary, as it can be done via the standard spec files.
Feel free to correct me if I am wrong, or to supplement my knowledge if
you can.
Has anyone tried to build uClibc and uClibc executables with a glibc
native compiler and non-standard spec file?
--
Charlie
More information about the uClibc
mailing list