Re: [uCsimm] nope I really am having trouble (uC-src-0.9.2)

From: Andrew Kohlsmith (
Date: Sun Sep 24 2000 - 20:30:47 EDT

> If you are trying to build a kernel image then you must do a 'make
> menuconfig', at least once, even if you do not change things, then save
> the config out when you quit. Next, you do a 'make dep', followed by a
> 'make linux.bin', this process deviates from the normal 2.2 make
> sequence where you want the linux binary image to be built, rather than
> a bZimage / install.

Yes -- I've gotten to the point where I've made a new kernel and used the
distributed romdisk (whose login password is different!) but when I went to
actually compile the romdisk files instead of using the binaries supplied, I
run into the problem.

Until this point I have not used buildenv.

After using buildenv I have the same problem. However I thought I'd give it
all another shot, so I rebuild the kernel from the supplied sources as well
as uC-libc and uC-libm. I am seeing the same problem building uC-libc,
which makes me wonder if it worked teh first time around and I had just not
noticed it.

The problem (doing a make in uC-libc:)
[quite a lot of compile info, and a LOT of "warning: xxx (eg __FD_ISSET)
redefined) warnings], then the failure:

clnt_tcp.c: In function `readtcp':
clnt_tcp.c:407: structure has no member named `__bits'
clnt_tcp.c:419: warning: passing arg 3 of `select' from incompatible pointer
clnt_tcp.c:419: warning: passing arg 4 of `select' from incompatible pointer
make[1]: *** [clnt_tcp.o] Error 1
rm clnt_simple.o clnt_raw.o auth_unix.o authunix_prot.o bindresvport.o
auth_none.o clnt_generic.o clnt_perror.o
make[1]: Leaving directory `/opt/uClinux/uC-libc/rpc'
make: *** [rpc] Error 2

This is precisely the same error I get when trying to build the romdisk

Something I have noted is that all the redefinitons seem to come from
types.h in the include/gnu subdirectory conflicting with
include/linux/posix_types. Is this normal?

> There is something to be said about installing the stock RPMs first, get
> familiar with the concept of the gcc cross-compile environment, THEN,
> attempt to 'do it by hand'. Why not set up a working environment from
> the RPMs, verify its' operation, take another "clean" machine and
> attempt to build the environment from sources + patch files? This is
> the primary purpose of my laptop computer, it becomes the victum machine
> for this kind of work and also testing of RPM builds. It is a worthy
> thing to want to experiment / challange ones own self, but, isn't
> 'cheating' allowed? ;-0

In a word, no. :-) While I know that Slack now has the RPM utility and
utils like alien exist, RPM is just plain nasty in my opinion. 'sides, I
have cross-compiled before (uClinux/Coldfire to be exact), I think I just
have forgotten something dumb here.

Thanks for the informative reply, I hadn't really taken a good look at
buildenv until now and it looks like it can simplify this greatly!

This message resent by the list server

This archive was generated by hypermail 2b30 : Sun Apr 07 2002 - 00:01:38 EST