[uClibc]Building uClibc...

Manuel Novoa III mjn3 at uclibc.org
Sun Jun 10 17:02:26 UTC 2001


Tom...

On Sat, Jun 09, 2001 at 10:00:11AM -0400, Tom Cameron wrote:
> Hello all,
> 	It seems every time I refresh my copy of uClibc against CVS,
> something drastic about the way I compile it has changed...and every time it
> bets more and more broken.

Actually it is getting less and less broken.  After batting things back
and forth with Erik, I reworked the install stuff so that you can install
the development environment anywhere you want.  You can also install the
target runtime environment in a directory tree for ease in moving to the
target platform.  You no longer need to be root to install either a
development or a runtime environment.

>         I'm trying to build uClibc, NOT install it on
> the local machines, and build apps against it.

It would be a lot easier on you if you just installed the development
environment and modified your path when you wanted to build uClibc apps.
Erik set up a number of helpful symlinks that are created by the install
to make building apps a lot easier.  And with the new install stuff, you
have more flexibility regarding directory paths on both the host and
the target.  Finally, working with uClibc this way should (now) protect
you from changes in layout of the source tree; saving you work in the
long run.

Of course, you can still build against an uninstalled uClibc.  Apparently
you haven't read the comments in the gcc wrapper code as was suggested by
the README.  By either renaming the wrapper or by setting the UCLIBC_GCC
environment variable, you can force the wrapper to build vs the uninstalled
version.

>         Instead what I get is
> "Gee...I'm sorry...but you know that whole crt0.o thing...yeah...well...I
> can't find it...so I'm not going to compile ANYTHING".  This is on my
> initial build...so it completely boggles my mind as to why _uClibc_ can't
> find something it _just_ compiled!  Of course it's not in /usr/lib or some
> place like that...I haven't run the install yet...and I don't plan on it
> either.

Or what... you'll hold your breath until you turn blue?  Whining is _not_
constructive, and continuing it it will get you introduced to my spam filter.

<RANT>
I work on uClibc as a hobby.  I don't get paid for it.  I don't use it for
anything other than personal projects.  In spite of this, there are parts
of uClibc that I've worked on, not because I needed them at the time, but
because they needed to be done for uClibc to move forward and because no
one else seemed willing to do them.  There have been times when I've stopped
what I was doing just to fix a bug someone reported.  It is bad enough
that, while the number of users has increased, few seem willing to step
up and contribute to the project.  But, WHINING IS INTOLERABLE!!!  You
should be ashamed!!!
</RANT>

As we move closer to a 1.0 release, it is important that we be able to
install the development environment.  I'm sure there will be people who
will want to use uClibc, but who won't care about the source.  After all,
how often do you build apps vs an uninstalled-but-built version of glibc?

If you think there are things broken regarding the install process,
bring them up.  We _want_ to fix things as we move to a release.

Of course, you are free to continue using uClibc without installing it.
But remember... building against an uninstalled uClibc is a _feature_,
primarily meant to aid in development.  It isn't the intended mode of use.
If you choose to do so, you have to do the work on your own to keep up
with changes.  I for one have neither the time or the inclination for
hand holding.

> 	What do you all suggest I do to the Makefile and Rules files to
> change this behavior?

You don't have to change these files to get the behavior your asking for.
All you need to do is set an environment variable, as is described in the
gcc wrapper comments (pointed to by the README).  But as you hadn't
discoverd that fact on your own, perhaps you should reconsider you
decision not to install.

>         Any suggestions are, as always, GREATLY appreciated!

If you're going to play with development code, expect there to be work
involved.

Manuel





More information about the uClibc mailing list