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.

build problem

[kapetr]

Hello,

I run Ubuntu 12.04 64b.
I'm using USB - ID 048d:9135 Integrated Technology Express, Inc. Zolid 
Mini DVB-T Stick

with linux-media build-ed drivers - as described here:
http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers


I just have to build it again after every kernel update - OK.

But last time - I have done the same as every time, but the build 
process failed:


$ git clone --depth=1 git://linuxtv.org/media_build.git
$ cd media_build/
$ ./build --verbose

but it ends with error

xxxxxxxxxxxxxxxxxxxxxxxxxxxx

...

******************
* Start building *
******************
make -C /home/hugo/tmp/media_build/v4l allyesconfig
make[1]: Entering directory `/home/hugo/tmp/media_build/v4l'
No version yet, using 3.2.0-61-generic
make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l'
make[1]: Entering directory `/home/hugo/tmp/media_build/v4l'
make[2]: Entering directory `/home/hugo/tmp/media_build/linux'
Applying patches for kernel 3.2.0-61-generic
patch -s -f -N -p1 -i ../backports/api_version.patch
patch -s -f -N -p1 -i ../backports/pr_fmt.patch
The text leading up to this was:
--------------------------
|diff --git a/drivers/media/usb/gspca/dtcs033.c 
b/drivers/media/usb/gspca/dtcs033.c
|index 5e42c71..ba01a3e 100644
|--- a/drivers/media/usb/gspca/dtcs033.c
|+++ b/drivers/media/usb/gspca/dtcs033.c
--------------------------
No file to patch.  Skipping patch.
1 out of 1 hunk ignored
make[2]: *** [apply_patches] Error 1
make[2]: Leaving directory `/home/hugo/tmp/media_build/linux'
make[1]: *** [allyesconfig] Error 2
make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l'
make: *** [allyesconfig] Error 2
can't select all drivers at ./build line 490.
xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx

Please help me to get my TV working again.


Thanks

--kapetr

Re: build problem

[Hans Verkuil]

On 05/07/2014 07:45 AM, kapetr@mizera.cz wrote:
> Hello,
> 
> I run Ubuntu 12.04 64b.
> I'm using USB - ID 048d:9135 Integrated Technology Express, Inc. Zolid 
> Mini DVB-T Stick
> 
> with linux-media build-ed drivers - as described here:
> http://linuxtv.org/wiki/index.php/How_to_Obtain,_Build_and_Install_V4L-DVB_Device_Drivers
> 
> 
> I just have to build it again after every kernel update - OK.
> 
> But last time - I have done the same as every time, but the build 
> process failed:
> 
> 
> $ git clone --depth=1 git://linuxtv.org/media_build.git
> $ cd media_build/
> $ ./build --verbose
> 
> but it ends with error

The archive ./build downloads is missing a file for some reason. It may be
a few days before it is fixed since the maintainer of that file is attending
a conference. I've told Mauro that it is broken.

In the meantime this should work, although it will be slow since it has to clone
the git tree:

./build --main-git

Regards,

	Hans

> 
> xxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 
> ...
> 
> ******************
> * Start building *
> ******************
> make -C /home/hugo/tmp/media_build/v4l allyesconfig
> make[1]: Entering directory `/home/hugo/tmp/media_build/v4l'
> No version yet, using 3.2.0-61-generic
> make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l'
> make[1]: Entering directory `/home/hugo/tmp/media_build/v4l'
> make[2]: Entering directory `/home/hugo/tmp/media_build/linux'
> Applying patches for kernel 3.2.0-61-generic
> patch -s -f -N -p1 -i ../backports/api_version.patch
> patch -s -f -N -p1 -i ../backports/pr_fmt.patch
> The text leading up to this was:
> --------------------------
> |diff --git a/drivers/media/usb/gspca/dtcs033.c 
> b/drivers/media/usb/gspca/dtcs033.c
> |index 5e42c71..ba01a3e 100644
> |--- a/drivers/media/usb/gspca/dtcs033.c
> |+++ b/drivers/media/usb/gspca/dtcs033.c
> --------------------------
> No file to patch.  Skipping patch.
> 1 out of 1 hunk ignored
> make[2]: *** [apply_patches] Error 1
> make[2]: Leaving directory `/home/hugo/tmp/media_build/linux'
> make[1]: *** [allyesconfig] Error 2
> make[1]: Leaving directory `/home/hugo/tmp/media_build/v4l'
> make: *** [allyesconfig] Error 2
> can't select all drivers at ./build line 490.
> xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
> 
> Please help me to get my TV working again.
> 
> 
> Thanks
> 
> --kapetr
> --
> To unsubscribe from this list: send the line "unsubscribe linux-media" 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

[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.

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.

Build problem

[Rick Stevens]

This is a repost, as I've not seen a response.  Feel free to respond
to me directly if it seems more appropriate.  I've done a bit of
updating too, as this ugly beast reared it's head on a second machine
this weekend.  This has been driving me nuts for days!  I need some
help!

This may or may not have been discussed.  Yesterday, I was building
2.4.14 (yes, a bit behind the time) for a system where the root
filesystem lives on a Symbios 53c8xx SCSI drive.  I built the system
as fully modularized (the root driver and such were modules).  When
I finally got around to building the initrd image, I noticed that
the scsi_mod.o and sd_mod.o drivers were NOT loaded into the ramdisk
image.

Hmmm, I said to myself.  I looked at the
/lib/modules/2.4.14/kernel/drivers/scsi directory and discovered that
scsi_mod.o and sd_mod.o weren't present!  Looking back at the source
tree, they had indeed been built.  Apparently the "make modules_install"
didn't move them to the /lib tree.  So I copied them manually,
re-depmoded it and re-built the initrd image.  This time, the scsi_mod
and sd_mod modules WERE inserted into the ramdisk image.  However, when
booting using that image, neither scsi_mod nor sd_mod are loaded.  The
sym53c8xx driver DOES load, but we have an instant panic because the
root filesystem can't be found.

ADDITION: Same bloody thing happened on a different machine where the
root filesystem lives on a dpt_i2o SCSI RAID module.

What am I doing wrong here?  Is "make modules_install" broken in 2.4.14?
Am I suffering from a short between the keyboard and floor?  For
further info, this is a baseline RedHat 7.1 system, but I want the
2.4.14 kernel (the virtual memory system seems to work better for
our purposes than that found in kernels <= 2.4.9 and no, I don't
want to get into a discussion about the merits of the aa and ac
VM systems).


P.S. I'm posting this to linux-kernel and linux-scsi.  Someone should
be able to tell me what I did wrong.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-      Try to look unimportant--the bad guys may be low on ammo!     -
----------------------------------------------------------------------

Build problem

[Rick Stevens]

This may or may not have been discussed.  Yesterday, I was building
2.4.14 (yes, a bit behind the time) for a system where the root
filesystem lives on a Symbios 53c8xx SCSI drive.  I built the system
as fully modularized (the root driver and such were modules).  When
I finally got around to building the initrd image, I noticed that
the scsi_mod.o and sd_mod.o drivers were NOT loaded into the ramdisk
image.

Hmmm.  I looked at the /lib/modules/2.4.14/kernel/drivers/scsi
directory and discovered that scsi_mod.o and sd_mod.o weren't
present!  Looking back at the source tree, they had indeed been built.
Apparently the "make modules_install" didn't move them to the /lib
tree.  So I copied them manually, re-depmoded it and re-built the
initrd image.  This time, the scsi_mod and sd_mod modules WERE
inserted into the ramdisk image.  However, when booting using that
image, neither scsi_mod nor sd_mod are loaded.  The sym53c8xx driver
DOES load, but we have an instant panic because the root filesystem
can't be found.

What did I do wrong here?  Is "make modules_install" broken in 2.4.14?
Am I suffering from a short between the keyboard and floor?  For
further info, this is a baseline RedHat 7.1 system, but I want the
2.4.14 kernel (the virtual memory system seems to work better for
our purposes than that found in kernels <= 2.4.9 and no, I don't
want to get into a discussion about the merits of the aa and ac
VM systems).


P.S. I'm posting this to linux-kernel and linux-scsi.  Someone should
be able to tell me what I did wrong.

----------------------------------------------------------------------
- Rick Stevens, SSE, VitalStream, Inc.      rstevens@vitalstream.com -
- 949-743-2010 (Voice)                    http://www.vitalstream.com -
-                                                                    -
-     Never put off 'til tommorrow what you can forget altogether!   -
----------------------------------------------------------------------