build problem

build problem

[Ken Martwick]

I just tried a "test-compile" of the v.0.1.0 kernel with
the default configuration.  The compilation failed with
the following error messages:
 
make[3]: Entering directory `/usr/src/elks-0.1.0/arch/i86/tools'
gcc -I ../../../include -o build build.c
/tmp/cca005671.o: In function `main':
/tmp/cca005671.o(.text+0x152): undefined reference to `major'
/tmp/cca005671.o(.text+0x16c): undefined reference to `minor'
/tmp/cca005671.o(.text+0x1e3): undefined reference to `major'
/tmp/cca005671.o(.text+0x1fd): undefined reference to `minor'
collect2: ld returned 1 exit status
make[3]: *** [build] Error 1
make[3]: Leaving directory `/usr/src/elks-0.1.0/arch/i86/tools'
make[2]: *** [toolkit] Error 2
make[2]: Leaving directory `/usr/src/elks-0.1.0/arch/i86'
make[1]: *** [Image] Error 2
make[1]: Leaving directory `/usr/src/elks-0.1.0'
make: *** [elks] Error 2
 
I can't find the difference, as v.0.0.84 compiles without
problems and build.c seems to be very similar.  Can anyone
shed any light on this problem?
 
Ken Martwick

Re: build problem

[Javier Sedano]

Ken Martwick wrote:
> [...]
> /tmp/cca005671.o(.text+0x152): undefined reference to `major'
> [...]
> collect2: ld returned 1 exit status
> [...]
> I can't find the difference, as v.0.0.84 compiles without
> problems and build.c seems to be very similar.  Can anyone
> shed any light on this problem?
> 

	Check the error again: build.c has been sucessfully compiled, so the
problem is not that. It can not find the reference to major, which is
probably defined in other .c file, and needs to be linked to build the
main binary. ld is who is failing, not bcc.

	By the way, I don't know how to solve the problem ;-)

-- 
Multi-Tasking: vease cuarto de baño
--------
Javier Sedano Jarillo      http://www.it.uc3m.es/~jsedano
 jsedano@dit.upm.es (*)
 jsedano@ieee.org
-
To unsubscribe from this list: send the line "unsubscribe linux-8086" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html

Re: build problem

[Riley Williams]

Hi Ken.

> I just tried a "test-compile" of the v.0.1.0 kernel with the default
> configuration. The compilation failed with the following error messages:
>
> make[3]: Entering directory `/usr/src/elks-0.1.0/arch/i86/tools'
> gcc -I ../../../include -o build build.c
> /tmp/cca005671.o: In function `main':
> /tmp/cca005671.o(.text+0x152): undefined reference to `major'
> /tmp/cca005671.o(.text+0x16c): undefined reference to `minor'
> /tmp/cca005671.o(.text+0x1e3): undefined reference to `major'
> /tmp/cca005671.o(.text+0x1fd): undefined reference to `minor'
> collect2: ld returned 1 exit status
> make[3]: *** [build] Error 1
> make[3]: Leaving directory `/usr/src/elks-0.1.0/arch/i86/tools'
> make[2]: *** [toolkit] Error 2
> make[2]: Leaving directory `/usr/src/elks-0.1.0/arch/i86'
> make[1]: *** [Image] Error 2
> make[1]: Leaving directory `/usr/src/elks-0.1.0'
> make: *** [elks] Error 2
>
> I can't find the difference, as v.0.0.84 compiles without problems
> and build.c seems to be very similar. Can anyone shed any light on
> this problem?

I can't shed any definite light on this, as the 0.1.0 kernel compiles
without any problems at all here. However, one possibility is that you
have old versions of one or more of the utilities used to build the ELKS
kernel. Here's a checklist of what is installed here. First, the output
from the ver_linux script included with just about every Linux kernel:

 Q> If some fields are empty or look unusual you may have an old version.
 Q> Compare to the current minimal requirements in Documentation/Changes.
 Q>  
 Q> Linux Consulate.UFP.CX 2.2.14-e2c #5 Tue Jan 25 21:06:15 GMT 2000 i586 unknown
 Q>  
 Q> Gnu C                  egcs-2.91.66
 Q> Gnu make               3.78.1
 Q> binutils               2.9.5.0.22
 Q> util-linux             2.10f
 Q> mount                  2.10r
 Q> modutils               2.3.21
 Q> e2fsprogs              1.18
 Q> PPP                    2.3.11
 Q> Linux C Library        1.3.so*
 Q> Dynamic linker (ldd)   2.1.3
 Q> Procps                 2.0.7
 Q> Net-tools              1.55
 Q> Console-tools          0.3.3
 Q> Sh-utils               2.0
 Q> Modules Loaded         ppp slip slhc parport_pc lp parport tulip ne2k-pci 8390 nls_iso8859-1 nls_cp437 vfat fat

In addition to the above, I run under Red Hat 6.2 and have the
dev86-0.15.0-2.i386.rpm package installed. I presume that holds version
0.15.0 of the as86, bcc and ld86 tools, but none of them appear to have
a version command so I can't confirm that.

Best wishes from Riley.

Re: build problem

[Riley Williams]

Hi Ken.

> There could very possibly be some problem related to the Linux
> version; I am running Slackware 3.5 (2.0.34 kernel) but what bothers
> me is that I had no problem compiling v.0.0.84. In fact, playing
> tricks with file time stamps allows a successful compilation of
> v.0.1.0 if the "build" from v.0.84.0 is substituted so that "make"
> sees it as already compiled!

That indicates that the problem is to do with compiling build.c and that
would make sense. I've just checked the CVS tree, and it makes for
interesting reading regarding this particular file...

 Q> ===================================================================
 Q> File: build.c          	Status: Up-to-date
 Q> 
 Q>  Working revision:		1.5
 Q>  Repository revision:	1.5	/cvsroot/elks/elks/arch/i86/tools/build.c,v
 Q>  Sticky Tag:		(none)
 Q>  Sticky Date:		(none)
 Q>  Sticky Options:		(none)
 Q>
 Q>  Existing Tags:
 Q> 	elks-0_1_0               	(revision: 1.5)
 Q> 	elks-0_1_0-pre4          	(revision: 1.4)
 Q> 	elks-0_1_0-pre2          	(revision: 1.2)
 Q> 	elks-0_0_88              	(revision: 1.2)
 Q> 	elks-0_0_88-pre1         	(revision: 1.2)
 Q> 	elks-0_0_87              	(revision: 1.2)
 Q> 	elks-0_0_87-pre1         	(revision: 1.2)
 Q> 	elks-0_0_85-pre3         	(revision: 1.1.1.1)
 Q> 	V0-0-85-PRE3             	(revision: 1.1.1.1)
 Q> 	ANSI-C                   	(branch: 1.1.1.1.6)
 Q> 	elks-0_0_85-pre2         	(revision: 1.1.1.1)
 Q> 	elks-0_0_85-pre1         	(revision: 1.1.1.1)
 Q> 	elks-0_0_83              	(revision: 1.1.1.1)
 Q> 	elks-0_0_82              	(revision: 1.1.1.1)
 Q> 	psion_port               	(branch: 1.1.1.1.4)
 Q> 	elks-0_0_81              	(revision: 1.1.1.1)
 Q> 	rom_code_boot            	(branch: 1.1.1.1.2)
 Q> 	elks-0_0_80              	(revision: 1.1.1.1)
 Q> 	elks-0_0_80-pre1         	(revision: 1.1.1.1)
 Q> 	elks-0_0_79              	(revision: 1.1.1.1)
 Q> 	elks-0_0_78              	(revision: 1.1.1.1)
 Q> 	elks-0_0_76              	(revision: 1.1.1.1)
 Q> 	elks-0_0_75              	(revision: 1.1.1.1)
 Q> 	elks-0_0_74-pre1         	(revision: 1.1.1.1)
 Q> 	elks-0_0_73-pre2-start   	(revision: 1.1.1.1)
 Q> 	elks-0_0_73              	(revision: 1.1.1.1)
 Q> 	elks                     	(branch: 1.1.1)

We see that from the ELKS tree being imported into the CVS up until
0.0.85-pre3 was tagged, this file had not changed. Somewhere between
then and 0.0.87-pre1 being tagged, a comment was reformatted, but the
code itself was not changed. It doesn't make sense for that to be the
problem. As a result, this problem you are having should not show up
prior to 0.1.0-pre2 as no further changes took place before then.

Revision 1.3 isn't explicitly tagged, but the tweak between 0.1.0-pre2
and revision 1.3 consisted of the following:

Index: build.c
===================================================================
RCS file: /cvsroot/elks/elks/arch/i86/tools/build.c,v
retrieving revision 1.2
retrieving revision 1.3
diff -u -5 -w -r1.2 -r1.3
--- build.c	4 Oct 2001 21:06:51 -0000	1.2
+++ build.c	20 Jan 2002 22:30:47 -0000	1.3
@@ -24,11 +24,10 @@
 #include <stdio.h>			/* fprintf */
 #include <string.h>
 #include <stdlib.h>			/* contains exit */
 #include <sys/types.h>			/* unistd.h needs this */
 #include <sys/stat.h>
-#include <sys/sysmacros.h>
 #include <unistd.h>			/* contains read/write */
 #include <fcntl.h>
 #include "a.out.h"
 #include <errno.h>
 #include <linuxmt/config.h>

===================================================================

This simply consists of removing a header file. On my system, this
header file defines macros for major(dev) and minor(dev) to suit the
compiler being used, and both macros are used in this file, so that
is certainly a possibility. Between revision 1.3 and the 0.1.0-pre4
release, we find the following changes:

Index: build.c
===================================================================
RCS file: /cvsroot/elks/elks/arch/i86/tools/build.c,v
retrieving revision 1.3
retrieving revision 1.4
diff -u -5 -w -r1.3 -r1.4
--- build.c	20 Jan 2002 22:30:47 -0000	1.3
+++ build.c	24 Feb 2002 17:29:00 -0000	1.4
@@ -27,11 +27,11 @@
 #include <sys/types.h>			/* unistd.h needs this */
 #include <sys/stat.h>
 #include <unistd.h>			/* contains read/write */
 #include <fcntl.h>
 #include "a.out.h"
-#include <errno.h>
+#include <linuxmt/errno.h>
 #include <linuxmt/config.h>
 
 #define MINIX_HEADER 32
 
 #define N_MAGIC_OFFSET 1024

===================================================================

This could easily be wrong, as it replaces the include of the Linux
version of errno.h with that of the ELKS version of the same file. Since
build.c is one of the tools used to compile ELKS rather than something
supplied with ELKS, this looks wrong to me, so could you try reverting
this particular change on your system and see whether it matters?

The changes between 0.1.0-pre4 and 0.1.0 itself are entirely formatting
changes made as part of ANSI'fying the ELKS source code. In each case,
two or more statements on a single line have been rewritten on separate
lines, but the statements themselves have not changed in the slightest,
so that is unlikely to be the problem.

I have to conclude that one of the above patches is the faulty one, and
reverting it will fix this problem. Perhaps you could try that and
confirm which is the case, and I can then revert it and fix the problem
in the CVS tree as well.

Best wishes from Riley.

Re: build problem

[Ken Martwick]

Hi Riley,
You wrote, in part:
 
> I have to conclude that one of the above patches is the faulty
> one, and reverting it will fix this problem. Perhaps you could
> try that and confirm which is the case, and I can then revert it
> and fix the problem in the CVS tree as well.
> Best wishes from Riley.
 
The "#include <sys/sysmacros.h>" was the crucial omission.  It is
hard to see how the program would compile without it, but there
certainly could be alternative include paths in later Linux source
trees.
Ken Martwick

Re: build problem

[Riley Williams]

Hi Ken.

>> I have to conclude that one of the above patches is the faulty one,
>> and reverting it will fix this problem. Perhaps you could try that
>> and confirm which is the case, and I can then revert it and fix the
>> problem in the CVS tree as well.

> The "#include <sys/sysmacros.h>" was the crucial omission.

I've now patched the CCVS tree to revert that change, and I've credited
you with finding it...

> It is hard to see how the program would compile without it, but
> there certainly could be alternative include paths in later Linux
> source trees.

I would presume that the include files in some distributions include
that particular header in one of the other headers that are included.
However, it's protected from multiple inclusion, so it doesn't hurt to
explicitly include it in those cases.

Best wishes from Riley.