[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: |
Stuart Hughes |
Subject: |
Re: [Ltib] NEW LTIB...and Full Toolchain build.... (docu) |
Date: |
Thu, 02 Apr 2009 16:08:59 +0100 |
User-agent: |
Thunderbird 2.0.0.16 (X11/20080707) |
Hi Tom,
Now I think I can see what you're trying to do. If need be, send me the
screen-shot off-list. However, for the static C libraries in /usr/lib
and the kernel headers in /usr/src/linux/include here's the scoop;
Unless you need them (by some selection) they will never be in the NFS
image in the first place. If you need them but LTIB's configuration
would not normally select them, here's what you need to do (example for
kernel headers and static libc files):
$ ./ltib -c
Toolchain component options --->
[*] libc shared libraries
[ ] libc crt*.o startup files
[ ] libc headers
[ ] libc static libraries !!! select this if you want it
[ ] libc locale files
[*] c++ shared libraries
[ ] c++ header
[ ] c++ static libraries
[*] libgcc*.so*
As you see normally the 'lib c static libraries' don't go onto the run
time rootfs area as they're not needed on the target. Also they're not
needed when cross compiling as they are automatically found in the
toolchain if needed (that's why the headers are disabled too). So if
you need these, just enable the parts you want.
Similarly, for the kernel headers, from the top level select:
[ ] Configure the kernel
[ ] Leave the sources after building !!! select this if you want it
Regards, Stuart
Morrison, Tom wrote:
I need to do a screen shot to show you...which doesn't translate
well on the ltib group email...
I need to send you a screen shot because I contend that if I don't check
another image type - it does NOT allow me to keep all of the files of
interest (aka: the default actions is to remove all the /usr/src &
static
libraries, and just about everything that might be useful if I need to
build a 'toolchain rootfs'
do you want me to send you a screen shot - perhaps Freescale in their
BSP
implementation got this part 'not right'...?
t
-----Original Message-----
From: Stuart Hughes [mailto:address@hidden
Sent: Thursday, April 02, 2009 10:48 AM
To: Morrison, Tom
Cc: address@hidden; address@hidden; address@hidden
Subject: Re: [Ltib] NEW LTIB...and Full Toolchain build.... (docu)
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