DIY - KeK

[knc1]

I assume from the filename this is a C not a C++ source, so ...
--static --static-libgcc
Ref: http://gcc.gnu.org/onlinedocs/gcc-4....l#Link-Options
That will take care of the warning messages about the runtime (if CS built a static libgcc - I haven't checked for that).

GM's choice of 2010q1-202 (a CS product, prior to purchase by MG) is one very close to what lab126 was using on the K5. "We stock" the 2010-09 for that purpose, one (six months later) release. Shouldn't be much difference between the two.

For "new work" such as this, using the most recent release (2012.03-57) is the way to go. You shouldn't run into the corner cases where you need to match the original compiler version.
Some of the work GM does, does run into them and does require a "best match" of the tool chain.

While cross compiling, try setting your PATH to:
export PATH=/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin:$PATH
Then: gcc --version
should report the arm gcc (and also make all references to the tool chain components grab the arm components).

I can't see how, when you enter:
arm-linux-gcc
that you are picking up the compiler that is being reported in the messages.
There must be some other local settings that you have that make it do that.
Check those, or post them for review here.

[twobob]

Originally Posted by geekmaster

@twobob: I was getting those errors too on static builds at first. For static compiles, before compiling the alsa lib you need to run alsa configure with " --enable-static --disable-shared" (and I used a few more too as suggested by NiLuJe). You can read what I used here: https://www.mobileread.com/forums/sho....php?p=2146686

I upgraded to CS 2010q1-202 because it fixed some little documented compiler bug that had bitten me on a previous build. I do not remember what now, but I am pretty sure that it is documented somewhere in one of my almost 3K posts somewhere in this forum.

Ah yes.

I have managed to convince it to build shared for now. Since "standalone" static binaries aren't truly static anyways (IMHO), and we have a known platform I think I will stick to shared - on the understanding that shared builds continue to work across all platforms - which they should now. I recompiled alsa with your settings and building shared doesn't give me any errors anymore. So I will go with that.

[twobob]

Originally Posted by knc1

I assume from the filename this is a C not a C++ source, so ...
--static --static-libgcc
Ref: http://gcc.gnu.org/onlinedocs/gcc-4....l#Link-Options
That will take care of the warning messages about the runtime (if CS built a static libgcc - I haven't checked for that).

GM's choice of 2010q1-202 (a CS product, prior to purchase by MG) is one very close to what lab126 was using on the K5. "We stock" the 2010-09 for that purpose, one (six months later) release. Shouldn't be much difference between the two.

For "new work" such as this, using the most recent release (2012.03-57) is the way to go. You shouldn't run into the corner cases where you need to match the original compiler version.
Some of the work GM does, does run into them and does require a "best match" of the tool chain.

While cross compiling, try setting your PATH to:
export PATH=/home/simon/CodeSourcery/Sourcery_CodeBench_Lite_for_ARM_GNU_Linux/bin:$PATH
Then: gcc --version
should report the arm gcc (and also make all references to the tool chain components grab the arm components).

I can't see how, when you enter:
arm-linux-gcc
that you are picking up the compiler that is being reported in the messages.
There must be some other local settings that you have that make it do that.
Check those, or post them for review here.

Well I can answer that. I was tired of typing the long version so I just ln -s'd the shorter triplet to the long ghueabi version. Should have said, my bad.

The error only exhibits when sing the alsalib and only when used static.
Since I am happy with shared I will file this under - weird - and move on.

Thanks v much!

[knc1]

Originally Posted by twobob

Only when using --static.
Since I am happy with shared I will file this under - weird - and move on.

Thanks v much!

File it under: "anytime trying to build fully static against glibc".
Plus, sometimes you have to: --static --static-libgcc --disable-shared
when building against glibc. (That, for instance, will make Busybox happy.)

The other common "C" libraries (uClibc, eglibc, newlib) are more suited for building static and deal with this another way.

[knc1]

Originally Posted by twobob

Well I can answer that. I was tired of typing the long version so I just ln -s'd the shorter triplet to the long ghueabi version.

Doing that might (probably will) lead to problems with the other components of the tool-chain.

If you browse the tool-chain tree, you will find "gcc" in two places ...
One, under an "ARCH qualified path / bin"
One, where the "ARCH qualifier" is part of the "gcc" file name.

You want the full, absolute, path to the "ARCH qualified path / bin" first in your path search order.
Listing the contents of that "ARCH qualified path / bin" will show just how many components are included in the tool-chain.

Ah, another bit of related trivia: the application "gcc" is not the compiler. It is the command line option processor "front end" to the tool-chain. It in turn munges the options and calls the various other components in that "ARCH qualified path / bin" to get the various parts of the compile done.
At which point the tool-chain behavior usually turns into crap when its intial access was via a (shortened) symbolic link.

[twobob]

Originally Posted by knc1

Doing that might (probably will) lead to problems with the other components of the tool-chain.

If you browse the tool-chain tree, you will find "gcc" in two places ...
One, under an "ARCH qualified path / bin"
One, where the "ARCH qualifier" is part of the "gcc" file name.

You want the full, absolute, path to the "ARCH qualified path / bin" first in your path search order.
Listing the contents of that "ARCH qualified path / bin" will show just how many components are included in the tool-chain.

Ah, another bit of related trivia: the application "gcc" is not the compiler. It is the command line option processor "front end" to the tool-chain. It in turn munges the options and calls the various other components in that "ARCH qualified path / bin" to get the various parts of the compile done.
At which point the tool-chain behavior usually turns into crap when its intial access was via a (shortened) symbolic link.

Ar! I see what you mean

Rightyo then, I will do a tidyup before I try any statically charged builds and call from the fully qualified name for now then!
Thanks knc1

[knc1]

Originally Posted by twobob

Ar! I see what you mean

Rightyo then, I will do a tidyup before I try any statically charged builds and call from the fully qualified name for now then!
Thanks knc1

Ah, if you put the "fully qualified name/bin" on your path, then:
gcc
ar
ld
etc, etc, etc is all you have to call.
This will fix most, simple "makefiles" - for Autotools stuff you need sb2 also.

Let me see now, I haven't done it, so I'll do it right now and make a follow up post.

[knc1]

Oops.
One very bad idea deleted here.

Works for simple builds but breaks makefiles that need to access both host and target tools.

Instead of this post, follow the directions bundled with the x-compiler(s).

[twobob]

@Knc1

You hero. much appreciated!!

[knc1]

Originally Posted by twobob

You hero. much appreciated!!

Not yet - give it some tries with the more difficult to build things.

If you find a difference between calling by the short name and the long name - then we will have to out-smart it some other way.

At least all changes to the file system (other than the PATH modification) are in one directory.

Un-install: rm -fr /opt/arm-2012.03
And fix the PATH modification statement if you used it.

[twobob]

Originally Posted by knc1

Not yet - give it some tries with the more difficult to build things.

If you find a difference between calling by the short name and the long name - then we will have to out-smart it some other way.

At least all changes to the file system (other than the PATH modification) are in one directory.

Un-install: rm -fr /opt/arm-2012.03
And fix the PATH modification statement if you used it.

noted!

[knc1]

Originally Posted by twobob

noted!

Since you have your notebook out now ...

For handwritten, off-the-wall, makefiles - -
Nothing replaces reading the author's work and if they don't use the commonly accepted build variables in commonly accepted ways, trying to "get inside their head" to cross-compile their work.

For autotools based sources (./configure, make, make install) you will need sb2 to cross-compile, or any of the various "native mode" tools because configure will insist on creating the output files based on what it finds on the host rather than the target.

Cmake based sources - I don't have a lot of experience with those, from what I read they **should** cross-compile but rarely do.

And then you run into things like: http://www.creytiv.com/baresip.html
Two library sets, a demo program and a client program.
Lots of good things in those library sets (A/V codecs, low level bit and byte bashing, etc.) which might be of use to various projects here.

Step one of cross-compiling anything: read the Makefile (with capital M). Your next move will be based on what you find there.

re-0.4.1:Makefile
First impression - cross-compiling other than from mingw32 to linux will be a lot of fun.

It might be quicker to do this one as an "emulated native" build under Aboriginal Linux http://landley.net/aboriginal/about.html

See the following post for a quick tour of building a static application using Rob Landley's Aboriginal Linux.

[knc1]

This environment can only build STATIC linked programs to run on the Kindles!
But since building STATIC linked programs seems to be a common speed-bump ...
It will build dynamically linked programs, but for uClibc, which is not what the Kindles are using.
* * * *
Presumes a QEMU that provides: qemu-system-arm is already installed.
Confer with your Linux package manager about that subject.
and/or
Give my hand-built one a try, attached to post:
https://www.mobileread.com/forums/sho...3&postcount=85
and provide feedback on your results.

Make a work place and grab the tar-ball:

core2quad ~ $ mkdir BLDS
core2quad ~ $ cd BLDS
core2quad BLDS $ wget http://drpbox.knetconnect.com/KeK/system-image-armv6l.tar.bz2

Extract the contents onto the current working directory and then make that directory current:

core2quad BLDS $ tar --extract --file=system-image-armv6l.tar.bz2
core2quad BLDS $ cd system-image-armv6l

Make a quick check that the install is working on your host machine:

core2quad system-image-armv6l $ ./run-emulator.sh
  qemu-system-arm: pci_add_option_rom: failed to find romfile "pxe-rtl8139.rom"
  Uncompressing Linux... done, booting the kernel.
  Booting Linux on physical CPU 0
  * * * *
  VFS: Mounted root (squashfs filesystem) readonly on device 8:0.
  Freeing init memory: 100K
  8139cp 0000:00:0c.0: eth0: link up, 100Mbps, full-duplex, lpa 0x05E1
  Not using distcc.
Type exit when done.
(armv6l:1) /home # gcc -dumpmachine
  armv6l-unknown-linux-gnueabi
(armv6l:1) /home # uname -a
  Linux (none) 3.4.0 #1 Sat Jul 14 08:57:51 CDT 2012 armv6l GNU/Linux
(armv6l:1) /home # exit
  Restarting system.
core2quad system-image-armv6l $

Now display the deb-environment.sh script, read the comments at the top.

The above, default, system image only has a 32Mbyte /home directory.
For development, you want a larger /home directory.
If you execute ./dev-environment.sh without setting any environment varables it will create a 2Gbyte /home directory file for you.
You can always use the ./dev-environment.sh script for entry, it will not over-write any existing hdb.img.

How do you get your files in and out of the emulated arm system?
Read and follow the comments in ./native-build.sh;
OR
Just mount the hdb.img (the /home when inside the emulated system) and copy to and fro as required.

core2quad system-image-armv6l $ sudo mkdir /mnt/hdb
core2quad system-image-armv6l $ sudo mount -o loop hdb.img /mnt/hdb
- - - copy, copy, modify, copy - - -
core2quad system-image-armv6l $ sudo umount /mnt/hdb

OR
Just 'wget' your sources while inside the environment, for an example tinycc (which defaults to building as dynamicly linked - at least this one does):

core2quad system-image-armv6l $ ./dev-environment.sh
  * * * *
  Type exit when done.
(armv6l:1) /home # wget http://drpbox.knetconnect.com/KeK/tinycc-patched.tgz
(armv6l:1) /home # tar -xf tinycc-patched.tgz
(armv6l:1) /home # cd tinycc
(armv6l:1) /home/tinycc # (edit configure cpu list to include armv6l)
(armv6l:1) /home/tinycc # ./configure
(armv6l:1) /home/tinycc # make
(which will fail when it tries to build documentation, so what?)
(armv6l:1) /home/tinycc # ./tcc -v
tcc version 0.9.25
(which by the way, is a lie -- this is the not yet released 0.9.26)

We know that it does not use any of the whizz-bang new syscalls in Linux-3.4, so it does not matter that it was built against version 3.4 header files.

This copy of tinycc will also "build static" executables.
It will build "shared library" executables for uClibc (its own environment)
It might be possible to build "shared library" executables with it for a glibc environment also - provided you get all the system library over-ride commands required correct on your tcc command line.

Something always needs to be left as a: "student exercise"
As in: what became of /usr/include/stddef.h ?

Continued at post: https://www.mobileread.com/forums/sho...7&postcount=76
Where the final tcc-static is built.

[knc1]

False alarm. I had included <stdio.h> in my HelloWorld.c file when I did not need to.

Source:

main() {
    printf("Hello World\n");
}

Test:

(armv6l:1) /home # ./tcc -run hello.c
Hello World

On that note, will change the above link back to the Aboriginal Linux that I built from Rob's repository head.

[twobob]

Brain hurt.

Need two lifetimes to catch up with your headspace.

*goes and gets second lifetime*

This information is golddust. thanks mate