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: "building binutils for target" question



So the question is: do you need to run a compiler on your target?
If the answer is 'no', then all you need is the cross-toolchain.
In my case, fortunately (or unfortunately, depending if a newbie like me has to do it) the answer is 'yes' as the target machine would need to compile and run programs using gcc, so I have to prepare everything on the (powerful) x86_64 arch machine, build the image, deploy it to the target powerpc and then let that machine do its business.

OK, but, presumably, when I construct that final image glibc should also be there (in the final image), right? how do I "move it across"? Where is it located (for the target arch)?

Basically, you would follow these steps: - build the cross-toolchain ( with crostool-NG, of course! ;-) )

- build every packages, and install them in what we call a 'staging area':
./configure --build=x86_64-blabla --host=powerpc-blabla --prefix=/ --options
make
make DESTDIR=/some/place/staging
(note: you may need to pass additional CFLAGS and LDFLAGS, such as:
CFLAGS="-I/some/place/staging/usr/include -I/some/place/staging/include"
LDFLAGS="-L/some/place/staging/lib -L/some/place/staging/usr/lib"
)
In your last "make" statement presumably you meant "make DESTDIR=/some/place/staging install" right?

As for the CFLAGS/LDFLAGS includes that is a given, although I am thinking if I run with chroot to /some/place/staging and then execute make install then I won't be needing this, right? I might be wrong though!

Note: do NOT install in the sysroot! If you do so, then you won't be
able to reuse the toolchain, as it would be poluted with headers and
libraries from your programs. You really want to install in a staging
area!
I know, I've read all of the doc files and I am also aware of the populate tool, but to me it seemed a bit of a chicken-and-egg scenario - you need to build the tools in the staging area in order to use this script, but in effect I can't build the tools if I do not have the core libraries...

- the staging area will contain all that your packages have installed, but
is missing the 'system' libraries from the toolchain. So crosstool-NG
does provide a tool that can complete the staging for you. That tool is
called populate:
powerpc-blabla-populate -s /some/place/staging -d /some/place/rootfs
populate will scan all binaires (executable and shared libs) in staging,
find missing NEEDED libs and get them from the sysroot, and create a copy
of staging in rootfs, which will contain all libs required to run.
Note: if you are using glibc, be sure to add (some or all of )the NSS
libraries. You can do it with the '-l' options of populate. See:
docs/5 - Using the toolchain.txt
populate --help
But as you pointed out below, if I just copy all of the toolchain's sysroot to my staging area I won't need any of this, right? Would that mean that I do not have to install the kernel headers for the target machine as well?

- you then create an 'image' of rootfs that you transfer to the target
and boot on that. It all depends on your target what this image will be:
- file system image to burn on flash
- tarball to extract on SD or HDD, or to NFS mount
- kernel+initrd to boot from the network
- and so on...
Yeah, precisely! That is exactly what my plan is!

You do not need to copy or install them again. The cross-gcc and cross-ld
will be able to find them (and the libs) automatically. This is the purpose
of the sysroot.
What about my "cross-native" gcc and the binutils I am going to build? Would they be able to find them (or should I use the --with-headers option when running configure, would that be enough do you think)?

You would need to build the native gcc using the already built sysroot. Just
copy the sysroot of the cross-toolchain, and use that copy to configure gcc.
You could start by creating your staging by entirely copying the sysroot
as-is, and then configure gcc with --disable-sysroot and --with-build-sysroot
that points to the staging.
And also presumably using --with-headers as well, right?

Of course, in this case, you would not need to run populate, as your staging
will already have everything...
True, but are there any drawback with using this approach (it is a given that I may copy something, which I won't be needing on the target machine)?


MZ


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