2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?

2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?

[Dan Kegel]

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

Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?

[Sam Ravnborg]

> 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

Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?

[William Lee Irwin III]

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

Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?

[Dan Kegel]

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

Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?

[Sam Ravnborg]

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

Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Dan Kegel]

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 bertrand.marquis@sysgo.com,
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

Re: Building on case-insensitive systems and systems where -shared doesn't work well

[Dan Kegel]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Russell King]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Russell King]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Sam Ravnborg]

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 bertrand.marquis@sysgo.com,
> 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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Sam Ravnborg]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Sam Ravnborg]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well

[Dan Kegel]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Herbert Poetzl]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Building on case-insensitive systems and systems where -shared doesn't work well

[Dan Kegel]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well

[Herbert Poetzl]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well

[Herbert Poetzl]

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 majordomo@vger.kernel.org
> More majordomo info at  http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at  http://www.tux.org/lkml/

Re: Building on case-insensitive systems and systems where -shared doesn't work well

[Dan Kegel]

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

Re: Building on case-insensitive systems and systems where -shared doesn't work well (was: Re: 2.6.8 link failure for sparc32 (vmlinux.lds.s: No such file or directory)?)

[Sam Ravnborg]

On Sat, Oct 16, 2004 at 11:00:24PM +0200, Sam Ravnborg wrote:
 
> > This one's after an idea by bertrand.marquis@sysgo.com,
> > 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