[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Bug#36075: libc6: Compiling Linux 2.2 under 2.0



On Wed, 14 Apr 1999 21:47:00 +0200 (CEST), "ERDI 'Cactus' Gergo" wrote:
>On Wed, 14 Apr 1999, Zack Weinberg wrote:
>
>> Also, what the hell are you doing compiling things as root?  The
>> Makefiles expect that you are an unprivileged user except for the
>> installation targets.
>Of course this has no relevance in this case, since with the EXACT SAME
>configuration, I was able to compile 2.2.5 when another 2.2.x kernel was
>booted.

Things that you think are `Of course' not the problem have a
depressing tendency to turn out to be the problem.  In particular,
privilege checking was completely redone in the 2.1 series, so it is
quite possible that you have some mildly out of spec configuration
which 2.2 accepts and 2.0 does not.

In any case, compiling the kernel as root breaks several assumptions
of the Makefiles; it remains a problem once you get past this one.
It is also a bad idea in general.

>> I'd try:
>> 
>> - Check versions of bash and make.  I have
>> 
>> ii  bash            2.02.1-1.4     The GNU Bourne Again SHell
>> ii  make            3.77-6         The GNU version of the "make" utility.
>ii  bash            2.02.1-1.4     The GNU Bourne Again SHell
>ii  make            3.77-6         The GNU version of the "make" utility.

Ok...

>> - Nuke your source tree.  Download a clean copy of 2.2.5.  
>Which is exactly what I did.
>> - Run `make mrproper' to ensure no stray files.  If the problem hasn't
>> been fixed, it will recur at this point.
>It is irrelevant what I try to make, since the parsing of the
>Makefile itself is what halts make.

That's what I said.

If you change the kernel and the problem goes away, then the problem
is logically with the kernel.  What patchlevel of 2.0 were you using?
Any exotic compile-time settings?  Were you able to compile things
successfully using that kernel and a previous version of libc?

If a bug exists in libc, the logical place will be in the
implementation of vfork (which has to be mapped to fork on 2.0
kernels).  However, examining this code, I see no way it can return
EINVAL.  Furthermore, it has been extensively tested on 2.0 systems
and works fine.

zw


Reply to: