Doubts on codesourcery toolchain and SDL

GoogleGroups
1

Hello,
first of all thank for your attention. I've got a small doubt on how
to use the gnueabi toolchain
for XCompiling the SDL library.
I dunno if this is a bit out of topic related to this group, but being
the toolchain used on Beagle
I hope yes.

first of all I've downloaded and installed the arm-none-linux-gnueabi,
for instance under /home/embest/arm.
After this, I've set the right PATH using the export, in order to have
the arm-none-linux-gnueabi-XXX tools works throughout the system.

Now I've tried to cross compile the libpng library using this
toolchain, which depends on zlib, so first I've tried to XCompile this
last one.
Within the zlib folder, I've configured this one using --prefix=/home/
embest/arm ( having set the CC and AR vars too, of course ). After
make & make install the library has successfully installed within the /
home/embest/arm/lib folder, having the zlib.a archive.

Now I've tried to configure the libpng, with the following line:

./configure --host=arm-none-linux-gnueabi --build=i686-pc-linux-gnu --
prefix=/home/embest/arm LDFLAGS=-L/home/embest/arm/lib CFLAGS=-I/home/
embest/arm/include

after make and make install the library has been successfully built
and installed near the previous zlib.

My point is this, so far:

I know my toolchain is not in the default place, i.e. /usr/local, but
I'm worried about to call the configure withtoo many parameters.
Without the LDFLAGS and CFLAGS the configure complains of course,
'cause it doesn't find the zlib in the right place. At the same time,
without the include dir indication the arm-none-linux-gnueabi-gcc
complains.

Is there another way to do this operation? I mean, is there a way to
give the configure a UNIQUE dir, i.e. the prefix one in my case,
without the boring stuff to specify every time the lib and include
dirs?

I need a sort of mechanism to gather the lib and include from within
the toolchain, and installs the new one in the same place ( probably
is what I've seen to be called "toolchain tree" )

Would it be better to install the toolchain under /usr/local/arm, for
instance? I've tried but in this way I had to do the same boring
trick, giving the configure the LDFLAGS=-L/usr/local/arm/lib folder.

Where am I wrong, please?

Many thanks for your help in advance

Ricky

2

Hello,
first of all thank for your attention. I've got a small doubt on how
to use the gnueabi toolchain
for XCompiling the SDL library.

I have big doubts on the whole CSL thing, but anyway...

I dunno if this is a bit out of topic related to this group, but being
the toolchain used on Beagle
I hope yes.

There is no native version of CSL, so what host and target distributions are you targeting?

3

Hello,
sorry it's not clear to me what do you mean with CLS.

My build system is --build=i686-pc-linux-gnu

while my host system is:

--host=arm-none-linux-gnueabi

as I wrote in my preivous post as configure parameters.

I'm going to use SDL_image, so first I've still crosscompiled
successfully
both libpng and zlib.
Now I'm going to XCompile SDL lib, too. But I has to understand if I'm
doing something
wrong in my toolchain installation.
It seems not so far.
Thank you

Ricky

4

Koen doesn't like the CSL toolchain.

I have been using it to build userland apps, with CentOS and Ubuntu
Linux and under Windoze, since September of last year when John
explained the mysteries of -Xlinker -rpath -Xlinker (or something like
that).

Works great for me.

See:
  http://groups.google.com/group/beagleboard/msg/f513d1f9855fd656

- dan

5

the boys at free-electrons have an entire course on embedded linux
on the BB:

  http://free-electrons.com/blog/beagle-labs/

and in one of the lab files (toolchains-lab.odt), they claim to have
built a toolchain with crosstool-ng and

  $ ./ct-ng arm-unknown-linux-uclibcgnueabi

but the latest hg pull of ct-ng has the sample file:

  samples/arm-cortex_a8-linux-gnueabi/crosstool.config

would that not make sense for a beagle? has anyone built a perfectly
respectable toolchain for the BB from ct-ng?

rday

6

If you build a toolchain you need to make sure you compile everybit of sw on the beagle with it, otherwise you'll get stuff in incompatibilty hell when trying to debug things.
People that really need their 'own' toolchain know how to build it.

regards,

Koen

7

If you build a toolchain you need to make sure you compile everybit of sw on the beagle with it, otherwise you'll get stuff in incompatibilty hell when trying to debug things.
People that really need their 'own' toolchain know how to build it.

regards,

Koen

UNIX and Linux .so dynamic shared libraries are at least a little bit
better behaved than Windows .DLLs.

.so's have version numbers. ldd(1) reports the shared libs which
satisfy an executable's dependencies.

Our Friend John suggests copying the current libs (/lib, /usr/lib)
from the target to the development host.

Invoking the "-Xlinker -rpath -Xlinker $(my_lib_dir)" incantation
instructs the linker to search our local copy of shared libs.

This results in a binary which loads the correct dynamic shared
libraries at run time.

This way you could compile FORTRAN, Ada, COBOL or just use a newer or
an older version of GCC as needed.

best regards,
- dan

8

That won't help you with things like ABIs, CFLAGS, LDFLAGS, changes in C++, etc. Copying over libs won't help one bit if you start mixing gcc 3.x and 4.x.

regards,

Koen

9

This is just a problem in the case of dynamically linked apps, correct?

A statically linked EABI app can come from anywhere or any kind of
compiler - even the ARM RealView compiler for Linux.

Mixing OABI and EABI objects would be a Really Bad Idea - but mixing
EABI objects from different compilers just depends on the linker.

The OABI is behind us as of 2.6.16:
  http://infocenter.arm.com/help/index.jsp?topic=/com.arm.doc.dai0150b/ar01s01s05.html

Mixing C++ objects from different compilers is another problem all
together. C++ name mangling is not defined as any kind of standard. It
even changes between versions of GCC. Any kind of C++ would all have
to be done with the same version of GCC.

All that said, if the original poster has a known working CSL
compiler, such as 2007q3, compiles all of his own C++ apps and libs
using his own tool chain, and links with current Beagleboard libs from
/lib and /usr/lib, the end result should be a valid executable.

This has been the recipe for embedded systems development for decades. :wink:

best regards,
- dan

10

That won't help you with things like ABIs, CFLAGS, LDFLAGS, changes in C++, etc. Copying over libs won't help one bit if you start mixing gcc 3.x and 4.x.

regards,

Koen

This is just a problem in the case of dynamically linked apps, correct?

No. Try linking in a incompatible .a file.

A statically linked EABI app can come from anywhere or any kind of
compiler - even the ARM RealView compiler for Linux.

If your kernel has EABI turned on, NEON turned on, etc. And there's no such things as a truly statically compiled app, it will still try to access things like /etc/nsswitch.conf which could have changed format or might not be present. I know people that said "a statically linked glibc app runs fine on a uclibc system" and got burned when they actually tried it.

Mixing OABI and EABI objects would be a Really Bad Idea - but mixing
EABI objects from different compilers just depends on the linker.

The OABI is behind us as of 2.6.16:
Documentation – Arm Developer

You're reading that wrong, it only means that starting with 2.6.16 eabi support it builtin to the kernel, but you can configure it for oabi as well. FWIW, I used EABI on 2.6.12 kernels :slight_smile:

All that said, if the original poster has a known working CSL
compiler, such as 2007q3

Try using -Os and still call it working....

, compiles all of his own C++ apps and libs
using his own tool chain, and links with current Beagleboard libs from
/lib and /usr/lib, the end result should be a valid executable.

Yeah, "should", which is where consultants are making a kiliing because someone said "should" and it turns out it doesn't :slight_smile: Mixing toolchains is bad, bad idea. If you are ready to accept QA and debug hell, fine, but don't go recommending it to other people.

I waste enough time at work listening to people going on and on about "foo crashes when built with CSL 2009q1, could that be because the rest is compiled with 2008q3?". You can only image how much time the people experiencing the actual problem are wasting!

regards,

Koen

11

This is just a problem in the case of dynamically linked apps, correct?

No. Try linking in a incompatible .a file.

Good point... The .a could come from anywhere and thus be a problem.

I compile my C and C++ apps and all of my own C libs with the same
compiler and link with the libs from the Beagleboard file system.
Works for me - so far.

A statically linked EABI app can come from anywhere or any kind of
compiler - even the ARM RealView compiler for Linux.

If your kernel has EABI turned on, NEON turned on, etc. And there's no such things as a truly statically compiled app, it will still try to access things like /etc/nsswitch.conf which could have changed format or might not be present. I know people that said "a statically linked glibc app runs fine on a uclibc system" and got burned when they actually tried it.

Yeah, mixing glibc and uclibc would be a big mess too... Doesn't
uclibc specify a totally different GCC compiler?

My statically linked app loads libpthread.so (!) This stopped me dead
in my tracks until I started linking against the Beagleboard libs. It
still loads libpthread.so but at least it can find it now...

I waste enough time at work listening to people going on and on about "foo crashes when built with CSL 2009q1, could that be because the rest is compiled with 2008q3?". You can only image how much time the people experiencing the actual problem are wasting!

I would dump CSL in a heartbeat if OpenEmbedded built a cross compiler
hosted on Windows. As it is I am stuck compiling machine generated
code from inside a Windows based app and need a Windows based
compiler.

This is some of the value added by Windriver and Montavista. They
offer cross-compilers built for both Linux and Windows development
hosts built from the same source tree.

best regards,
- dan

12

Op 30 nov 2009 om 22:01 heeft Dan Poirot <dtpoirot@gmail.com> het volgende geschreven:\

13

Op 30 nov 2009 om 22:01 heeft Dan Poirot <dtpoirot@gmail.com> het volgende geschreven:\

This is just a problem in the case of dynamically linked apps, correct?

No. Try linking in a incompatible .a file.

Good point... The .a could come from anywhere and thus be a problem.

I compile my C and C++ apps and all of my own C libs with the same
compiler and link with the libs from the Beagleboard file system.
Works for me - so far.

A statically linked EABI app can come from anywhere or any kind of
compiler - even the ARM RealView compiler for Linux.

If your kernel has EABI turned on, NEON turned on, etc. And there's no such things as a truly statically compiled app, it will still try to access things like /etc/nsswitch.conf which could have changed format or might not be present. I know people that said "a statically linked glibc app runs fine on a uclibc system" and got burned when they actually tried it.

Yeah, mixing glibc and uclibc would be a big mess too... Doesn't
uclibc specify a totally different GCC compiler?

My statically linked app loads libpthread.so (!) This stopped me dead
in my tracks until I started linking against the Beagleboard libs. It
still loads libpthread.so but at least it can find it now...

I waste enough time at work listening to people going on and on about "foo crashes when built with CSL 2009q1, could that be because the rest is compiled with 2008q3?". You can only image how much time the people experiencing the actual problem are wasting!

I would dump CSL in a heartbeat if OpenEmbedded built a cross compiler
hosted on Windows.

OE supports just that :slight_smile:

14

>> This is just a problem in the case of dynamically linked apps, correct?
>
> No. Try linking in a incompatible .a file.

Good point... The .a could come from anywhere and thus be a problem.

I compile my C and C++ apps and all of my own C libs with the same
compiler and link with the libs from the Beagleboard file system.
Works for me - so far.

Part of the problem is people using autoconf and things libtool. These
troublesome scripts likes to yank libraries out of unexpected places. Even if
you compile it and are aware of things, you still can wind up with bad .a
files being referenced. This is not purely a tool chain mixing thing; it
requires more draconian efforts like making sure it is impossible to see any
libraries/tools/etc that has ever been built with another tool chain. Even if
it works today, a minor upgrade has been known to cause introduce subtle bugs
via autoconf/libtool due to it deciding to suddenly link in a totally
different lib.

>> A statically linked EABI app can come from anywhere or any kind of
>> compiler - even the ARM RealView compiler for Linux.
>
> If your kernel has EABI turned on, NEON turned on, etc. And there's no
> such things as a truly statically compiled app, it will still try to
> access things like /etc/nsswitch.conf which could have changed format or
> might not be present. I know people that said "a statically linked glibc
> app runs fine on a uclibc system" and got burned when they actually tried
> it.

Yeah, mixing glibc and uclibc would be a big mess too... Doesn't
uclibc specify a totally different GCC compiler?

My statically linked app loads libpthread.so (!) This stopped me dead
in my tracks until I started linking against the Beagleboard libs. It
still loads libpthread.so but at least it can find it now...

Glibc has done its best in making it impossible to build a true static binary.

Having said that... If you can make a true static binary or make all parts of
a binary self consistant at both run time and build time, it is fine to mix
tool chains.

> I waste enough time at work listening to people going on and on about
> "foo crashes when built with CSL 2009q1, could that be because the rest
> is compiled with 2008q3?". You can only image how much time the people
> experiencing the actual problem are wasting!

I would dump CSL in a heartbeat if OpenEmbedded built a cross compiler
hosted on Windows. As it is I am stuck compiling machine generated
code from inside a Windows based app and need a Windows based
compiler.

This is some of the value added by Windriver and Montavista. They
offer cross-compilers built for both Linux and Windows development
hosts built from the same source tree.

With a little bit of effort, I have not had any issues with using a mix of
cross-tools, montavista, and Angstrom binaries on the same image. It all
comes down to keeping things consistant at all stages.

I am not suggesting people randomly intermix binaries; just wanted to point
out that it is not as bad as it is suggested to be and what you need to
ensure if you must violate the non toolchain mixing rule. If you can't ensure
every single thing is consistant at both run and build time, then fall back
to a clean machine with just 1 tool chain and always use that!