Recent changes to bugs

missing depend in libsial/Makefile

Mike Frysinger — Fri, 02 Jan 2009 07:32:52 -0000

the libsial/Makefile file in the 6.2.0 release does not declare a dependency of sial_api.o on sial.tab.h

as such, a parallel build may fail as make attempts to compile sial_api.c before sial.tab.h has been generated

--- a/libsial/Makefile
+++ b/libsial/Makefile
@@ -53,7 +53,7 @@
./mkbaseop > baseops.c
$(CC) $(CFLAGS) -c baseops.c

-mkbaseop.c sial_member.o sial_op.o sial_stat.o sial_type.o y.tab.o : sial.tab.h
+mkbaseop.c sial_api.o sial_member.o sial_op.o sial_stat.o sial_type.o y.tab.o : sial.tab.h

lex.sial.o: lex.sial.c sial.tab.c sial.h
$(CC) $(CFLAGS) -c lex.sial.c

trivial, missing COPYING in bunch-0.3.tgz

James Cameron — Wed, 15 Nov 2006 04:24:27 -0000

Although the .c source files have the GPL prelude, the full text of the license is not present in the distribution of buncho-0.3.tgz

It isn't clear whether the license covers the scripts or regnat.S.

Suggest adding COPYING to the build of the tarball next time.

I wasn't able to find any "make dist" target, so the attached patch adds one. COPYING still needs to be added though.

unable to compile lkcd due to error

Anonymous — Tue, 11 Oct 2005 01:08:20 -0000

I am using a i386 system. Here is the error I get when
i try to compile:

cc -I/usr/src/kernelmods/lkcdutils/dwarf/libdwarf -g
-D_FILE_OFFSET_BITS=64 -DARCH=i386 -Iinclude
-I../liballoc -I../libutil -I/usr/local/include
-I/usr/include/libelf -Wall -Wstrict-prototypes
-DDUMP_ARCH_I386 -c -o kl_cmp.o kl_cmp.c
kl_cmp.c:37: error: static declaration of cache_head
follows non-static declaration
include/kl_cmp.h:85: error: previous declaration of
cache_head was here
kl_cmp.c:37: error: static declaration of cache_tail
follows non-static declaration
include/kl_cmp.h:86: error: previous declaration of
cache_tail was here
kl_cmp.c: In function kl_compress_gzip:
kl_cmp.c:1338: warning: pointer targets in passing
argument 1 of compress differ in signedness
kl_cmp.c:1338: warning: pointer targets in passing
argument 3 of compress differ in signedness
make: *** [kl_cmp.o] Error 1

"invalid address mapping" error comes in lcrash

Anonymous — Mon, 25 Apr 2005 05:55:31 -0000

We are using the linux kernel 2.4.18-14 for development
of a networking product and have used the lkcd for
generation of core dumps is case the linux kernel
crashes. The system has about one gig of RAM, but the
amount of memory visible to the kernel is passed as 128
MB to the kernel at boot time in the "mem" parameter
for lilo. Till now, the crash dumps that we were
getting were readable by the lcrash and everything was
running fine. Recently we have increased the amount of
memory visible to the kernel from 128 to 384 MB. After
this change the crash dumps created were unreadable by
the lcrash util and we get "invalid memory mapping"
errors in lcrash. Can u help us in here (like pointing
to some fix in lkcd or some special cfg to be done). I
am pasting the device stats and the /ect/sysconfig/dump
file in the mail.

Device stats:
Disk /dev/sda: 255 heads, 63 sectors, 4462 cylinders
Units = cylinders of 16065 * 512 bytes

Device Boot Start End Blocks Id System
/dev/sda1 * 1 131 1052226 83 Linux
/dev/sda2 132 2742 20972857+ 83 Linux
/dev/sda3 2743 3264 4192965 82 Linux
swap (second swap)
/dev/sda4 3265 4462 9622935 f Win95
Ext'd (LBA)
/dev/sda5 3265 3786 4192933+ 83 Linux
/dev/sda6 3787 4047 2096451 83 Linux
/dev/sda7 4048 4462 3333456 82 Linux
swap (first swap)

------------------------------------------------------------------------------------------------------------

/etc/sysconfig/dump:

DUMP_ACTIVE=1
DUMPDEV=/dev/vmdump
DUMPDIR=/var/log/dump
DUMP_SAVE=1
DUMP_LEVEL=8
DUMP_FLAGS=0
DUMP_COMPRESS=0
PANIC_TIMEOUT=600

------------------------------------------------------------------------------

Seekig help desparately,
Anurag Mathur

build fails WRT CONFIG_SCHEDSTATS

Anonymous — Tue, 15 Feb 2005 14:24:30 -0000

Build fails with my config because struct runqueue def was
moved from sched.c to sched.h, but not completely -- small
portion inside #ifdef CONFIG_SCHEDSTATS was dropped.

I fixed this myself, but now got another error:

drivers/dump/dump_overlay.c: In function
`dump_passthru_add_data':
drivers/dump/dump_overlay.c:791: error: structure has
no member named `count'

I think it's due to similar matter.

--
Digging further...
xrgtn (arg@online.com.ua)

Building of lkcdutils fails with following error.

Anonymous — Mon, 14 Feb 2005 14:39:57 -0000

[root@localhost lkcdutils]# pwd
/lkcd/lkcdutils
onfigure: creating ./config.status
config.status: creating Makefile
config.status: creating config.h
gcc -I. -I. -I. -c -o dwarf_abbrev.o dwarf_abbrev.c
gcc -I. -I. -I. -c -o dwarf_alloc.o dwarf_alloc.c
gcc -I. -I. -I. -c -o dwarf_arange.o dwarf_arange.c
gcc -I. -I. -I. -c -o dwarf_die_deliv.o dwarf_die_deliv.c
gcc -I. -I. -I. -c -o dwarf_error.o dwarf_error.c
gcc -I. -I. -I. -c -o dwarf_form.o dwarf_form.c
gcc -I. -I. -I. -c -o dwarf_frame.o dwarf_frame.c
dwarf_frame.c: In function
`dwarf_expand_frame_instructions':
dwarf_frame.c:2140: warning: cast from pointer to
integer of different size
dwarf_frame.c:2140: warning: cast to pointer from
integer of different size
gcc -I. -I. -I. -c -o dwarf_funcs.o dwarf_funcs.c
gcc -I. -I. -I. -c -o dwarf_global.o dwarf_global.c
gcc -I. -I. -I. -c -o dwarf_init_finish.o
dwarf_init_finish.c
dwarf_init_finish.c: In function `_dwarf_setup':
dwarf_init_finish.c:155: error: `Elf_Scn' undeclared
(first use in this function)
dwarf_init_finish.c:155: error: (Each undeclared
identifier is reported only once
dwarf_init_finish.c:155: error: for each function it
appears in.)
dwarf_init_finish.c:155: error: `scn' undeclared (first
use in this function)
dwarf_init_finish.c:182: warning: assignment makes
pointer from integer without a cast
dwarf_init_finish.c:229: warning: assignment makes
pointer from integer without a cast
dwarf_init_finish.c:290: warning: assignment makes
pointer from integer without a cast
dwarf_init_finish.c:297: warning: assignment makes
pointer from integer without a cast
dwarf_init_finish.c: In function `dwarf_init':
dwarf_init_finish.c:529: error: `Elf_Cmd' undeclared
(first use in this function)
dwarf_init_finish.c:529: error: syntax error before
"what_kind_of_elf_read"
dwarf_init_finish.c:571: error: `what_kind_of_elf_read'
undeclared (first use in this function)
dwarf_init_finish.c:571: error: `ELF_C_READ' undeclared
(first use in this function)
dwarf_init_finish.c:574: warning: assignment makes
pointer from integer without a cast
dwarf_init_finish.c: In function `_dwarf_load_section':
dwarf_init_finish.c:712: error: `Elf_Scn' undeclared
(first use in this function)
dwarf_init_finish.c:712: error: `scn' undeclared (first
use in this function)
dwarf_init_finish.c:713: error: `Elf_Data' undeclared
(first use in this function)
dwarf_init_finish.c:713: error: `data' undeclared
(first use in this function)
make: *** [dwarf_init_finish.o] Error 1

lcrash in linux alpha lkcdutils vrs.4.2

Anonymous — Fri, 09 Apr 2004 12:44:48 -0000

Hi
i search to use LKCD e lkcdutils in ALPHA cpu.

I have 2.4.20 kernel version with lkcd; kernels works
but lcrash don't save in /var/log/dump the crash.

Because you don't change

#define KL_DUMP_PAGE_SHIFT 12ULL

#define KL_DUMP_PAGE_SHIFT 13ULL (page is 8K in alpha)

in file:

libklib/include/kl_dump.h

Thus so alpha works!

cappelc

missing files

Josh Davis — Tue, 06 Apr 2004 02:20:47 -0000

Main page and downloads readme as of Feb 2, 2004 says
files were moved to the main sourceforge page at
http://www.sourceforge.net/projects/lkcd

There are no files there. Looking manually at the
downloads page for this group, it says there are no
files. The newest files on OLD are August, 2003.

Kerntypes not compiled when LKCD is built as modules

Hariprasad — Tue, 20 Jan 2004 06:52:46 -0000

The following patch is needed to compile kerntypes.o
when LKCD is built as modules.

sialpp.y does not work with new bison

Corey Minyard — Sat, 19 Jul 2003 16:20:59 -0000

The sialpp.y and associated code uses bison internals,
and the internals have changed with new versions of
bison. I would strongly recommend not relying on bison
internals. This is a simple enough parser that it
could easily be rewritten by hand, if necessary. In
its current form it will continually break with
different versions of bison and will not work with any
other parser generators.