This is the mail archive of the crossgcc@sourceware.org mailing list for the crossgcc project.

See the CrossGCC FAQ for lots more information.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: crosstool-NG for Alpha-Target, Error


Hello Sebastian!
Hello All!

On Sunday 14 September 2008 21:23:15 Sebastian Koenig wrote:
> On Sun, 14 Sep 2008, Yann E. MORIN wrote:
> > DEC-OSF is clearly not supported. I don't know what it costs to support
> > systems other than Linux, but if you are willing to help... ;-)
> How do I have to start to add support for other systems?

This means adding a new 'kernel' to crosstool-NG. That will be a complex task.

First off, try to find the exact target tuple. 'alphaev56-dec-osf' seems to
be OK, as per config.sub. But:
 - I though OSF was the same as Tru64? So it seems we should be using
   alpha64* as the first part of the tuple.
 - the 'dec' part above is the place for the vendor. Can it be set to
   anything else? If not, then provision should be taken to make
   TARGET_VENDOR unavailable for OSF (see below).

Then, grab the latest svn trunk.

Next, create one config variable for every supported kernels (Linux only
for now):

    config ARCH_SUPPORT_KERNEL_LINUX
      bool
      default n

(that way, adding new kernels later will be easy.)

Next, make all architectures select the supported kernels, like:

    config ARCH_alpha
      select ARCH_SUPPORT_KERNEL_LINUX

    config ARCH_arm
      select ARCH_SUPPORT_KERNEL_LINUX

and so for all architectures.

Then, make all kernels depends on supported kernel:

    config KERNEL_LINUX
      depends on ARCH_SUPPORT_KERNEL_LINUX

And do the same for the C libraries:

    config LIBC_GLIBC
      depends on ARCH_SUPPORT_KERNEL_LINUX

    config LIBC_EGLIBC
      depends on ARCH_SUPPORT_KERNEL_LINUX

    config LIBC_UCLIBC
      depends on ARCH_SUPPORT_KERNEL_LINUX

Also, strace, dmalloc, duma, and some others will probably break for anything
except Linux. Make those depends on ARCH_SUPPORT_KERNEL_LINUX as appropriate.

There will probably some config options that depend on the kernel.
TARGET_VENDOR might be one if setting the vendor part of the tuple to 'dec'
is compulsory (which it shouldn't be, I think).

The easy part is over, now... :-) This is a good checkpoint to submit a patch.

Now, hunt all places where Linux is hardcoded. You will find such places in
scripts/functions, in the function CT_DoBuildTargetTuple, and in
scripts/build/cc/gcc.sh & scripts/build/libc/*.sh (uClibc is not impacted).
scripts/build/binutils.sh is also a candidate for inspection. But there might
well be a lot of other places... When you find such hard-coded dependency on
the Linux kerenl, try to find a smart way to make it a run-time dependency.

You will probably have a lot of work in the glibc/eglibc build scripts.

When you are finished, this makes here your second point of choice for
submitting your changes. :-)

The really hard part starts here. Introduce the OSF 'kernel' with a new
config option. Propagate this option down to appropriate places (as for the
Linux kernel).

Progressively build each component until it works. Go on to the next until
all build. Build a test app and check it runs on your machine.

Unfortunately, I can't help much more, as I don't have any Alpha at home,
and much less access to OSF. I don't even know if alpaha*-*-osf needs a
C library like glibc...

If you decide to go down that road, that would be great! I will help you has
much as I can, but that will most probably be limited to hints as how to code
that in crosstool-NG. This could lay down the path to adding other systems,
such as Cygwin, BSD...

Also, posting here to ask for help will undoubtfully be useful. If you know
other mailing lists dedicated or knowledgeable about OSF, then also post
there:
 - the gcc ML for gcc-related issues
 - the glibc ML, for glibc-related problems
 - the binutils ML for binutils-related issues
 - ...

And don't forget that you should split your changes in as much independant
chunks as possible, and submit those in individual patches, so that merging
is easier, both on your part and on mine (trunk will evolve while you make
your changes, and with small chunks, rebasing will be easier).

Hope to read from you soon! :-)

Regards, and good luck!
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +0/33 662376056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| --==< ^_^ >==-- `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
`------------------------------^-------^------------------^--------------------'


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


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]