2.2.18pre19:
/usr/bin/gcc272 -D__KERNEL__ -I/home/22/linux/include -Wall
-Wstrict-prototypes -O2 -fomit-frame-pointer -D__SMP__ -pipe
-fno-strength-reduce -m486 -malign-loops=2 -malign-jumps=2
-malign-functions=2 -DCPU=586 -c -o fork.o fork.c
ide-probe.c: In function `probe_cmos_for_drives':
ide-probe.c:400: `rtc_lock' undeclared (first use this function)
ide-probe.c:400: (Each undeclared identifier is reported only once
ide-probe.c:400: for each function it appears in.)
And , whose idea was that "make modules_install" should create
/lib/modules/..../build symlink to the kernel sources?
It really breakes depmod -a (modutils 2.3.11)(*)
Best regards,
--
Tomasz Motylewski
(*) I could find a workaround, but if it hits me, it will hit lots of other
people not reading linux-kernel regularly. In my opinion upgrading stable
kernels should work without any modifications to the existing system.
On Tue, 7 Nov 2000, Tomasz Motylewski wrote:
> 2.2.18pre19:
> ide-probe.c:400: `rtc_lock' undeclared (first use this function)
> ide-probe.c:400: (Each undeclared identifier is reported only once
> ide-probe.c:400: for each function it appears in.)
See the attached patch. Just declares it as an extern spinlock_t, as
per a boatload of other places in the kernel.
Mark
--
+-------------------------------------------------------------------------+
Mark Cooke The views expressed above are mine and are not
Systems Programmer necessarily representative of university policy
University Of Birmingham URL: http://www.sr.bham.ac.uk/~mpc/
+-------------------------------------------------------------------------+
On Tue, 7 Nov 2000 01:20:36 +0100 (CET),
Tomasz Motylewski <[email protected]> wrote:
>2.2.18pre19:
>And , whose idea was that "make modules_install" should create
>/lib/modules/..../build symlink to the kernel sources?
>It really breakes depmod -a (modutils 2.3.11)(*)
>
>(*) I could find a workaround, but if it hits me, it will hit lots of other
>people not reading linux-kernel regularly. In my opinion upgrading stable
>kernels should work without any modifications to the existing system.
Agreed, I was unhappy that the build symlink was added to 2.2 kernels.
Now you need modutils >= 2.3.14 for 2.2 kernels :(. But nobody asks
me, I'm just the kernel module.[ch] and modutils maintainer.
> Agreed, I was unhappy that the build symlink was added to 2.2 kernels.
> Now you need modutils >= 2.3.14 for 2.2 kernels :(. But nobody asks
> me, I'm just the kernel module.[ch] and modutils maintainer.
Actually they do. I agree that it wants sorting. Im just wondering what the
best approach is - maybe check modutils rev and only add the link if its high
enough ?
On Tue, 7 Nov 2000 12:11:57 +0000 (GMT),
Alan Cox <[email protected]> wrote:
>> Agreed, I was unhappy that the build symlink was added to 2.2 kernels.
>> Now you need modutils >= 2.3.14 for 2.2 kernels :(. But nobody asks
>> me, I'm just the kernel module.[ch] and modutils maintainer.
>
>Actually they do. I agree that it wants sorting. Im just wondering what the
>best approach is - maybe check modutils rev and only add the link if its high
>enough ?
Against 2.2.18-pre19, only create build symlink if insmod exists and
has version >= 2.3.14.
Index: 18-pre19.1/Makefile
--- 18-pre19.1/Makefile Sat, 04 Nov 2000 21:35:33 +1100 kaos (linux-2.2/G/b/14_Makefile 1.3.2.2.1.1.1.5.1.3.6.1.5.1.1.1.1.16.1.4 644)
+++ 18-pre19.1(w)/Makefile Wed, 08 Nov 2000 00:13:19 +1100 kaos (linux-2.2/G/b/14_Makefile 1.3.2.2.1.1.1.5.1.3.6.1.5.1.1.1.1.16.1.4 644)
@@ -335,6 +335,7 @@ modules_install:
MODLIB=$(INSTALL_MOD_PATH)/lib/modules/$(KERNELRELEASE); \
mkdir -p $$MODLIB; \
rm -f $$MODLIB/build; \
+ [ `/sbin/insmod -V 2>&1 | awk '/^insmod version /{split($3, a, /\./); printf "%d%03d%03d\n", a[1], a[2], a[3];}'`0 -ge 20030140 ] && \
ln -s `pwd` $$MODLIB/build; \
cd modules; \
MODULES=""; \
On Tue, 7 Nov 2000, Alan Cox wrote:
>Date: Tue, 7 Nov 2000 12:11:57 +0000 (GMT)
>From: Alan Cox <[email protected]>
>To: Keith Owens <[email protected]>
>Cc: Tomasz Motylewski <[email protected]>,
> Alan Cox <[email protected]>, [email protected]
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: ide-probe.c:400: `rtc_lock' undeclared and
> /lib/modules/..../build
>
>> Agreed, I was unhappy that the build symlink was added to 2.2 kernels.
>> Now you need modutils >= 2.3.14 for 2.2 kernels :(. But nobody asks
>> me, I'm just the kernel module.[ch] and modutils maintainer.
>
>Actually they do. I agree that it wants sorting. Im just wondering what the
>best approach is - maybe check modutils rev and only add the link if its high
>enough ?
What if build-machine != machine-kernel-was-built-for?
----------------------------------------------------------------------
NOTE: My new email address is: [email protected]
Mike A. Harris - Linux advocate - Open source advocate
Computer Consultant - Capslock Consulting
Copyright 2000 all rights reserved
----------------------------------------------------------------------
"Facts do not cease to exist because they are ignored."
- Aldous Huxley
On Tue, 7 Nov 2000 21:48:59 -0500 (EST),
"Mike A. Harris" <[email protected]> wrote:
>On Tue, 7 Nov 2000, Alan Cox wrote:
>>Actually they do. I agree that it wants sorting. Im just wondering what the
>>best approach is - maybe check modutils rev and only add the link if its high
>>enough ?
>
>What if build-machine != machine-kernel-was-built-for?
Then you are SOL, but that is a generic cross compile problem. Anybody
doing cross compile has to do extra steps to copy the results to the
other machine and they can take care of problems like the build symlink
themselves. The patch in 2.2.18-pre20 fixes the problem for local
compiles, which are 95%+ (SWAG) of the compiles.
On Wed, 8 Nov 2000, Keith Owens wrote:
>Date: Wed, 08 Nov 2000 14:59:42 +1100
>From: Keith Owens <[email protected]>
>To: Mike A. Harris <[email protected]>
>Cc: Linux Kernel mailing list <[email protected]>
>Content-Type: text/plain; charset=us-ascii
>Subject: Re: ide-probe.c:400: `rtc_lock' undeclared and
> /lib/modules/..../build
>
>On Tue, 7 Nov 2000 21:48:59 -0500 (EST),
>"Mike A. Harris" <[email protected]> wrote:
>>On Tue, 7 Nov 2000, Alan Cox wrote:
>>>Actually they do. I agree that it wants sorting. Im just wondering what the
>>>best approach is - maybe check modutils rev and only add the link if its high
>>>enough ?
>>
>>What if build-machine != machine-kernel-was-built-for?
>
>Then you are SOL, but that is a generic cross compile problem. Anybody
>doing cross compile has to do extra steps to copy the results to the
>other machine and they can take care of problems like the build symlink
>themselves. The patch in 2.2.18-pre20 fixes the problem for local
>compiles, which are 95%+ (SWAG) of the compiles.
I'm not refering to cross compiling. I'm talking about if I
compile my kernel on machine A, and want to run this on 100%
hardware identical machine B. What if machine B doesn't run the
same version of modutils? In other words same hardware setup
different distribution or version of Linux?
----------------------------------------------------------------------
NOTE: My new email address is: [email protected]
Mike A. Harris - Linux advocate - Open source advocate
Computer Consultant - Capslock Consulting
Copyright 2000 all rights reserved
----------------------------------------------------------------------
#[Mike A. Harris bash tip #2 - custom colorized bash prompts]
# For a color prompt, put the following at the bottom of your ~/.bash_profile
TTYNAME=$(tty | sed -e 's/^\/dev\///' -e 's/^tty//');DRED=31;DGREEN=32
BROWN=33;DBLUE=34;DMAGENTA=35;DCYAN=36;GREY=37;DGREY=30\;1;RED=31\;1
GREEN=32\;1;YELLOW=33\;1;BLUE=34\;1;MAGENTA=35\;1;CYAN=36\;1;WHITE=37\;1
CLRUSER=$CYAN ; CLRHOST=$YELLOW # Set the user and host colors here
PS1="$TTYNAME \[\033[${CLRUSER}m\]\u\[\033[0;m\]"
export PS1="${PS1}@\[\033[${CLRHOST}m\]\h\\[\033[0;m\]:\w\$ "