Patchwork kernel/linux: change arch tuple to use -uclinux for uclinux toolchains

login
register
mail settings
Submitter Esben Haabendal
Date Sept. 25, 2012, 12:29 p.m.
Message ID <87wqziffpo.fsf@arh128.prevas.dk>
Download mbox | patch
Permalink /patch/186796/
State Rejected
Headers show

Comments

Esben Haabendal - Sept. 25, 2012, 12:29 p.m.
# HG changeset patch
# User Esben Haabendal <esben.haabendal@prevas.dk>
# Date 1348575902 -7200
# Node ID 893b394644d2228baead66c2bb599f3ab1796a28
# Parent  f46a1d105896c89f697ff7f2c8ebb6b7b8403d5d
kernel/linux: change arch tuple to use -uclinux for uclinux toolchains

This fixes at least ColdFire uClinux builds, as gcc filters out
all m68k no-mmu cpus for linux builds and (some) mmu cpus for uclinux
builds.

Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>


--
For unsubscribe information see http://sourceware.org/lists.html#faq
Yann E. MORIN - Sept. 25, 2012, 4:41 p.m.
Esben, All,

On Tuesday 25 September 2012 14:29:39 Esben Haabendal wrote:
> # HG changeset patch
> # User Esben Haabendal <esben.haabendal@prevas.dk>
> # Date 1348575902 -7200
> # Node ID 893b394644d2228baead66c2bb599f3ab1796a28
> # Parent  f46a1d105896c89f697ff7f2c8ebb6b7b8403d5d
> kernel/linux: change arch tuple to use -uclinux for uclinux toolchains
> 
> This fixes at least ColdFire uClinux builds, as gcc filters out
> all m68k no-mmu cpus for linux builds and (some) mmu cpus for uclinux
> builds.
> 
> Signed-off-by: "Esben Haabendal" <esben@haabendal.dk>
> 
> diff -r f46a1d105896 -r 893b394644d2 scripts/build/kernel/linux.sh
> --- a/scripts/build/kernel/linux.sh	Sun Sep 23 11:59:28 2012 +0900
> +++ b/scripts/build/kernel/linux.sh	Tue Sep 25 14:25:02 2012 +0200
> @@ -6,12 +6,7 @@
>      if [ "${CT_ARCH_USE_MMU}" = "y" ]; then
>          CT_TARGET_KERNEL="linux"
>      else
> -    # Sometime, noMMU linux targets have a -uclinux tuple, while
> -    # sometime it's -linux. We currently have only one noMMU linux
> -    # target, and it uses -linux, so let's just use that. Time
> -    # to fix that later...
> -    #    CT_TARGET_KERNEL="uclinux"
> -        CT_TARGET_KERNEL="linux"
> +        CT_TARGET_KERNEL="uclinux"
>      fi
>  }

NAK.

IIRC, the blackfin arch does not use '-uclinux', but '-linux':

    $ hg blame scripts/build/kernel/linux.sh
    [--SNIP--]
    1345: CT_DoKernelTupleValues() {
    1345:     if [ "${CT_ARCH_USE_MMU}" = "y" ]; then
    1345:         CT_TARGET_KERNEL="linux"
    1345:     else
    1910:     # Sometime, noMMU linux targets have a -uclinux tuple, while
    1910:     # sometime it's -linux. We currently have only one noMMU linux
    1910:     # target, and it uses -linux, so let's just use that. Time
    1910:     # to fix that later...
    1910:     #    CT_TARGET_KERNEL="uclinux"
    1910:         CT_TARGET_KERNEL="linux"
    1345:     fi
    1345: }
    [--SNIP--]

    $ hg log -v -r 1910 --template '{desc}\n'
    Add basic support for the Blackfin architecture
    [--SNIP--]
    Apply the patch to the kernel/linux build script to use 'linux'
    in the noMMU tuples. See:
      http://sourceware.org/ml/crossgcc/2010-04/msg00010.html

Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for flat-binaries
with no shared libs, and 'bfin-linux' for FDPIC-ELF that allows shared libs.

So, if there are archs that want -uclinux, it has to be conditional.

Regards,
Yann E. MORIN.
Mike Frysinger - Sept. 25, 2012, 4:46 p.m.
On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote:
> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for
> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that
> allows shared libs.

correct, the current convention is that "-uclinux" is for FLAT targets.  
although minor correction: most FLAT systems do support shared FLAT binaries, 
but they're a horrible abomination that few people use :).
-mike
Esben Haabendal - Sept. 25, 2012, 6:18 p.m.
Mike Frysinger <vapier@gentoo.org> writes:

> On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote:
>> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for
>> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that
>> allows shared libs.
>
> correct, the current convention is that "-uclinux" is for FLAT
> targets.  

Ok, but where does this convention come from.  Or rather, who follows
this convention?

It does not generally seem to be the convention used in GCC, at least
not for all archs.

If linux-gnu is linux with glibc, linux-uclibc is uClinux/FDPIC-ELF with
uClibc, and uclinux-uclibc is uClinux/FLAT with uClibc.  What arch tuple
should then be used for linux with uClibc?  I don't see the benefit of
not being able to tell it apart from uClinux/FDPIC-ELF with uClibc.

If you take a look at gcc/config.gcc

it has stuff like

--------
m68k-*-uclinuxoldabi*)          # Motorola m68k/ColdFire running uClinux
                                # with uClibc, using the original
                                # m68k-elf-based ABI
        default_m68k_cpu=68020
        default_cf_cpu=5206
        tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h elfos.h m68k/uclinux-oldabi.h glibc-stdint.h"
        tm_defines="${tm_defines} MOTOROLA=1"
        tmake_file="m68k/t-floatlib m68k/t-uclinux"
        ;;
m68k-*-uclinux*)                # Motorola m68k/ColdFire running uClinux
                                # with uClibc, using the new GNU/Linux-style
                                # ABI.
        default_m68k_cpu=68020
        default_cf_cpu=5206
        tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h"
        tm_defines="${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1"
        extra_options="${extra_options} linux.opt"
        tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs"
        ;;
m68k-*-linux*)          # Motorola m68k's running GNU/Linux
                                # with ELF format using glibc 2
                                # aka the GNU/Linux C library 6.
        default_m68k_cpu=68020
        default_cf_cpu=5475
        with_arch=${with_arch:-m68k}
        tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h m68k/linux.h ./sysroot-suffix.h"
        extra_options="${extra_options} m68k/ieee.opt"
        tm_defines="${tm_defines} MOTOROLA=1"
        tmake_file="${tmake_file} m68k/t-floatlib m68k/t-linux m68k/t-mlibs"
        # if not configured with --enable-sjlj-exceptions, bump the
        # libgcc version number
        if test x$sjlj != x1; then
            tmake_file="$tmake_file m68k/t-slibgcc-elf-ver"
        fi
        ;;
--------

I guess that mean that at least for m68k, the convention you mention is
not shared with GCC.

When building an m68k cross gcc, using *-*-linux-* will filter out any
target devices that does not have the FL_MMU flag set (in
gcc/config/m68k/m68k-devices.def).  When building with *-*-uclinux-*,
only those devices without FL_MMU flag set, or with FL_UCLINUX flag set
will be available.

As such, the convention does not work for m68k.

As for my current needs, this can be made conditional for m68k.

That said, I don't think the convention is the most sane one, as it
would be best to have "linux-uclibc" mean the same thing independent of
the cpu prefix, and also in line with the principle of least surprise,
it would make sense to use "uclinux-*" for uclinux archs :-)

/Esben




--
For unsubscribe information see http://sourceware.org/lists.html#faq
Mike Frysinger - Sept. 25, 2012, 8:37 p.m.
On Tuesday 25 September 2012 14:18:38 Esben Haabendal wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote:
> >> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for
> >> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that
> >> allows shared libs.
> > 
> > correct, the current convention is that "-uclinux" is for FLAT
> > targets.
> 
> Ok, but where does this convention come from.  Or rather, who follows
> this convention?
> 
> It does not generally seem to be the convention used in GCC, at least
> not for all archs.
> 
> If linux-gnu is linux with glibc, linux-uclibc is uClinux/FDPIC-ELF with
> uClibc, and uclinux-uclibc is uClinux/FLAT with uClibc.

uClibc supports multiple file formats (including FDPIC-ELF and FLAT).  if you 
see a toolchain end in "-uclinux" or "-uclibc*", you're pretty much guaranteed 
to be using uClibc.

further, pretty much every target i've seen so far that ends in -uclinux was 
targeting the FLAT file format.  for Blackfin targets, we wanted a new tuple 
when using FDPIC-ELF, so we went with linux-uclibc rather than uclinux.  after 
all, when you're running Linux with the ELF format, the fact that you lack a 
MMU is largely transparent to userland (ignoring lack of fork).

> What arch tuple should then be used for linux with uClibc?  I don't see the
> benefit of not being able to tell it apart from uClinux/FDPIC-ELF with
> uClibc.

i don't understand the question.  "uclinux" means you're running Linux with 
uClibc, as does "linux-uclibc".

> --------
> m68k-*-uclinuxoldabi*)          # Motorola m68k/ColdFire running uClinux
>                                 # with uClibc, using the original
>                                 # m68k-elf-based ABI
>         default_m68k_cpu=68020
>         default_cf_cpu=5206
>         tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h
> elfos.h m68k/uclinux-oldabi.h glibc-stdint.h" tm_defines="${tm_defines}
> MOTOROLA=1"
>         tmake_file="m68k/t-floatlib m68k/t-uclinux"
>         ;;
> m68k-*-uclinux*)                # Motorola m68k/ColdFire running uClinux
>                                 # with uClibc, using the new
> GNU/Linux-style # ABI.
>         default_m68k_cpu=68020
>         default_cf_cpu=5206
>         tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h
> flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h"
> tm_defines="${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1"
>         extra_options="${extra_options} linux.opt"
>         tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs"
>         ;;
> m68k-*-linux*)          # Motorola m68k's running GNU/Linux
>                                 # with ELF format using glibc 2
>                                 # aka the GNU/Linux C library 6.
>         default_m68k_cpu=68020
>         default_cf_cpu=5475
>         with_arch=${with_arch:-m68k}
>         tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h
> m68k/linux.h ./sysroot-suffix.h" extra_options="${extra_options}
> m68k/ieee.opt"
>         tm_defines="${tm_defines} MOTOROLA=1"
>         tmake_file="${tmake_file} m68k/t-floatlib m68k/t-linux
> m68k/t-mlibs" # if not configured with --enable-sjlj-exceptions, bump the
> # libgcc version number
>         if test x$sjlj != x1; then
>             tmake_file="$tmake_file m68k/t-slibgcc-elf-ver"
>         fi
>         ;;
> --------
> 
> I guess that mean that at least for m68k, the convention you mention is
> not shared with GCC.

m68k doesn't support FDPIC-ELF.  i don't know what you're trying to show.

> When building an m68k cross gcc, using *-*-linux-* will filter out any
> target devices that does not have the FL_MMU flag set (in
> gcc/config/m68k/m68k-devices.def).  When building with *-*-uclinux-*,
> only those devices without FL_MMU flag set, or with FL_UCLINUX flag set
> will be available.
> 
> As such, the convention does not work for m68k.
> 
> As for my current needs, this can be made conditional for m68k.
> 
> That said, I don't think the convention is the most sane one, as it
> would be best to have "linux-uclibc" mean the same thing independent of
> the cpu prefix, and also in line with the principle of least surprise,
> it would make sense to use "uclinux-*" for uclinux archs :-)

looks to me like gcc only uses the FL_{MMU,UCLINUX} flags to figure out whether 
to build FLAT shared libraries.  so if you want those things, use m68k-
uclinux.  if you don't want those things, then use whatever target you want.
-mike
Esben Haabendal - Sept. 25, 2012, 9:18 p.m.
Mike Frysinger <vapier@gentoo.org> writes:

> On Tuesday 25 September 2012 14:18:38 Esben Haabendal wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> > On Tuesday 25 September 2012 12:41:42 Yann E. MORIN wrote:
>> >> Basically, 'bfin-elf' is for bare-metal, 'bfin-uclinux' if for
>> >> flat-binaries with no shared libs, and 'bfin-linux' for FDPIC-ELF that
>> >> allows shared libs.
>> > 
>> > correct, the current convention is that "-uclinux" is for FLAT
>> > targets.
>> 
>> Ok, but where does this convention come from.  Or rather, who follows
>> this convention?
>> 
>> It does not generally seem to be the convention used in GCC, at least
>> not for all archs.
>> 
>> If linux-gnu is linux with glibc, linux-uclibc is uClinux/FDPIC-ELF with
>> uClibc, and uclinux-uclibc is uClinux/FLAT with uClibc.
>
> uClibc supports multiple file formats (including FDPIC-ELF and FLAT).
> if you see a toolchain end in "-uclinux" or "-uclibc*", you're pretty
> much guaranteed to be using uClibc.

Yes.

> further, pretty much every target i've seen so far that ends in -uclinux was 
> targeting the FLAT file format.

You seem to miss the point I am making here. This is not true for
m68k/coldfire.  You must use *-*-uclinux-* to configure gcc for the
non-mmu m68k/cf cpus.

> for Blackfin targets, we wanted a new tuple when using FDPIC-ELF, so
> we went with linux-uclibc rather than uclinux.  after all, when you're
> running Linux with the ELF format, the fact that you lack a MMU is
> largely transparent to userland (ignoring lack of fork).

Yes, I see that.  But...

>> What arch tuple should then be used for linux with uClibc?  I don't see the
>> benefit of not being able to tell it apart from uClinux/FDPIC-ELF with
>> uClibc.
>
> i don't understand the question.  "uclinux" means you're running Linux with 
> uClibc, as does "linux-uclibc".

I dare to say "no".  With *-*-uclinux-* you are saying you are running
Linux without mmu.  With *-*-linux-uclibc or *-*-uclinux-uclibc you are
saying you are running Linux with uClibc.

With some m68k cpus, you are able to use either Linux with glibc, Linux
(with mmu) with uClibc, or Linux (without mmu, uCLinux) with uClibc.  It
would be rather handy to be able to use different arch tuples for all 3
cases.

>
>> --------
>> m68k-*-uclinuxoldabi*)          # Motorola m68k/ColdFire running uClinux
>>                                 # with uClibc, using the original
>>                                 # m68k-elf-based ABI
>>         default_m68k_cpu=68020
>>         default_cf_cpu=5206
>>         tm_file="${tm_file} m68k/m68k-none.h m68k/m68kelf.h dbxelf.h
>> elfos.h m68k/uclinux-oldabi.h glibc-stdint.h" tm_defines="${tm_defines}
>> MOTOROLA=1"
>>         tmake_file="m68k/t-floatlib m68k/t-uclinux"
>>         ;;
>> m68k-*-uclinux*)                # Motorola m68k/ColdFire running uClinux
>>                                 # with uClibc, using the new
>> GNU/Linux-style # ABI.
>>         default_m68k_cpu=68020
>>         default_cf_cpu=5206
>>         tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h
>> flat.h m68k/linux.h m68k/uclinux.h ./sysroot-suffix.h"
>> tm_defines="${tm_defines} MOTOROLA=1 UCLIBC_DEFAULT=1"
>>         extra_options="${extra_options} linux.opt"
>>         tmake_file="m68k/t-floatlib m68k/t-uclinux m68k/t-mlibs"
>>         ;;
>> m68k-*-linux*)          # Motorola m68k's running GNU/Linux
>>                                 # with ELF format using glibc 2
>>                                 # aka the GNU/Linux C library 6.
>>         default_m68k_cpu=68020
>>         default_cf_cpu=5475
>>         with_arch=${with_arch:-m68k}
>>         tm_file="${tm_file} dbxelf.h elfos.h svr4.h linux.h glibc-stdint.h
>> m68k/linux.h ./sysroot-suffix.h" extra_options="${extra_options}
>> m68k/ieee.opt"
>>         tm_defines="${tm_defines} MOTOROLA=1"
>>         tmake_file="${tmake_file} m68k/t-floatlib m68k/t-linux
>> m68k/t-mlibs" # if not configured with --enable-sjlj-exceptions, bump the
>> # libgcc version number
>>         if test x$sjlj != x1; then
>>             tmake_file="$tmake_file m68k/t-slibgcc-elf-ver"
>>         fi
>>         ;;
>> --------
>> 
>> I guess that mean that at least for m68k, the convention you mention is
>> not shared with GCC.
>
> m68k doesn't support FDPIC-ELF.  i don't know what you're trying to
> show.

I am not just trying to show something, I am trying to build a working
uclinux toolchain for coldfire.  It doesn't really matter for that, that
FDPIC-ELF is not supported, as the problem is here for FLAT.

>> When building an m68k cross gcc, using *-*-linux-* will filter out any
>> target devices that does not have the FL_MMU flag set (in
>> gcc/config/m68k/m68k-devices.def).  When building with *-*-uclinux-*,
>> only those devices without FL_MMU flag set, or with FL_UCLINUX flag set
>> will be available.
>> 
>> As such, the convention does not work for m68k.
>> 
>> As for my current needs, this can be made conditional for m68k.
>> 
>> That said, I don't think the convention is the most sane one, as it
>> would be best to have "linux-uclibc" mean the same thing independent of
>> the cpu prefix, and also in line with the principle of least surprise,
>> it would make sense to use "uclinux-*" for uclinux archs :-)
>
> looks to me like gcc only uses the FL_{MMU,UCLINUX} flags to figure
> out whether to build FLAT shared libraries.

No, gcc uses these flags combined with the arch tuples to sort out which
cpu's that are available (for --with-cpu and -mcpu).  Using linux-uclibc
results in only having the FL_MMU cpus available.

> so if you want those things, use m68k- uclinux.

Exactly :-)

I will rework the patch to set CT_TARGET_KERNEL depending on both
CT_ARCH_USE_MMU and CT_ARCH.  So "linux" for bfin and "uclinux" for
m68k.

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Mike Frysinger - Sept. 26, 2012, 2:33 a.m.
On Tuesday 25 September 2012 17:18:31 Esben Haabendal wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> > On Tuesday 25 September 2012 14:18:38 Esben Haabendal wrote:
> >> What arch tuple should then be used for linux with uClibc?  I don't see
> >> the benefit of not being able to tell it apart from uClinux/FDPIC-ELF
> >> with uClibc.
> > 
> > i don't understand the question.  "uclinux" means you're running Linux
> > with uClibc, as does "linux-uclibc".
> 
> I dare to say "no".  With *-*-uclinux-* you are saying you are running
> Linux without mmu.  With *-*-linux-uclibc or *-*-uclinux-uclibc you are
> saying you are running Linux with uClibc.

Linux is Linux.  "uclinux" is a dead term which has no bearing anymore and 
hasn't for years.  you run Linux w/mmu support turned on or turned off, but 
you're running Linux in either case.  thus saying "Linux with uClibc" is 
meaningless to mmu status.

Blackfin doesn't have a MMU and most likely never will.  bfin-linux-uclibc is 
for running the FDPIC-ELF format with uClibc under Linux.  we build with MMU 
support turned off, but *gcc* does not care at all either way.  uClibc and 
Linux is configured with the MMU turned off.

> With some m68k cpus, you are able to use either Linux with glibc, Linux
> (with mmu) with uClibc, or Linux (without mmu, uCLinux) with uClibc.  It
> would be rather handy to be able to use different arch tuples for all 3
> cases.

running Linux w/mmu support enabled on a processor with a MMU can execute code 
compiled for a system w/mmu disabled.  there's no magic here, just a different 
file format (FLAT) and certain functions disabled (like fork).  similarly, if a 
Blackfin processor was released with a MMU enabled, i could take all the code i 
already have compiled today and run it perfectly fine on that.

> I will rework the patch to set CT_TARGET_KERNEL depending on both
> CT_ARCH_USE_MMU and CT_ARCH.  So "linux" for bfin and "uclinux" for
> m68k.

hard coding one way or the other is wrong.  bfin-uclinux is valid, as is m68k-
uclinux and arm-uclinux and mips-uclinux and many other targets.
-mike
Esben Haabendal - Sept. 26, 2012, 4:47 a.m.
Mike Frysinger <vapier@gentoo.org> writes:

>> I will rework the patch to set CT_TARGET_KERNEL depending on both
>> CT_ARCH_USE_MMU and CT_ARCH.  So "linux" for bfin and "uclinux" for
>> m68k.
>
> hard coding one way or the other is wrong.  bfin-uclinux is valid, as is m68k-
> uclinux and arm-uclinux and mips-uclinux and many other targets.

Well, the fact is that either GCC has to be changed to handle
linux/uclinux in the arch tuple to your preferences, or ct-ng has to be
able to handle it.  The current situations makes ct-ng unable to build
linux-uclibc for m68k cpus without mmu.

So what do you propose?

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq
Mike Frysinger - Sept. 26, 2012, 5:26 a.m.
On Wednesday 26 September 2012 00:47:07 Esben Haabendal wrote:
> Mike Frysinger <vapier@gentoo.org> writes:
> >> I will rework the patch to set CT_TARGET_KERNEL depending on both
> >> CT_ARCH_USE_MMU and CT_ARCH.  So "linux" for bfin and "uclinux" for
> >> m68k.
> > 
> > hard coding one way or the other is wrong.  bfin-uclinux is valid, as is
> > m68k- uclinux and arm-uclinux and mips-uclinux and many other targets.
> 
> Well, the fact is that either GCC has to be changed to handle
> linux/uclinux in the arch tuple to your preferences, or ct-ng has to be
> able to handle it.  The current situations makes ct-ng unable to build
> linux-uclibc for m68k cpus without mmu.

i don't know what the selection of ct-ng looks like as i don't use it.  i'm 
just clarifying incorrect statements made and giving background.

if you want to target m68k systems running Linux w/out an mmu using the FLAT 
format, then "m68k-uclinux" is the tuple you want to use.  hardcoding any arch 
around that logic is wrong.
-mike
Esben Haabendal - Sept. 26, 2012, 6:37 a.m.
Mike Frysinger <vapier@gentoo.org> writes:

> On Wednesday 26 September 2012 00:47:07 Esben Haabendal wrote:
>> Mike Frysinger <vapier@gentoo.org> writes:
>> >> I will rework the patch to set CT_TARGET_KERNEL depending on both
>> >> CT_ARCH_USE_MMU and CT_ARCH.  So "linux" for bfin and "uclinux" for
>> >> m68k.
>> > 
>> > hard coding one way or the other is wrong.  bfin-uclinux is valid, as is
>> > m68k- uclinux and arm-uclinux and mips-uclinux and many other targets.
>> 
>> Well, the fact is that either GCC has to be changed to handle
>> linux/uclinux in the arch tuple to your preferences, or ct-ng has to be
>> able to handle it.  The current situations makes ct-ng unable to build
>> linux-uclibc for m68k cpus without mmu.
>
> i don't know what the selection of ct-ng looks like as i don't use it.  i'm 
> just clarifying incorrect statements made and giving background.

Yes, thank you, highly appreciated. I don't know why, but I somehow
just assumed that FD_PIC_ELF were supported by m68k, but without
support in both GCC or Linux I guess I was being slightly optimistic ;-)

> if you want to target m68k systems running Linux w/out an mmu using
> the FLAT format, then "m68k-uclinux" is the tuple you want to use.

And that is exactly what we will do, which then requires a bit of logic
to not mess up the bfin arch in ct-ng.

/Esben

--
For unsubscribe information see http://sourceware.org/lists.html#faq

Patch

diff -r f46a1d105896 -r 893b394644d2 scripts/build/kernel/linux.sh
--- a/scripts/build/kernel/linux.sh	Sun Sep 23 11:59:28 2012 +0900
+++ b/scripts/build/kernel/linux.sh	Tue Sep 25 14:25:02 2012 +0200
@@ -6,12 +6,7 @@ 
     if [ "${CT_ARCH_USE_MMU}" = "y" ]; then
         CT_TARGET_KERNEL="linux"
     else
-    # Sometime, noMMU linux targets have a -uclinux tuple, while
-    # sometime it's -linux. We currently have only one noMMU linux
-    # target, and it uses -linux, so let's just use that. Time
-    # to fix that later...
-    #    CT_TARGET_KERNEL="uclinux"
-        CT_TARGET_KERNEL="linux"
+        CT_TARGET_KERNEL="uclinux"
     fi
 }