Re: problems about __cli()

Re: problems about __cli()

[Iain Sandoe]

Hi Rolf,

 Thu, Jul 20, 2000, Rolf Liu wrote:
> I am currently compiling the kernel 2.2.13.
> A problem occours, it said the "__cli() is not defined".
> I wonder where the __cli() is defined in the kernel tree, which file is it
> in ?
> thanks a  lot.

(at 2.2.17preZZ - any reason for using 2.2.13?)

Where "your-kernel-foo-bar" is the source tree you are working with:

__cli() is defined in:

/usr/src/your-kernel-foo-bar/include/asm-ppc/system.h

asm-ppc is symlinked to /usr/src/your-kernel-foo-bar/include/asm by the
build process.

the function is implemented in:

/usr/src/your-kernel-foo-bar/arch/ppc/kernel/misc.S

It is *vital* to make sure that there is a symlink named 'linux' in /usr/src
that points to your /usr/src/your-kernel-foo-bar/ because there are symlinks
in /usr/include that expect to use this to find the build-specific headers.

hope this helps,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Josh Huber]

[-- Attachment #1: Type: text/plain, Size: 755 bytes --]

On Thu, Jul 20, 2000 at 10:19:54AM +0100, Iain Sandoe wrote:
> 
[snip]
> 
> It is *vital* to make sure that there is a symlink named 'linux' in /usr/src
> that points to your /usr/src/your-kernel-foo-bar/ because there are symlinks
> in /usr/include that expect to use this to find the build-specific headers.

A couple notes:

You don't have to put your kernel in /usr/src, and you DON'T have to
symlink /usr/src/linux to it before you build.  The symlinks (on
broken RedHat derivatives) in /usr/include should point to the kernel
headers that your libc was built againt, otherwise you risk breaking
binary compatibility.

-- 
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: problems about __cli()

[Michael Schmitz]

Iain Sandoe wrote:
> the function is implemented in:
>
> /usr/src/your-kernel-foo-bar/arch/ppc/kernel/misc.S
>
> It is *vital* to make sure that there is a symlink named 'linux' in /usr/src
> that points to your /usr/src/your-kernel-foo-bar/ because there are symlinks
> in /usr/include that expect to use this to find the build-specific headers.

Wasn't that the same guy that tried to build Linux kernels on a Windoze
system? The whole /usr/src and symlink stuff might be a bit tough to
pull off on such a box.

	Michael


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Iain Sandoe]

On  Fri, Jul 21, 2000,  Michel Dänzer wrote:
> Iain Sandoe schrieb:
>> Thu, Jul 20, 2000,  Josh Huber wrote:
>> > On Thu, Jul 20, 2000 at 10:19:54AM +0100, Iain Sandoe wrote:
>> >>
>> > [snip]
>> >>
>> >> It is *vital* to make sure that there is a symlink named 'linux' in
>> >> /usr/src that points to your /usr/src/your-kernel-foo-bar/ because there
>> >> are symlinks in /usr/include that expect to use this to find the
>> >> build-specific headers.
>> >
>> > A couple notes:
>> >
>> > You don't have to put your kernel in /usr/src, and you DON'T have to
>> > symlink /usr/src/linux to it before you build.  The symlinks (on
>> > broken RedHat derivatives) in /usr/include should point to the kernel
>> > headers that your libc was built againt, otherwise you risk breaking
>> > binary compatibility.
>>
>> I guess I *must* have one of those broken derivatives... and it doesn't work
>> for me without that step...  Admittedly, this is mostly an issue between
>> 2.2.xx and 2.4.0 - but I do have to remember to change it back between
>> whiles... a better way would be ?
>
> Have you tried 'make mrproper' (backup your .config ;), put back the old
> config, then 'make oldconfig dep vmlinux'? AFAIK the directory where the tree
> resides only matters after make dep, and the connection is untied with make
> mrproper.

Well, I *usually* do  (on average once a day..):
save .config
make mrproper
restore .config
make menuconfig (just to check out that I'm certain of the conditions for
*this* compile :)
make dep vmlinux.... etc.

However, I'm not immune from 'finger trouble' ;-)

Next time I do a 2.4.0 build I'll note more carefully what I do and see what
happens... I'm concentrating on IRQ stuff on 2.2.17 until prob. Sunday.

Thanks for the suggestions,
Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Iain Sandoe]

Thu, Jul 20, 2000,  Josh Huber wrote:
> On Thu, Jul 20, 2000 at 10:19:54AM +0100, Iain Sandoe wrote:
>>
> [snip]
>>
>> It is *vital* to make sure that there is a symlink named 'linux' in /usr/src
>> that points to your /usr/src/your-kernel-foo-bar/ because there are symlinks
>> in /usr/include that expect to use this to find the build-specific headers.
>
> A couple notes:
>
> You don't have to put your kernel in /usr/src, and you DON'T have to
> symlink /usr/src/linux to it before you build.  The symlinks (on
> broken RedHat derivatives) in /usr/include should point to the kernel
> headers that your libc was built againt, otherwise you risk breaking
> binary compatibility.

I guess I *must* have one of those broken derivatives... and it doesn't work
for me without that step...  Admittedly, this is mostly an issue between
2.2.xx and 2.4.0 - but I do have to remember to change it back between
whiles... a better way would be ?

Iain.

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Josh Huber]

[-- Attachment #1: Type: text/plain, Size: 1000 bytes --]

On Thu, Jul 20, 2000 at 02:45:56PM +0100, Iain Sandoe wrote:
> I guess I *must* have one of those broken derivatives... and it doesn't work
> for me without that step...  Admittedly, this is mostly an issue between
> 2.2.xx and 2.4.0 - but I do have to remember to change it back between
> whiles... a better way would be ?

Well...hmm, what doesn't work?  You mean you can't build a kernel
unless you make /usr/src/linux point to the kernel source you're
building?  This is odd, as I haven't done that...ever!  In fact,
there's no directories in /usr/src on my machine.

I'm confused, as I've built many kernels on a redhat box here (intel,
but that shouldn't matter) without every updating the symlink, or
using /usr/src to build inside.

I tend to have very large amounts of kernel source laying around, and
I don't like to clutter my /usr partition with them...

-- 
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: problems about __cli()

[Geert Uytterhoeven]

On Thu, 20 Jul 2000, Josh Huber wrote:
> On Thu, Jul 20, 2000 at 02:45:56PM +0100, Iain Sandoe wrote:
> > I guess I *must* have one of those broken derivatives... and it doesn't work
> > for me without that step...  Admittedly, this is mostly an issue between
> > 2.2.xx and 2.4.0 - but I do have to remember to change it back between
> > whiles... a better way would be ?
>
> Well...hmm, what doesn't work?  You mean you can't build a kernel
> unless you make /usr/src/linux point to the kernel source you're
> building?  This is odd, as I haven't done that...ever!  In fact,
> there's no directories in /usr/src on my machine.

IIRC, there was a time (long before 2.0) that kernel builds did look for
includes in /usr/include/, so you had to unpack (or symlink) your kernel in
/usr/src/linux/. Fortunately the include path was changed to put
root_of_build/include first.

Gr{oetje,eeting}s,

						Geert

--
Geert Uytterhoeven -- There's lots of Linux beyond ia32 -- geert@linux-m68k.org

In personal conversations with technical people, I call myself a hacker. But
when I'm talking to journalists I just say "programmer" or something like that.
							    -- Linus Torvalds


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Martin Costabel]

Geert Uytterhoeven wrote:
>
> On Thu, 20 Jul 2000, Josh Huber wrote:
>
> You don't have to put your kernel in /usr/src, and you DON'T have to
> symlink /usr/src/linux to it before you build.  The symlinks (on
> broken RedHat derivatives) in /usr/include should point to the kernel
> headers that your libc was built againt, otherwise you risk breaking
> binary compatibility.

This is an argument I have heard several times, but I never understood:
If this risks breaking binary compatibility, then your kernel (compiled
with its own headers, after all) might not be binary compatible with
your glibc. Not nice.

> > On Thu, Jul 20, 2000 at 02:45:56PM +0100, Iain Sandoe wrote:
> > > I guess I *must* have one of those broken derivatives... and it doesn't work
> > > for me without that step...  Admittedly, this is mostly an issue between
> > > 2.2.xx and 2.4.0 - but I do have to remember to change it back between
> > > whiles... a better way would be ?
> >
> > Well...hmm, what doesn't work?  You mean you can't build a kernel
> > unless you make /usr/src/linux point to the kernel source you're
> > building?  This is odd, as I haven't done that...ever!  In fact,
> > there's no directories in /usr/src on my machine.
>
> IIRC, there was a time (long before 2.0) that kernel builds did look for
> includes in /usr/include/, so you had to unpack (or symlink) your kernel in
> /usr/src/linux/. Fortunately the include path was changed to put
> root_of_build/include first.

There *are* situations where you need /usr/src/linux to point to your
current kernel sources. This is when you compile modules for the current
kernel, a prominent example being MOL.

--
Martin

** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Josh Huber]

[-- Attachment #1: Type: text/plain, Size: 652 bytes --]

On Sat, Jul 22, 2000 at 08:11:07PM +0200, Martin Costabel wrote:
> There *are* situations where you need /usr/src/linux to point to your
> current kernel sources. This is when you compile modules for the current
> kernel, a prominent example being MOL.

Actually, I prefer to add a -I/path/to/kernel/include to the module
makefiles rather than the /usr/src/linux symlink. I suppose it's
personal preference, but I find that having to explicitly specify
where the kernel source is reduces the posibility of a screwed
compile.

-- 
Josh
6B21489A | GnuPG ID/Fingerprint | huber@mclx.com |
61F0 6138 BE7B FEBF A223  E9D1 BFE1 2065 6B21 489A

[-- Attachment #2: Type: application/pgp-signature, Size: 0 bytes --]

Re: problems about __cli()

[Jeff Garzik]

On Mon, 24 Jul 2000, Josh Huber wrote:

> On Sat, Jul 22, 2000 at 08:11:07PM +0200, Martin Costabel wrote:
> > There *are* situations where you need /usr/src/linux to point to your
> > current kernel sources. This is when you compile modules for the current
> > kernel, a prominent example being MOL.
>
> Actually, I prefer to add a -I/path/to/kernel/include to the module
> makefiles rather than the /usr/src/linux symlink. I suppose it's
> personal preference, but I find that having to explicitly specify
> where the kernel source is reduces the posibility of a screwed
> compile.

Moreover, your method Josh is the only sane method IMHO.  Trusting
/usr/src/linux to be correct for whatever kernel version you are
building against is Russian roulette (to put it lightly)...

	Jeff


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

Re: problems about __cli()

[Michel Dänzer]

Iain Sandoe schrieb:
>
> Thu, Jul 20, 2000,  Josh Huber wrote:
> > On Thu, Jul 20, 2000 at 10:19:54AM +0100, Iain Sandoe wrote:
> >>
> > [snip]
> >>
> >> It is *vital* to make sure that there is a symlink named 'linux' in
> >> /usr/src that points to your /usr/src/your-kernel-foo-bar/ because there
> >> are symlinks in /usr/include that expect to use this to find the
> >> build-specific headers.
> >
> > A couple notes:
> >
> > You don't have to put your kernel in /usr/src, and you DON'T have to
> > symlink /usr/src/linux to it before you build.  The symlinks (on
> > broken RedHat derivatives) in /usr/include should point to the kernel
> > headers that your libc was built againt, otherwise you risk breaking
> > binary compatibility.
>
> I guess I *must* have one of those broken derivatives... and it doesn't work
> for me without that step...  Admittedly, this is mostly an issue between
> 2.2.xx and 2.4.0 - but I do have to remember to change it back between
> whiles... a better way would be ?

Have you tried 'make mrproper' (backup your .config ;), put back the old
config, then 'make oldconfig dep vmlinux'? AFAIK the directory where the tree
resides only matters after make dep, and the connection is untied with make
mrproper.


Michel


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/

problems about __cli()

[Rolf Liu]

Hi, all
I am currently compiling the kernel 2.2.13.
A problem occours, it said the "__cli() is not defined".
I wonder where the __cli() is defined in the kernel tree, which file is it
in ?
thanks a  lot.

Rolf Liu
Software Center Motorola China
Global Software Division, Motorola,Inc.
No 2 Dong San Huan Nan Lu (7th Floor)
Chao Yang District, Beijing 100022, P. R. China
Email: rolfl@sc.mcel.mot.com
Phone: 86-10-65642023            Fax: 86-10-65668458
-----------------------------------------------------------------
[  ] General Business Information
[  ] Motorola Internal Use Only
[  ] Motorola Confidential Proprietary


** Sent via the linuxppc-dev mail list. See http://lists.linuxppc.org/