I'm trying to verify that I can build toolchains and compile
and link kernels for a large set of CPU types using simple kernel config files.
I'm also somewhat foolishly trying to do all this with gcc-3.4.2.
So any problems I run into are a bit hard to pin down to
compiler, kernel, or user error, since this is mostly new territory for me.
Here's another issue.
When I build 2.6.8 for sparc32, using the config file
http://kegel.com/crosstool/crosstool-0.28-rc36/sparc.config ,
I get a link error:
/opt/crosstool/sparc-unknown-linux-gnu/gcc-3.4.2-glibc-2.3.3/bin/sparc-unknown-linux-gnu-ld -m elf32_sparc -T arch/sparc/kernel/vmlinux.lds.s arch/sparc/kernel/head.o arch/sparc/kernel/init_task.o init/built-in.o --start-group
usr/built-in.o arch/sparc/kernel/built-in.o arch/sparc/mm/built-in.o arch/sparc/math-emu/built-in.o kernel/built-in.o mm/built-in.o fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o lib/lib.a
arch/sparc/prom/lib.a arch/sparc/lib/lib.a lib/built-in.o arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o sound/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o arch/sparc/boot/btfix.o -o
arch/sparc/boot/image
/opt/crosstool/sparc-unknown-linux-gnu/gcc-3.4.2-glibc-2.3.3/bin/sparc-unknown-linux-gnu-ld: cannot open linker script file arch/sparc/kernel/vmlinux.lds.s: No such file or directory
make[1]: *** [arch/sparc/boot/image] Error 1
make: *** [image] Error 2
Anyone seen this?
Thanks,
Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
> I'm trying to verify that I can build toolchains and compile
> and link kernels for a large set of CPU types using simple kernel config
> files.
> I'm also somewhat foolishly trying to do all this with gcc-3.4.2.
> So any problems I run into are a bit hard to pin down to
> compiler, kernel, or user error, since this is mostly new territory for
> me.
>
> Here's another issue.
> When I build 2.6.8 for sparc32, using the config file
> http://kegel.com/crosstool/crosstool-0.28-rc36/sparc.config ,
> I get a link error:
>
> /opt/crosstool/sparc-unknown-linux-gnu/gcc-3.4.2-glibc-2.3.3/bin/sparc-unknown-linux-gnu-ld
> -m elf32_sparc -T arch/sparc/kernel/vmlinux.lds.s
> arch/sparc/kernel/head.o arch/sparc/kernel/init_task.o init/built-in.o
> --start-group
> usr/built-in.o arch/sparc/kernel/built-in.o arch/sparc/mm/built-in.o
> arch/sparc/math-emu/built-in.o kernel/built-in.o mm/built-in.o
> fs/built-in.o ipc/built-in.o security/built-in.o crypto/built-in.o
> lib/lib.a
> arch/sparc/prom/lib.a arch/sparc/lib/lib.a lib/built-in.o
> arch/sparc/prom/built-in.o arch/sparc/lib/built-in.o drivers/built-in.o
> sound/built-in.o net/built-in.o --end-group .tmp_kallsyms2.o
> arch/sparc/boot/btfix.o -o
> arch/sparc/boot/image
Look like arch/sparc/boot/Makefile is too old.
vmlinux.lds.s were renamed to vmlinux.lds 2004/08/15 - maybe you need to
checkout that file?
Sam
At some point in the past, Dan Kegel wrote:
>> I'm trying to verify that I can build toolchains and compile
>> and link kernels for a large set of CPU types using simple kernel config
>> files.
>> I'm also somewhat foolishly trying to do all this with gcc-3.4.2.
>> So any problems I run into are a bit hard to pin down to
>> compiler, kernel, or user error, since this is mostly new territory for
>> me.
>> Here's another issue.
>> When I build 2.6.8 for sparc32, using the config file
>> http://kegel.com/crosstool/crosstool-0.28-rc36/sparc.config ,
>> I get a link error:
On Tue, Sep 21, 2004 at 12:50:49PM +0200, Sam Ravnborg wrote:
> Look like arch/sparc/boot/Makefile is too old.
> vmlinux.lds.s were renamed to vmlinux.lds 2004/08/15 - maybe you need to
> checkout that file?
I don't see this kind of issue in current 2.6.x; what's going on?
-- wli
William Lee Irwin III wrote:
>>Look like arch/sparc/boot/Makefile is too old.
>>vmlinux.lds.s were renamed to vmlinux.lds 2004/08/15 - maybe you need to
>>checkout that file?
>
> I don't see this kind of issue in current 2.6.x; what's going on?
Figured it out. It was user error. I had an outdated patch.
Sorry for the noise. Next time I'll check my patches more carefully.
- Dan
p.s. For what it's worth, I only need to apply five patches to
vanilla 2.6.8 to get past various build errors:
60 258 2483 kaz-types.patch
50 207 2088 linux-2.6.8-arm-nonofpu.patch
683 2328 27265 linux-2.6.8-build_on_case_insensitive_fs-1.patch
285 1215 10145 linux-2.6.8-m68k-kludge.patch
28 122 1028 linux-2.6.8-noshared-kconfig.patch
The build_on_case_insensitive_fs patch is the one that was out of date.
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
On Tue, Sep 21, 2004 at 10:40:24PM -0700, Dan Kegel wrote:
> 683 2328 27265 linux-2.6.8-build_on_case_insensitive_fs-1.patch
> 28 122 1028 linux-2.6.8-noshared-kconfig.patch
Can you please post these two patches.
The fist I hope is very small today.
Sam
Sam Ravnborg wrote:
> On Tue, Sep 21, 2004 at 10:40:24PM -0700, Dan Kegel wrote:
>> 683 2328 27265 linux-2.6.8-build_on_case_insensitive_fs-1.patch
>> 28 122 1028 linux-2.6.8-noshared-kconfig.patch
>
> Can you please post these two patches.
> The fist I hope is very small today.
OK, here they are, plus a third one that also seems neccessary:
This one's by Martin Schaffner:
http://www.kegel.com/crosstool/crosstool-0.28-rc37/patches/linux-2.6.8/linux-2.6.8-build_on_case_insensitive_fs.patch
This one's by Kevin Hilman. I haven't tried it yet, but seems neccessary:
http://www.kegel.com/crosstool/linux-2.6.8-netfilter-case-insensitive.patch
Both of the above choose arbitrary ways to avoid using
filenames identical but for case. Feel free to pick
some other way, there's nothing magic about the names we picked.
This one's after an idea by [email protected],
but it's small enough to be considered trivial. Many OS's
don't support shared libraries as easily as Linux does,
and there's nothing to be gained by making libkconfig shared, so don't.
http://www.kegel.com/crosstool/crosstool-0.28-rc37/patches/linux-2.6.8/linux-2.6.8-noshared-kconfig.patch
Anything you can do to help get these patches
reviewed and possibly applied would be quite welcome.
- Dan
--
My technical stuff: http://kegel.com
My politics: see http://www.misleader.org for examples of why I'm for regime change
On Wed, Oct 06, 2004 at 10:57:29PM -0700, Dan Kegel wrote:
> Sam Ravnborg wrote:
> >On Tue, Sep 21, 2004 at 10:40:24PM -0700, Dan Kegel wrote:
> >> 683 2328 27265 linux-2.6.8-build_on_case_insensitive_fs-1.patch
> >> 28 122 1028 linux-2.6.8-noshared-kconfig.patch
> >
> >Can you please post these two patches.
> >The fist I hope is very small today.
>
> OK, here they are, plus a third one that also seems neccessary:
>
> This one's by Martin Schaffner:
> http://www.kegel.com/crosstool/crosstool-0.28-rc37/patches/linux-2.6.8/linux-2.6.8-build_on_case_insensitive_fs.patch
>
Most of this is done in current linus-BK. I'm planning to handle
asm-offset in another way and will then start to get rid of .S -> .s
> This one's by Kevin Hilman. I haven't tried it yet, but seems neccessary:
> http://www.kegel.com/crosstool/linux-2.6.8-netfilter-case-insensitive.patch
>
This should be taken with the netfilter people.
> Both of the above choose arbitrary ways to avoid using
> filenames identical but for case. Feel free to pick
> some other way, there's nothing magic about the names we picked.
>
> This one's after an idea by [email protected],
> but it's small enough to be considered trivial. Many OS's
> don't support shared libraries as easily as Linux does,
> and there's nothing to be gained by making libkconfig shared, so don't.
> http://www.kegel.com/crosstool/crosstool-0.28-rc37/patches/linux-2.6.8/linux-2.6.8-noshared-kconfig.patch
>
I will give this a try - and apply if I see no problems.
Sam
On Sat, Oct 16, 2004 at 11:00:24PM +0200, Sam Ravnborg wrote:
> On Wed, Oct 06, 2004 at 10:57:29PM -0700, Dan Kegel wrote:
> > Sam Ravnborg wrote:
> > >On Tue, Sep 21, 2004 at 10:40:24PM -0700, Dan Kegel wrote:
> > >> 683 2328 27265 linux-2.6.8-build_on_case_insensitive_fs-1.patch
> > >> 28 122 1028 linux-2.6.8-noshared-kconfig.patch
> > >
> > >Can you please post these two patches.
> > >The fist I hope is very small today.
> >
> > OK, here they are, plus a third one that also seems neccessary:
> >
> > This one's by Martin Schaffner:
> > http://www.kegel.com/crosstool/crosstool-0.28-rc37/patches/linux-2.6.8/linux-2.6.8-build_on_case_insensitive_fs.patch
> >
> Most of this is done in current linus-BK. I'm planning to handle
> asm-offset in another way and will then start to get rid of .S -> .s
Converting .S -> .s is useful for debugging - please don't cripple the
kernel developers just because some filesystems are case-challenged.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
On Sat, Oct 16, 2004 at 08:06:27PM +0100, Russell King wrote:
>
> Converting .S -> .s is useful for debugging - please don't cripple the
> kernel developers just because some filesystems are case-challenged.
Does the debug tools rely on files named *.s then?
There are today ~1400 files named *.S in the tree, but none named *.s.
So my idea was to do it like:
*.S => *.asm => *.o
But if this breaks some debugging tools I would like to know.
Btw. this is not about "case-challenged" filesystems in general. This is
about making the kernel usefull out-of-the-box for the increasing
embedded market.
Less work-around patces needed the better. And these people are often
bound to Windoze boxes - for different reasons. And the individual
developer may not be able to change this.
Sam
On Sat, Oct 16, 2004 at 11:24:40PM +0200, Sam Ravnborg wrote:
> On Sat, Oct 16, 2004 at 08:06:27PM +0100, Russell King wrote:
> >
> > Converting .S -> .s is useful for debugging - please don't cripple the
> > kernel developers just because some filesystems are case-challenged.
>
> Does the debug tools rely on files named *.s then?
>
> There are today ~1400 files named *.S in the tree, but none named *.s.
> So my idea was to do it like:
> *.S => *.asm => *.o
> But if this breaks some debugging tools I would like to know.
*.asm is nonstanard naming. If we have to support case-challenged
filesystems, please ensure that the rest of the nonbroken world can
continue as they have done for the last few decades and live happily
unaffected by these problems.
> Btw. this is not about "case-challenged" filesystems in general. This is
> about making the kernel usefull out-of-the-box for the increasing
> embedded market.
> Less work-around patces needed the better. And these people are often
> bound to Windoze boxes - for different reasons. And the individual
> developer may not be able to change this.
You still need a case-sensitive filesystem to be able to create a root
filesystem for their embedded device. I think you'll find that issues
surrounding caseful filenames in the kernel is the least of their
problems.
--
Russell King
Linux kernel 2.6 ARM Linux - http://www.arm.linux.org.uk/
maintainer of: 2.6 PCMCIA - http://pcmcia.arm.linux.org.uk/
2.6 Serial core
Russell King wrote:
>>Btw. this is not about "case-challenged" filesystems in general. This is
>>about making the kernel usefull out-of-the-box for the increasing
>>embedded market.
>>Less work-around patces needed the better. And these people are often
>>bound to Windoze boxes - for different reasons. And the individual
>>developer may not be able to change this.
Hear, hear!
> You still need a case-sensitive filesystem to be able to create a root
> filesystem for their embedded device.
A case-preserving filesystem should be enough. Or do you have a counterexample?
In any case, when I was building embedded filesystems,
I used an ext2 image file with genext2fs regardless of which operating
system I was running; made it a heck of a lot easier to
do things like create device files.
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Sat, Oct 16, 2004 at 08:40:01PM +0100, Russell King wrote:
> On Sat, Oct 16, 2004 at 11:24:40PM +0200, Sam Ravnborg wrote:
> > On Sat, Oct 16, 2004 at 08:06:27PM +0100, Russell King wrote:
> > >
> > > Converting .S -> .s is useful for debugging - please don't cripple the
> > > kernel developers just because some filesystems are case-challenged.
> >
> > Does the debug tools rely on files named *.s then?
> >
> > There are today ~1400 files named *.S in the tree, but none named *.s.
> > So my idea was to do it like:
> > *.S => *.asm => *.o
> > But if this breaks some debugging tools I would like to know.
>
> *.asm is nonstanard naming. If we have to support case-challenged
> filesystems, please ensure that the rest of the nonbroken world can
> continue as they have done for the last few decades and live happily
> unaffected by these problems.
I still do not see how a kernel developer are affected by changing
the extension of an intermidiate file - please explain.
Sam
On Sun, Oct 17, 2004 at 12:04:27AM +0200, Sam Ravnborg wrote:
> On Sat, Oct 16, 2004 at 08:40:01PM +0100, Russell King wrote:
> > On Sat, Oct 16, 2004 at 11:24:40PM +0200, Sam Ravnborg wrote:
> > > On Sat, Oct 16, 2004 at 08:06:27PM +0100, Russell King wrote:
> > > >
> > > > Converting .S -> .s is useful for debugging - please don't cripple the
> > > > kernel developers just because some filesystems are case-challenged.
> > >
> > > Does the debug tools rely on files named *.s then?
> > >
> > > There are today ~1400 files named *.S in the tree, but none named *.s.
> > > So my idea was to do it like:
> > > *.S => *.asm => *.o
> > > But if this breaks some debugging tools I would like to know.
> >
> > *.asm is nonstanard naming. If we have to support case-challenged
> > filesystems, please ensure that the rest of the nonbroken world can
> > continue as they have done for the last few decades and live happily
> > unaffected by these problems.
>
> I still do not see how a kernel developer are affected by changing
> the extension of an intermidiate file - please explain.
hmm, maybe because they expect the output of the
preprocessed assembly code to have the prefix .s
instead of .asm (see gcc man page and play with
gcc -S)
GCC(1) GNU Tools GCC(1)
.s Assembler source; assemble
.S Assembler source; preprocess, assemble
best,
Herbert
>
> Sam
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Herbert Poetzl wrote:
>>>>>Converting .S -> .s is useful for debugging - please don't cripple the
>>>>>kernel developers just because some filesystems are case-challenged.
>>>>
>>>>Does the debug tools rely on files named *.s then?
>>>>
>>>>There are today ~1400 files named *.S in the tree, but none named *.s.
>>>>So my idea was to do it like:
>>>>*.S => *.asm => *.o
>>>>But if this breaks some debugging tools I would like to know.
>>>
>>>*.asm is nonstanard naming. If we have to support case-challenged
>>>filesystems, please ensure that the rest of the nonbroken world can
>>>continue as they have done for the last few decades and live happily
>>>unaffected by these problems.
>>
>>I still do not see how a kernel developer are affected by changing
>>the extension of an intermidiate file - please explain.
>
> hmm, maybe because they expect the output of the
> preprocessed assembly code to have the prefix .s
> instead of .asm (see gcc man page and play with
> gcc -S)
The only .s/.S ambiguities that need resolving are intermediate files,
so fixing them should only require changing a few Makefile rules.
Let's wait and see what the patch looks like before we
argue about it; maybe it will be simple to make everybody
happy here (well, except those who hate the idea of
letting anyone compile Linux kernels on Cgywin or MacOSX).
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Sun, Oct 17, 2004 at 09:42:21AM -0700, Dan Kegel wrote:
> Herbert Poetzl wrote:
> >>>>>Converting .S -> .s is useful for debugging - please don't cripple the
> >>>>>kernel developers just because some filesystems are case-challenged.
> >>>>
> >>>>Does the debug tools rely on files named *.s then?
> >>>>
> >>>>There are today ~1400 files named *.S in the tree, but none named *.s.
> >>>>So my idea was to do it like:
> >>>>*.S => *.asm => *.o
> >>>>But if this breaks some debugging tools I would like to know.
> >>>
> >>>*.asm is nonstanard naming. If we have to support case-challenged
> >>>filesystems, please ensure that the rest of the nonbroken world can
> >>>continue as they have done for the last few decades and live happily
> >>>unaffected by these problems.
> >>
> >>I still do not see how a kernel developer are affected by changing
> >>the extension of an intermidiate file - please explain.
> >
> >hmm, maybe because they expect the output of the
> >preprocessed assembly code to have the prefix .s
> >instead of .asm (see gcc man page and play with
> >gcc -S)
>
> The only .s/.S ambiguities that need resolving are intermediate files,
> so fixing them should only require changing a few Makefile rules.
> Let's wait and see what the patch looks like before we
> argue about it; maybe it will be simple to make everybody
> happy here (well, except those who hate the idea of
> letting anyone compile Linux kernels on Cgywin or MacOSX).
fair enough, but Mac OS X doesn't require this (UFS
is case sensititve, and probably no linux guy/gal uses
HFS+), so IMHO it's 'just' Cygwin* folks here ...
best,
Herbert
> - Dan
>
>
> --
> Trying to get a job as a c++ developer? See
> http://kegel.com/academy/getting-hired.html
Herbert Poetzl wrote:
>>The only .s/.S ambiguities that need resolving are intermediate files,
>>so fixing them should only require changing a few Makefile rules.
>>Let's wait and see what the patch looks like before we
>>argue about it; maybe it will be simple to make everybody
>>happy here (well, except those who hate the idea of
>>letting anyone compile Linux kernels on Cgywin or MacOSX).
>
>
> fair enough, but Mac OS X doesn't require this (UFS
> is case sensititve, and probably no linux guy/gal uses
> HFS+), so IMHO it's 'just' Cygwin* folks here ...
MacOSX uses HFS+ by default. As a result, 99% of
people using MacOSX are going to use HFS+. I'm
a serious Linux developer, but if I owned a Mac,
I'd probably leave it set to HFS+, since I like
to keep my systems vanilla (it makes it easier to
pick up my stuff and use it on someone else's machine).
Thus it's not just Cygwin that's affected; this is
a real issue for MacOSX as commonly configured.
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Sun, Oct 17, 2004 at 10:47:07AM -0700, Dan Kegel wrote:
> Herbert Poetzl wrote:
> >>The only .s/.S ambiguities that need resolving are intermediate files,
> >>so fixing them should only require changing a few Makefile rules.
> >>Let's wait and see what the patch looks like before we
> >>argue about it; maybe it will be simple to make everybody
> >>happy here (well, except those who hate the idea of
> >>letting anyone compile Linux kernels on Cgywin or MacOSX).
> >
> >fair enough, but Mac OS X doesn't require this (UFS
> >is case sensititve, and probably no linux guy/gal uses
> >HFS+), so IMHO it's 'just' Cygwin* folks here ...
>
> MacOSX uses HFS+ by default. As a result, 99% of
> people using MacOSX are going to use HFS+.
> I'm a serious Linux developer, but if I owned a Mac,
> I'd probably leave it set to HFS+, since I like
> to keep my systems vanilla (it makes it easier to
> pick up my stuff and use it on someone else's machine).
> Thus it's not just Cygwin that's affected; this is
> a real issue for MacOSX as commonly configured.
hmm, well, probably the result of a halfhearted attempt
to satisfy both, the OpenStep and the MacOS Classic
developers ... but that doesn't belong here ...
just as fact:
# gcc --version
gcc (GCC) 3.3 20030304 (Apple Computer, Inc. build 1666)
Copyright (C) 2002 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
# man gcc
file.s
Assembler code. Apple's version of GCC runs the preprocessor on
these files as well as those ending in .S.
file.S
Assembler code which must be preprocessed.
# uname -a
Darwin anson 7.5.0 Darwin Kernel Version 7.5.0: Thu Aug 5 19:26:16 PDT 2004; root:xnu/xnu-517.7.21.obj~3/RELEASE_PPC Power Macintosh powerp
ONTOPIC:
why not move the intermediate files into a separate
subdirectory which can easily be removed on cleanup?
of course, gcc could also be changed to use different
extensions than .s and .S for those files ...
best,
Herbert
> - Dan
>
> --
> Trying to get a job as a c++ developer? See
> http://kegel.com/academy/getting-hired.html
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
Herbert Poetzl wrote:
> why not move the intermediate files into a separate
> subdirectory which can easily be removed on cleanup?
That would require zero code changes, and is a
pretty good workaround at least for my case,
where I can easily build with O=objdir.
Thanks for pointing it out!
- Dan
--
Trying to get a job as a c++ developer? See http://kegel.com/academy/getting-hired.html
On Sat, Oct 16, 2004 at 11:00:24PM +0200, Sam Ravnborg wrote:
> > This one's after an idea by [email protected],
> > but it's small enough to be considered trivial. Many OS's
> > don't support shared libraries as easily as Linux does,
> > and there's nothing to be gained by making libkconfig shared, so don't.
> > http://www.kegel.com/crosstool/crosstool-0.28-rc37/patches/linux-2.6.8/linux-2.6.8-noshared-kconfig.patch
> >
>
> I will give this a try - and apply if I see no problems.
Applied in a slightly simpler version.
Sam