The more rigorous error checking in kbuild 2.5 found several Makefile
entries for objects that have no source. kbuild 2.4 silently ignores
objects that it cannot build, allowing errors to sneak through.
These are typing errors or they are dead entries. In either case they
need to be cleaned up, by removing the entry from the Makefile or by
supplying the missing source. After removing the entries, also verify
if the CONFIG_ entry is still required and remove that as well if it is
obsolete.
Makefile Object with no source
drivers/acorn/char/Makefile keyb_l7200.o
drivers/acpi/Makefile osconf.o
drivers/char/Makefile serial_sa1100.o
drivers/ide/Makefile pdcadma.o
drivers/isdn/Makefile isdn_dwabc.o
drivers/net/Makefile veth.o
drivers/usb/storage/Makefile shuttle_sm.o
shuttle_cf.o
drivers/video/Makefile dcfb.o
fbcon-iplan2p16.o
fs/nls/Makefile nls_cp1252.o
nls_cp1253.o
nls_cp1254.o
nls_cp1256.o
nls_cp1257.o
nls_cp1258.o
nls_iso8859_10.o
nls_abc.o
lib/Makefile crc32.o
net/decnet/Makefile dn_fw.o
net/sched/Makefile sch_hpfq.o
sch_hfsc.o
On Sun, Apr 07, 2002 at 09:01:39PM +1000, Keith Owens wrote:
> lib/Makefile crc32.o
crc32.c seems to exist in linux/lib/ in 2.5.7 and 2.5.8-pre2
--
Russell King ([email protected]) The developer of ARM Linux
http://www.arm.linux.org.uk/personal/aboutme.html
On Sun, 7 Apr 2002 12:11:32 +0100,
Russell King <[email protected]> wrote:
>On Sun, Apr 07, 2002 at 09:01:39PM +1000, Keith Owens wrote:
>> lib/Makefile crc32.o
>
>crc32.c seems to exist in linux/lib/ in 2.5.7 and 2.5.8-pre2
But not in 2.4.19-pre6. Given an object which has no source, it could
be dead, a typing error or a placeholder for future work. There is no
way to tell which, most are dead entries.
I don't object to placeholder entries ("will be back ported from 2.5
one day" or "is only used in ia64") as long as they are commented out
until the source also exists. In this case, crc32 is required for ia64
on 2.4 kernels and we have a broken merge. The Makefile was updated
from the ia64 patch but the source was not. In 2.5 everybody uses
crc32. Best fix is to delete crc32 from 2.4 Makefiles and add it only
in the ia64 patch.
On Sun, 7 Apr 2002, Keith Owens wrote:
> The more rigorous error checking in kbuild 2.5 found several Makefile
> entries for objects that have no source. kbuild 2.4 silently ignores
...
> fs/nls/Makefile nls_cp1252.o
> nls_cp1253.o
> nls_cp1254.o
> nls_cp1256.o
> nls_cp1257.o
> nls_cp1258.o
> nls_iso8859_10.o
> nls_abc.o
The abc one is mine and should never have escaped from my test setup. The
others look pretty unused to me, so I think the following should be
applied to both 2.4 and 2.5.
/Urban
diff -urN -X exclude linux-2.4.19-pre5-orig/fs/nls/Makefile linux/fs/nls/Makefile
--- linux-2.4.19-pre5-orig/fs/nls/Makefile Mon Apr 1 12:39:15 2002
+++ linux/fs/nls/Makefile Sun Apr 7 15:36:34 2002
@@ -29,12 +29,6 @@
obj-$(CONFIG_NLS_CODEPAGE_950) += nls_cp950.o nls_big5.o
obj-$(CONFIG_NLS_CODEPAGE_1250) += nls_cp1250.o
obj-$(CONFIG_NLS_CODEPAGE_1251) += nls_cp1251.o
-obj-$(CONFIG_NLS_CODEPAGE_1252) += nls_cp1252.o
-obj-$(CONFIG_NLS_CODEPAGE_1253) += nls_cp1253.o
-obj-$(CONFIG_NLS_CODEPAGE_1254) += nls_cp1254.o
-obj-$(CONFIG_NLS_CODEPAGE_1256) += nls_cp1256.o
-obj-$(CONFIG_NLS_CODEPAGE_1257) += nls_cp1257.o
-obj-$(CONFIG_NLS_CODEPAGE_1258) += nls_cp1258.o
obj-$(CONFIG_NLS_ISO8859_1) += nls_iso8859-1.o
obj-$(CONFIG_NLS_ISO8859_2) += nls_iso8859-2.o
obj-$(CONFIG_NLS_ISO8859_3) += nls_iso8859-3.o
@@ -44,13 +38,11 @@
obj-$(CONFIG_NLS_ISO8859_7) += nls_iso8859-7.o
obj-$(CONFIG_NLS_ISO8859_8) += nls_cp1255.o nls_iso8859-8.o
obj-$(CONFIG_NLS_ISO8859_9) += nls_iso8859-9.o
-obj-$(CONFIG_NLS_ISO8859_10) += nls_iso8859-10.o
obj-$(CONFIG_NLS_ISO8859_13) += nls_iso8859-13.o
obj-$(CONFIG_NLS_ISO8859_14) += nls_iso8859-14.o
obj-$(CONFIG_NLS_ISO8859_15) += nls_iso8859-15.o
obj-$(CONFIG_NLS_KOI8_R) += nls_koi8-r.o
obj-$(CONFIG_NLS_KOI8_U) += nls_koi8-u.o nls_koi8-ru.o
-obj-$(CONFIG_NLS_ABC) += nls_abc.o
obj-$(CONFIG_NLS_UTF8) += nls_utf8.o
export-objs = $(obj-y)
> >On Sun, Apr 07, 2002 at 09:01:39PM +1000, Keith Owens wrote:
> >> lib/Makefile crc32.o
> >
> >crc32.c seems to exist in linux/lib/ in 2.5.7 and 2.5.8-pre2
>
> But not in 2.4.19-pre6. Given an object which has no source, it could
> be dead, a typing error or a placeholder for future work. There is no
> way to tell which, most are dead entries.
>
> I don't object to placeholder entries ("will be back ported from 2.5
> one day" or "is only used in ia64") as long as they are commented out
> until the source also exists. In this case, crc32 is
> required for ia64
> on 2.4 kernels and we have a broken merge. The Makefile was updated
> from the ia64 patch but the source was not. In 2.5 everybody uses
> crc32. Best fix is to delete crc32 from 2.4 Makefiles and add it only
> in the ia64 patch.
Per Jeff Garzik's request, 2.4.19-pre2 included the 2.4 kernel crc32
cleanups, which did not add a lib/crc32.c, but made the crc32 functions
static inline in include/linux/crc32.h.
Until this past week, the 2.4.x IA-64 port patch was adding
lib/{crc32.c,Makefile}. I provided David Mosberger (and he has since
merged) a new patch for fs/partitions/efi.[ch] which has essentially the 2.5
crc32 code in there, and no longer touches include/linux/crc32.h or
lib/crc32.c. In that patch I neglected to delete lib/crc32.c and remove
stuff from lib/Makefile for it, though I did tell David that he could delete
lib/crc32.c and include/linux/crc32.h from his patch entirely.
For now in 2.4.x, please simply remove the crc32 lines from lib/Makefile.
IA-64 doesn't need them anymore.
At some point, if someone wants to backport the 2.5.x crc32 library code,
that'd be fine by me. Marcelo didn't want any changes that could cause
instability in 2.4.x, so that's the way it's been done.
Thanks,
Matt
--
Matt Domsch
Sr. Software Engineer
Dell Linux Solutions http://www.dell.com/linux
Linux on Dell mailing lists @ http://lists.us.dell.com
#1 US Linux Server provider for 2001! (IDC Mar 2002)
>> fs/nls/Makefile nls_cp1252.o
It does seem as though this one would be useful to a significant
number of people. Is there some reason 125[2-46-8] are not included
where the rest are?
I can generate a patch to add the missing ones if anyone is
interested. Though it would be easier were there a tool to automate
those .c files.... (I've not found any docs about the layout; I'm
sure it would be easy given such info to modify eg Markus Kuhn's
uniset to output the necessary data. In fact, it seems like it would
be better to include the unicode table files in the kernel tree and
use a utility to generate the nls...c files as needed, yes?)
-JimC
On Sun, 7 Apr 2002 12:52:50 -0500 ,
[email protected] wrote:
>> >On Sun, Apr 07, 2002 at 09:01:39PM +1000, Keith Owens wrote:
>> >> lib/Makefile crc32.o
Forget crc32, the file is not referenced in base lib/Makefile.
Spurious bug report caused by another change.
On 7 Apr 2002, James H. Cloos Jr. wrote:
> >> fs/nls/Makefile nls_cp1252.o
>
> It does seem as though this one would be useful to a significant
> number of people. Is there some reason 125[2-46-8] are not included
> where the rest are?
Perhaps they aren't used in a form that makes any linux fs see them.
cp1252 is not the codepage used by a windows smb server so you wouldn't
need it for smbfs (same for vfat, ncpfs?), it would return data in the
corresponding dos codepage (cp850). NTFS is unicode. cd/dvd formats are
... (?)
Maybe I'm missing something.
> uniset to output the necessary data. In fact, it seems like it would
> be better to include the unicode table files in the kernel tree and
> use a utility to generate the nls...c files as needed, yes?)
I think so. A tool to build them would be nice, cp1252 or not. I did some
editing before on them and the editor was perl (ok, so I suck at using awk
and sed ...).
Some format that allows different implementations to be used. All the
iso* pages could share one implementation file but let the more advanced
have different. That could of course be done with a simple "#include".
/Urban
On Sun, Apr 07, 2002 at 09:01:39PM +1000, Keith Owens wrote:
>
> drivers/usb/storage/Makefile shuttle_sm.o
> shuttle_cf.o
I've just removed these rules from my 2.5 and 2.4 trees, and will send
the changes on upstream with the next round of USB patches.
thanks,
greg k-h