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] |
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] |