ltib
[Top][All Lists]
Advanced
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Ltib] NEW LTIB...and Full Toolchain build.... (docu)

From: Stuart Hughes
Subject: Re: [Ltib] NEW LTIB...and Full Toolchain build.... (docu)
Date: Thu, 02 Apr 2009 15:47:44 +0100
User-agent: Thunderbird 2.0.0.16 (X11/20080707) 
Hi Tom,
What I may have not explained clearly is that NFS is always selected/provided as this is what all other images are based on. So if you select NFS, it's the same as saying "don't build any other image types, just build an NFS/interface rootfs area". When you select other output options it runs something after the NFS area is built to take that, copy it and turn it into a filtered version of the NFS area before bundling it up in some way (jffs2, ext2.gz etc).
So for that reason the NFS area (rootfs) has all the files in it, without any options to removed them. The only controls you have are in the "./ltib -c" session, such as "keep source" for the kernel, and "Toolchain component options" (libc components).
If this doesn't clarify it for you, please give an actual example of what is happening/not happening for you. 

Regards, Stuart

Morrison, Tom wrote:

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
reply via email to
[Prev in Thread] Current Thread [Next in Thread]