[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: [Ltib] NEW LTIB...and Full Toolchain build.... (docu)
|
From: |
Morrison, Tom |
|
Subject: |
RE: [Ltib] NEW LTIB...and Full Toolchain build.... (docu) |
|
Date: |
Wed, 1 Apr 2009 17:01:04 -0400 |
I'm a little confused too...
In my version of LTIB - there is an option to set 1 (and only 1) target.
For the NFS-ONLY target - it does NOT allow you to configure any of the
options about 'remove the user/include directory' (or any other
options),
There are only 2 options available when you select NFS only:
'run a command after buildling the target'
'read only root'...
They do NOT show up because in deployment.lkc - it uses a
depends ! CONFIG_NFS
I worked around the problem, by patching this file my own way!
Tom
>> -----Original Message-----
>> From: Stuart Hughes [mailto:address@hidden
>> Sent: Wednesday, April 01, 2009 12:34 PM
>> To: Morrison, Tom
>> Cc: address@hidden; address@hidden; address@hidden
>> Subject: Re: [Ltib] NEW LTIB...and Full Toolchain build.... (docu)
>>
>> Hi Tom,
>>
>> I'm a little confused as to exactly what you're missing, but maybe if
I
>> explain a bit it might clarify things.
>>
>> Whenever you build with LTIB, you get an output area named 'rootfs'.
>> This is a real root filesystem for the target that is suitable for
>> mounting as the NFS root filesystem. This area has nothing that was
>> built into the binary rpms removed from it, so if it got packaged as
>> part of the build, it will be there.
>>
>> In addition to the NFS rootfs (which always gets built), you can
>> optionally select (in the Target Image Generation area) other image
>> output formats (such as jffs, cramfs etc). It is these output images
>> (they get created as single blobs) that can have options applied to
>> remove some unwanted files. Simplistically what happens is:
>>
>> 1. rootfs --copied to---> rootfs.tmp
>> 2. unwanted files removed from rootfs.tmp
>> 3. rootfs.tmp used to create output image (e.g. rootfs.jffs2)
>> 4. rootfs.tmp removed (there is an option to keep this).
>>
>> So in your case, because you're using an NFS image, you don't need to
>> worry about these 'remove' options. If you are missing files, this
can
>> be for a number of reasons:
>>
>> * They were never needed and so not copied or you don't need them
as
>> the toolchain can automatically find them
>>
>> Normally, kernel headers, glibc headers etc are built into the cross
>> compiler package. So you don't need them on the rootfs area unless
you
>> intend to install native gcc onto the target and to build on the
target.
>> I don't think you want to do that, but if you did, follow Steve's
>> advice and turn on the various options under 'Toolchain component
>> options'
>>
>> For kernel headers as normally userspace packages can just use the
>> kernel headers built into the cross toolchain. However, if something
>> (your stuff outside LTIB) wants the real headers for the kernel
you're
>> using, then you can simply select the option 'Include kernel
headers'
>> (CONFIG_PKG_KERNEL_WANT_HEADERS). They will then be found in
>> rootfs/usr/src/linux/...
>>
>>
>> If this doesn't address the problem you have, please send a simple
>> example of what you're trying to do (a hello-world test case for
>> example) and we can take it from there.
>>
>> Regards, Stuart
>>
>>
>> Morrison, Tom wrote:
>> > Hi Stuart,
>> >
>> > Again, thanks for all the help!
>> >
>> > I tried configuring (./ltib -c) - and tried to configure the things
>> > the way I wanted them...but...
>> >
>> > We are using the NFS-ONLY option (we do NOT need an initramfs or
>> > ramdisk option). While using this - it doesn't seem to give me the
>> > many options to 'deselect' configuration options like:
>> >
>> > 'remove the /usr/include directory'
>> >
>> > Which is needed to use with compiler to build my applications.
>> >
>> > Is there anyway around this, so I am using the NFS-ONLY - but am
>> > including all the headers/libraries in the rootfs subdirectory?
>> >
>> > The alternative is to build with a target image being some other
>> > type of targetimage (initramfs, ramdisk, cramfs?)...
>> >
>> > Tom
>> >
>> >
>> >>> -----Original Message-----
>> >>> From: Stuart Hughes [mailto:address@hidden
>> >>> Sent: Tuesday, March 31, 2009 8:56 AM
>> >>> To: Morrison, Tom
>> >>> Cc: address@hidden; address@hidden;
address@hidden
>> >>> Subject: Re: [Ltib] NEW LTIB...and Full Toolchain build....
>> >>>
>> >>> Hi Tom,
>> >>>
>> >>> The toolchains used in LTIB are standard full cross-compilers.
>> >>>
>> >>> If you're cross compiling outside of LTIB you can simply find the
>> > path of
>> >>> gcc (look in your LTIB config/platform/_target_) and the flags
that
>> > are
>> >>> used and then set the path and call:
>> >>> $CROSS-gcc $TOOLCHAIN_CFLAGS
>> >>>
>> >>> The compiler toolchain headers will be picked up automatically.
You
>> >>> don't need real kernel headers unless you're building modules.
>> >>>
>> >>> For some components (libc, kernel headers) ltib has options in
>> > "./ltib -
>> >>> c" to include these in the rootfs. Note that for the staging NFS
>> > area
>> >>> all the headers/libs will be found in rootfs/ /{lib,include}.
When
>> > you
>> >>> use the cross compiler you'll need to setup -I/-L in some way to
>> >>> reference this area for you (which is what the spoofing does).
The
>> > other
>> >>> thing you may need to consider is pkg-config, which LTIB also
spoofs.
>> >>>
>> >>> Another option if you wish is to run: "./ltib -m shell". From
here
>> > you
>> >>> are setup in the same environment as the ltib builder and so can
>> > simply
>> >>> say: "./configure ; make". You can exit the shell using "exit".
>> >>>
>> >>> Regards, Stuart
>> >>>
>> >>> --- address@hidden wrote:
>> >>>
>> >>> From: "Morrison, Tom" <address@hidden>
>> >>> To: <address@hidden>
>> >>> Cc: Geary Sean-R60898 <address@hidden>,
>> > Papacharlambous
>> >>> Steve-R61559 <address@hidden>
>> >>> Subject: [Ltib] NEW LTIB...and Full Toolchain build....
>> >>> Date: Mon, 30 Mar 2009 16:55:02 -0400
>> >>>
>> >>> Hi everyone...
>> >>>
>> >>> I have been using a LTIB image from Freescale and have
successfully
>> >>> built a rootfs that I am happy with. It is working well enough
that
>> >>> we want to use this as our standard rootfs (aka: DISTRO) - which
>> > means
>> >>> that the application(s) - NOT built in LTIB - need to have a full
>> >>> compiler that supports all of the standard Linux utils (e.g.:
>> > binutils)
>> >>> as well as all the include files (i.e.: include/linux/i2c.h)
>> >>>
>> >>> So, the compiler version supported in this release is 4.2-171 and
the
>> >>> target platform is a MPC85xx (E500v2 (SPE=yes))
>> >>>
>> >>> How do I go about building a full Toolchain for my application to
>> > use?
>> >>>
>> >>> Tom
>> >>>
>> >>>
>> >>>>> -----Original Message-----
>> >>>>> From: Geary Sean-R60898 [mailto:address@hidden
>> >>>>> Sent: Thursday, March 05, 2009 12:08 PM
>> >>>>> To: Morrison, Tom; Papacharlambous Steve-R61559
>> >>>>> Cc: McCormick Ralph-R58423
>> >>>>> Subject: RE: [Ltib] GLIBC 2.5
>> >>>>>
>> >>>>> I did use the 171 files but am about to try again with the 187
>> >>> version
>> >>>>> Just to verify you are still attempting to build this within
LTIB
>> >>>>> correct?
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>>
>> >>>>> -----Original Message-----
>> >>>>> From: Morrison, Tom [mailto:address@hidden
>> >>>>> Sent: Thursday, March 05, 2009 12:03 PM
>> >>>>> To: Geary Sean-R60898; Papacharlambous Steve-R61559
>> >>>>> Cc: McCormick Ralph-R58423
>> >>>>> Subject: RE: [Ltib] GLIBC 2.5
>> >>>>>
>> >>>>> Thank you - thank you - thank you Sean!
>> >>>>>
>> >>>>> I am very grateful that you've been very active with this and
>> > gotten
>> >>> the
>> >>>>> ball rolling (I figured I should at least 'officially' put the
SR
>> > in
>> >>> -
>> >>>>> so we can track this...sorry to cross paths with your work...
>> >>>>>
>> >>>>>
>> >>>>> Attached is a text file with the failure...
>> >>>>>
>> >>>>> If you look in this file:
>> >>>>>
>> >>>>>
>> >
/opt/freescale/usr/local/gcc-4.2.171-eglibc-2.5.171-dp-2/powerpc-none-
>> li
>> >>>>>
nux-gnuspe/lib/gcc/powerpc-none-linux-gnuspe/4.2.3/include/spe.h
>> >>>>>
>> >>>>> It seems to be want a definition for
>> >>>>>
>> >>>>> __ev64_opaque__
>> >>>>>
>> >>>>> And in my 'toolchain' there seems to NOT be a definition for
this?
>> >>>>>
>> >>>>> I did follow Steve's instructions (and I used -187 version (not
>> > -171
>> >>>>> that came with the LTIB image - this may be part of the
problem)?
>> >>>>>
>> >>>>> T
>> >>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Geary Sean-R60898 [mailto:address@hidden
>> >>>>>>> Sent: Thursday, March 05, 2009 11:46 AM
>> >>>>>>> To: Papacharlambous Steve-R61559; Morrison, Tom
>> >>>>>>> Cc: McCormick Ralph-R58423
>> >>>>>>> Subject: RE: [Ltib] GLIBC 2.5
>> >>>>>>>
>> >>>>>>> Hi Tom,
>> >>>>>>>
>> >>>>>>> I saw the SR that you created and had one of our apps guys
grab
>> >>> it..
>> >>>>>>> Also the BSP team has been looking into this issue as well
>> > since
>> >>> last
>> >>>>>>> night when I passed your emails on to them for investigation.
>> >>> This
>> >>>>>>> team is in Beijing so hopefully we'll hear something back
>> > tomorrow
>> >>>>>>> morning in regards to this.
>> >>>>>>>
>> >>>>>>> I have been rebuilding glibc and it actually just finished
>> > without
>> >>>>> error
>> >>>>>>> once I installed gawk. Where in your build does it actually
>> >>> fail?
>> >>>>>>>
>> >>>>>>> Sean
>> >>>>>>>
>> >>>>>>>
>> >>>>>>> -----Original Message-----
>> >>>>>>> From: Papacharlambous Steve-R61559
>> >>>>>>> Sent: Thursday, March 05, 2009 11:23 AM
>> >>>>>>> To: Morrison, Tom
>> >>>>>>> Cc: Geary Sean-R60898; McCormick Ralph-R58423
>> >>>>>>> Subject: RE: [Ltib] GLIBC 2.5
>> >>>>>>>
>> >>>>>>> Hi Tom,
>> >>>>>>>
>> >>>>>>> Just out of interest I checked how glibc was built in the
>> >>> toolchain,
>> >>>>> and
>> >>>>>>> the following cflags were used to build glibc: "-O -mcpu=8548
>> >>>>> -mspe=yes
>> >>>>>>> -mabi=spe -mhard-float -mfloat-gprs=double" which looks
correct
>> > to
>> >>>>> me.
>> >>>>>>> Just a thought but are you building all your user space
>> > packages
>> >>> with
>> >>>>>>> these flags?
>> >>>>>>>
>> >>>>>>> Best regards,
>> >>>>>>>
>> >>>>>>> Steve
>> >>>>>>>
>> >>>>>>> On Thu, 2009-03-05 at 10:36 -0500, Morrison, Tom wrote:
>> >>>>>>>> Fyi - Prep OK - build failed because spe.h defines something
>> >>> called
>> >>>>>>>> __ev64_opaque__ and this is NOT defined anywhere (so there
is
>> >>> still
>> >>>>>>>> some missing patch).....:-(...
>> >>>>>>>>
>> >>>>>>>> Now I am at the mercy of Sean and Ralph t
>> >>>>>>>>
>> >>>>>>>>>> -----Original Message-----
>> >>>>>>>>>> From: Steve Papacharalambous [mailto:address@hidden
>> >>>>>>>>>> Sent: Thursday, March 05, 2009 7:13 AM
>> >>>>>>>>>> To: Morrison, Tom
>> >>>>>>>>>> Cc: address@hidden
>> >>>>>>>>>> Subject: Re: [Ltib] GLIBC 2.5
>> >>>>>>>>>>
>> >>>>>>>>>> Hi Tom,
>> >>>>>>>>>>
>> >>>>>>>>>> It looks like you are using an iso from Freescale in which
>> >>> case
>> >>>>> you
>> >>>>>>>> need
>> >>>>>>>>>> to get support from Freescale for this iso. I've put
>> >>>>> instructions
>> >>>>>>>>>> of how to obtain support at the end of this email.
>> >>>>>>>>>>
>> >>>>>>>>>> The decision to use the libraries and headers from the
>> >>> toolchain
>> >>>>> in
>> >>>>>>>> the
>> >>>>>>>>>> target root file system is a deliberate choice to ensure
>> >>>>>>>> compatibility
>> >>>>>>>>>> between the run time environment on the target root file
>> >>> system
>> >>>>> and
>> >>>>>>>> the
>> >>>>>>>>>> executables that are built using the cross toolchain.
>> >>>>>>>>>>
>> >>>>>>>>>> Having said that you should be able to build the glibc
>> >>> package,
>> >>>>> and
>> >>>>>>>>>> you're right the two patches have not been uploaded to the
>> >>> GPP
>> >>>>> yet.
>> >>>>>>>>>> I'll look into this and get them uploaded for you. In the
>> >>>>> meantime
>> >>>>>>>> you
>> >>>>>>>>>> can extract these two patches from the toolchain source
>> > rpm
>> >>>>> which
>> >>>>>>>>>> is available from the GPP. One way to extract these files
>> > is
>> >>> to
>> >>>>>>>>>> use the
>> >>>>>>>>>> following:
>> >>>>>>>>>>
>> >>>>>>>>>> "rpm2cpio freescale-powerpc-linux-gnu-4.2-187.src.rpm |
>> > cpio
>> >>>>> -ivd"
>> >>>>>>>>>> Obtaining support from Freescale:
>> >>>>>>>>>> ------------
>> >>>>>>>>>> As you are using an iso image downloaded from
>> >>>>>>>> http://www.freescale.com/
>> >>>>>>>>>> you should post support questions by following these
>> > steps:
>> >>>>>>>>>> * go to http://www.freescale.com
>> >>>>>>>>>> * click on "Support / Technical support"
>> >>>>>>>>>> * click on "Submit a Service Request"
>> >>>>>>>>>> * register to get a user name and password.
>> >>>>>>>>>> * login in with your user name and password
>> >>>>>>>>>> * on the "New Service Request" page:
>> >>>>>>>>>> * category = Technical Request
>> >>>>>>>>>> * topic = Linux BSP
>> >>>>>>>>>> * Click on "Continue"
>> >>>>>>>>>> * fill out the information for the service request
>> >>>>>>>>>> * click on the "Submit" button at the bottom of the
>> > page.
>> >>>>>>>>>> ------------
>> >>>>>>>>>>
>> >>>>>>>>>> Best regards,
>> >>>>>>>>>>
>> >>>>>>>>>> Steve
>> >>>>>>>>>>
>> >>>>>>>>>> On Wed, 2009-03-04 at 17:28 -0500, Morrison, Tom wrote:
>> >>>>>>>>>>> I am using an LTIB package from Freescale for the
>> > MPC8572
>> >>>>> (dated
>> >>>>>>>>>>> 121208)...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> It seems that the subject line package of this BSP is a
>> >>>>> pre-built
>> >>>>>>>> RPM
>> >>>>>>>>>>> (it doesn't go through
>> >>>>>>>>>>>
>> >>>>>>>>>>> the a full build when using generic <./ltib> build
>> > process.
>> >>> It
>> >>>>>>>> looks
>> >>>>>>>>>>> like this full library gets
>> >>>>>>>>>>>
>> >>>>>>>>>>> untars a pre-built one into the as a uses a pre-built
>> > rpm
>> >>>>> GLIBC
>> >>>>>>>> (and
>> >>>>>>>>>>> an associated native
>> >>>>>>>>>>>
>> >>>>>>>>>>> GCC compiler (whose source is available luckily)...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> The problem with this pre-built one is that it was NOT
>> >>> built
>> >>>>>>>> correctly
>> >>>>>>>>>>> for the E500 and/or
>> >>>>>>>>>>>
>> >>>>>>>>>>> with a compiler that supports SPE (correctly)...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> I determined this by noticing that when executing
>> > startup
>> >>>>> scripts
>> >>>>>>>>>>> (executing out of new rootfs),
>> >>>>>>>>>>>
>> >>>>>>>>>>> I am getting multiple math emulation exceptions (when
>> >>> traced
>> >>>>>>>>>>> close
>> >>>>>>>> to
>> >>>>>>>>>>> - it looks like it is
>> >>>>>>>>>>>
>> >>>>>>>>>>> coming from GLIBC type functions). I determine that
>> > this
>> >>> is
>> >>>>> case
>> >>>>>>>> with
>> >>>>>>>>>>> both the New Linux
>> >>>>>>>>>>>
>> >>>>>>>>>>> Kernel associated with this NEW LTIB Package, and my
>> > older
>> >>>>> (more
>> >>>>>>>>>>> stable) Linux Kernel
>> >>>>>>>>>>>
>> >>>>>>>>>>> which has been thoroughly QA'd..
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> OK, I can deal with most of those exceptions - but
>> >>>>> unfortunately,
>> >>>>>>>>>>> there is something I
>> >>>>>>>>>>>
>> >>>>>>>>>>> am trying to execute that is NOT handled correctly with
>> > my
>> >>>>> OLDER
>> >>>>>>>>>>> / more stable
>> >>>>>>>>>>>
>> >>>>>>>>>>> Linux kernel...and thus causes an ILLEGAL instruction
>> > (and
>> >>>>> thus,
>> >>>>>>>>>>> my
>> >>>>>>>> NEW
>> >>>>>>>>>>> user program
>> >>>>>>>>>>>
>> >>>>>>>>>>> is NOT working)...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> OK - well, maybe somebody who built this LTIB image took
>> > a
>> >>>>> lazy
>> >>>>>>>>>>> approach - so I decide I
>> >>>>>>>>>>>
>> >>>>>>>>>>> want to try to build the GLIBC again (and make sure it
>> > has
>> >>> all
>> >>>>>>>>>>> the proper configuration switches
>> >>>>>>>>>>>
>> >>>>>>>>>>> to NOT cause this problem)...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> So, I try ./ltib -m prep -p glibc
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>>> Try glibc-2.5.tar.bz2.md5 from the GPP
>> >>>>>>>>>>>>> 18:49:52
>> >>>>>>>>>>>>>
>> > URL:http://www.bitshrine.org/gpp/glibc-2.5.tar.bz2.md5
>> >>>>>>>>>>> [51/51] -> "glibc-2.5.tar.bz2.md5" [1]
>> >>>>>>>>>>>
>> >>>>>>>>>>>>> Try glibc-2.5.tar.bz2 from the GPP
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> And it fails utterly...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> I REALLY want to use this OLD/Stable kernel (with the
>> > new
>> >>> LTIB
>> >>>>>>>> rootfs
>> >>>>>>>>>>> (because I can run Java with this version))...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> a) Have I made the proper analysis of this pre-built
>> >>> LTIB
>> >>>>>>> image
>> >>>>>>>>>>> not being built correctly (I KNOW that this is
>> >>>>>>>>>>>
>> >>>>>>>>>>> the source of my math exceptions - 99.5% sure
>> >>>>>>>>>>>
>> >>>>>>>>>>> b) How do I get a new version
>> >>>>>>>>>>>
>> >>>>>>>>>>> c) Will this fix my problem?
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Here is the spec file that came with the NEW LTIB
>> > image...
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %define pfx /opt/freescale/rootfs/%{_target_cpu}
>> >>>>>>>>>>>
>> >>>>>>>>>>> %define cs_version 4.2-187
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Summary : GNU standard C library with NPTL
>> > thread
>> >>>>>>> library.
>> >>>>>>>>>>> Name : glibc
>> >>>>>>>>>>>
>> >>>>>>>>>>> Version : 2.5
>> >>>>>>>>>>>
>> >>>>>>>>>>> Release : 1
>> >>>>>>>>>>>
>> >>>>>>>>>>> License : LGPL
>> >>>>>>>>>>>
>> >>>>>>>>>>> Vendor : Freescale
>> >>>>>>>>>>>
>> >>>>>>>>>>> Packager : Stuart Hughes & Steve Papacharalambous
>> >>>>>>>>>>>
>> >>>>>>>>>>> Group : System Environment/Libraries
>> >>>>>>>>>>>
>> >>>>>>>>>>> Source0 : %{name}-%{version}.tar.bz2
>> >>>>>>>>>>>
>> >>>>>>>>>>> Source1 : %{name}-ports-%{version}.tar.bz2
>> >>>>>>>>>>>
>> >>>>>>>>>>> Source2 : %{name}-libidn-%{version}.tar.bz2
>> >>>>>>>>>>>
>> >>>>>>>>>>> Patch0 :
>> >>> %{name}-%{cs_version}-from-fsf-2_5.diff.gz
>> >>>>>>>>>>> Patch1 :
>> >>>>>>> %{name}_ports-%{cs_version}-from-fsf-2_5.diff.gz
>> >>>>>>>>>>> BuildRoot : %{_tmppath}/%{name}
>> >>>>>>>>>>>
>> >>>>>>>>>>> Prefix : %{pfx}
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %Description
>> >>>>>>>>>>>
>> >>>>>>>>>>> %{summary}
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> This glibc package is built using glibc-2.5 and
>> >>>>> glibc-ports-2.5
>> >>>>>>>> plus
>> >>>>>>>>>>> the
>> >>>>>>>>>>>
>> >>>>>>>>>>> following patches from the CodeSourcery %{cs_version}
>> >>> release:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> - glibc-4.2-187-from-fsf-2_5.diff
>> >>>>>>>>>>>
>> >>>>>>>>>>> - glibc_ports-4.2-187-from-fsf-2_5.diff
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> The glibc and glibc-ports tarballs can be obtained from
>> > any
>> >>> of
>> >>>>>>>>>>> the
>> >>>>>>>> GNU
>> >>>>>>>>>>> ftp
>> >>>>>>>>>>>
>> >>>>>>>>>>> sites or their mirrors.
>> >>>>>>>>>>>
>> >>>>>>>>>>> The CodeSourcery patch can be obtained by downloading
>> > the
>> >>>>> source
>> >>>>>>>> rpm:
>> >>>>>>>>>>> freescale-powerpc-linux-gnu-%{cs_version}.src.rpm from:
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>> http://www.codesourcery.com/gnu_toolchains/power/download.html
>> >>>>>>>>>>> and then
>> >>>>>>>>>>>
>> >>>>>>>>>>> extracting the glibc and glibc-ports patchs from this
>> >>> source
>> >>>>> rpm.
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %Prep
>> >>>>>>>>>>>
>> >>>>>>>>>>> %setup
>> >>>>>>>>>>>
>> >>>>>>>>>>> %patch0 -p1
>> >>>>>>>>>>>
>> >>>>>>>>>>> tar jxvf %{SOURCE1}
>> >>>>>>>>>>>
>> >>>>>>>>>>> cd glibc-ports-%{version}
>> >>>>>>>>>>>
>> >>>>>>>>>>> %patch1 -p1
>> >>>>>>>>>>>
>> >>>>>>>>>>> cd ..
>> >>>>>>>>>>>
>> >>>>>>>>>>> ln -s glibc-ports-%{version} ports
>> >>>>>>>>>>>
>> >>>>>>>>>>> tar jxvf %{SOURCE2}
>> >>>>>>>>>>>
>> >>>>>>>>>>> ln -s glibc-libidn-%{version} libidn
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %Build
>> >>>>>>>>>>>
>> >>>>>>>>>>> # Temporary hack - stevep
>> >>>>>>>>>>>
>> >>>>>>>>>>> # For building toolchain components an optimized version
>> > of
>> >>>>> the
>> >>>>>>>>>>> # target is needed. This should really be defined in
>> > the
>> >>>>> config
>> >>>>>>>>>>> # area of ltib, and not done in the toolchain spec
>> > files.
>> >>>>>>>>>>> # For now we assume that the optimised target can be
>> >>> derived
>> >>>>> by
>> >>>>>>>>>>> # stripping the trailing "-" off the toolchain prefix,
>> > but
>> >>>>> this
>> >>>>>>>>>>> # will not be true for all cases, eg when using uClibc
>> >>>>>>> toolchains.
>> >>>>>>>>>>> OPT_CFGHOST=`echo ${TOOLCHAIN_PREFIX} | perl -n -e
>> >>>>>>>>>>> 's,-$,,;print'`
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> # Use the toolchain headers as the default for the glibc
>> >>>>> build.
>> >>>>>>>>>>> # TODO: Add a configuration option to allow selection of
>> >>> the
>> >>>>> BSP
>> >>>>>>>>>>> kernel
>> >>>>>>>>>>>
>> >>>>>>>>>>> # headers for the build - stevep
>> >>>>>>>>>>>
>> >>>>>>>>>>> TC_HEADERS_DIR="`dirname \`${TOOLCHAIN_PREFIX}gcc
>> >>>>>>>> ${TOOLCHAIN_CFLAGS}
>> >>>>>>>>>>> -print-file-name=libc.so\` | perl -p -e
>> >>> 's,/lib$,,'`/include"
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> rm -rf build-glibc
>> >>>>>>>>>>>
>> >>>>>>>>>>> mkdir build-glibc
>> >>>>>>>>>>>
>> >>>>>>>>>>> cd build-glibc
>> >>>>>>>>>>>
>> >>>>>>>>>>> echo "libc_cv_forced_unwind=yes" > config.cache
>> >>>>>>>>>>>
>> >>>>>>>>>>> echo "libc_cv_c_cleanup=yes" >> config.cache
>> >>>>>>>>>>>
>> >>>>>>>>>>> BUILD_CC="${BUILDCC}" \
>> >>>>>>>>>>>
>> >>>>>>>>>>> CFLAGS="-O" \
>> >>>>>>>>>>>
>> >>>>>>>>>>> ../configure \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --prefix=/usr \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --build=%{_build} \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --host=${OPT_CFGHOST} \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --disable-profile \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --without-gd \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --without-cvs \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --cache-file=config.cache \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --enable-kernel=2.6.10 \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --with-headers=${TC_HEADERS_DIR} \
>> >>>>>>>>>>>
>> >>>>>>>>>>> --enable-add-ons=ports,nptl,libidn
>> >>>>>>>>>>>
>> >>>>>>>>>>> make
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %Install
>> >>>>>>>>>>>
>> >>>>>>>>>>> cd build-glibc
>> >>>>>>>>>>>
>> >>>>>>>>>>> make install install_root=${RPM_BUILD_ROOT}/%{pfx}
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> # remove absolute paths from text search files (if they
>> >>> exist)
>> >>>>>>>>>>> perl -w -e '
>> >>>>>>>>>>>
>> >>>>>>>>>>> @ARGV = grep { `file $_` =~ m,ASCII C program text,
>> > }
>> >>>>> @ARGV;
>> >>>>>>>>>>> exit(0) unless @ARGV;
>> >>>>>>>>>>>
>> >>>>>>>>>>> $^I = ".bak";
>> >>>>>>>>>>>
>> >>>>>>>>>>> while(<>) {
>> >>>>>>>>>>>
>> >>>>>>>>>>> s,[\S/]+/,,g if m,^GROUP,;
>> >>>>>>>>>>>
>> >>>>>>>>>>> print;
>> >>>>>>>>>>>
>> >>>>>>>>>>> }
>> >>>>>>>>>>>
>> >>>>>>>>>>> ' ${RPM_BUILD_ROOT}/%{pfx}/lib/libc.so \
>> >>>>>>>>>>>
>> >>>>>>>>>>> ${RPM_BUILD_ROOT}/%{pfx}/lib/libpthread.so \
>> >>>>>>>>>>>
>> >>>>>>>>>>> ${RPM_BUILD_ROOT}/%{pfx}/%{_prefix}/lib/libc.so \
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> > ${RPM_BUILD_ROOT}/%{pfx}/%{_prefix}/lib/libpthread.so
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> # Remove libtool .la files.
>> >>>>>>>>>>>
>> >>>>>>>>>>> find $RPM_BUILD_ROOT/%{pfx} -name \*.la -exec rm {} \;
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %Clean
>> >>>>>>>>>>>
>> >>>>>>>>>>> rm -rf ${RPM_BUILD_ROOT}
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> %Files
>> >>>>>>>>>>>
>> >>>>>>>>>>> %defattr(-,root,root)
>> >>>>>>>>>>>
>> >>>>>>>>>>> %{pfx}/*
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> Tom Morrison
>> >>>>>>>>>>> Principal Software Engineer
>> >>>>>>>>>>>
>> >>>>>>>>>>> EMPIRIX
>> >>>>>>>>>>> 20 Crosby Drive - Bedford, MA 01730
>> >>>>>>>>>>> p: 781.266.3567 f: 781.266.3670
>> >>>>>>>>>>> email: address@hidden
>> >>>>>>>>>>> www.empirix.com
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>>
>> >>>>>>>>>>> _______________________________________________
>> >>>>>>>>>>> LTIB home page: http://bitshrine.org
>> >>>>>>>>>>>
>> >>>>>>>>>>> Ltib mailing list
>> >>>>>>>>>>> address@hidden
>> >>>>>>>>>>> http://lists.nongnu.org/mailman/listinfo/ltib
>> >>>>>>>>>> --
>> >>>>>>>>>> Steve Papacharalambous
>> >>>>>>>>>> Developer Technology.
>> >>>>>>>>>>
>> >>>>>>>>>> Registered address:
>> >>>>>>>>>> Freescale Semiconductor UK Ltd
>> >>>>>>>>>> Colvilles Road
>> >>>>>>>>>> East Kilbride
>> >>>>>>>>>> Glasgow
>> >>>>>>>>>> Scotland
>> >>>>>>>>>> G75 OTG
>> >>>>>>>>>>
>> >>>>>>>>>> Registration number: SC262720
>> >>>>>>>>>> VAT number: GB831329053
>> >>>>>>>>>>
>> >>>>>>>>>> (X) Public
>> >>>>>>>>>> ( ) Freescale Internal Use Only
>> >>>>>>>>>> ( ) Freescale Confidential Proprietary
>> >>>>>>>>>>
>> >>>>>>>>>>
>> >>>>>>>>
>> >>>>>>> --
>> >>>>>>> Steve Papacharalambous
>> >>>>>>> Developer Technology.
>> >>>>>>>
>> >>>>>>> Registered address:
>> >>>>>>> Freescale Semiconductor UK Ltd
>> >>>>>>> Colvilles Road
>> >>>>>>> East Kilbride
>> >>>>>>> Glasgow
>> >>>>>>> Scotland
>> >>>>>>> G75 OTG
>> >>>>>>>
>> >>>>>>> Registration number: SC262720
>> >>>>>>> VAT number: GB831329053
>> >>>>>>>
>> >>>>>>> (X) Public
>> >>>>>>> ( ) Freescale Internal Use Only
>> >>>>>>> ( ) Freescale Confidential Proprietary
>> >>>>>>>
>> >>>>>>>
>> >>>>>>>
>> >>>
>> >>>
>> >>> _______________________________________________
>> >>> LTIB home page: http://bitshrine.org
>> >>>
>> >>> Ltib mailing list
>> >>> address@hidden
>> >>> http://lists.nongnu.org/mailman/listinfo/ltib
>> >>>
>> >>>
>> >
>>