Quote:
Originally Posted by NiLuJe
If you're adventurous like me, you *can* use a newer GCC/glibc pair (I'm using Linaro GCC 4.7/glibc 2.9 for my k2/k3 tc), but know that you might have to tweak some C stuff/trick autotools to avoid pulling stuff from newer glibc, and that C++ stuff will probably be a no-go unless you're willing/can statically link libstdc++. (And you'll have to kill gcc's ssp and glibc's fortify support, which is usually a simple matter of correct CPP/CXX/CFLAGS).
|
Using incremental linking stages in the overall construction of a run-time object can accomplish amazing things.
Some Makefiles are constructed to do that from the ground up (usually for very large applications), most small application Makefiles do not have that organization.
But this is hardly a software 101 build subject.
Shoot, it isn't even a Makefile 101 subject.
- - - -
On a related topic (no pun intended) . . . .
Someone wrote a dynamic loader wrapper that allows you to run more than one loader/libc on the same machine.
I.E: at object load time, it checks the elf header, then uses the appropriate dynamic loader.
Translation: You can install and run uClibc linked applications on a glibc system.
If I can just find where I put that link (I was going to build that utility for the K3).
As in:
Code:
core2quad ~ $ /lib/ld-linux.so.2
Usage: ld.so [OPTION]... EXECUTABLE-FILE [ARGS-FOR-PROGRAM...]
You have invoked `ld.so', the helper program for shared library executables.
This program usually lives in the file `/lib/ld.so', and special directives
in executable files using ELF shared libraries tell the system's program
loader to load the helper program from this file. This helper program loads
the shared libraries needed by the program executable, prepares the program
to run, and runs it. You may invoke this helper program directly from the
command line to load and run an ELF executable file; this is like executing
that file itself, but always uses this helper program from the file you
specified, instead of the helper program file specified in the executable
file you run. This is mostly of use for maintainers to test new versions
of this helper program; chances are you did not intend to run this program.
--list list all dependencies and how they are resolved
--verify verify that given object really is a dynamically linked
object we can handle
--library-path PATH use given PATH instead of content of the environment
variable LD_LIBRARY_PATH
--inhibit-rpath LIST ignore RUNPATH and RPATH information in object names
in LIST
--audit LIST use objects named in LIST as auditors
and
Code:
(armv6l:1) /home # /lib/ld-uClibc.so.0
Standalone execution is not enabled
Ah, s..., another thing Rob left out of his configuration and build.
And for those who may have forgotten, glibc is also an executable:
Code:
core2quad ~ $ /lib/i386-linux-gnu/libc-2.13.so
GNU C Library (Ubuntu EGLIBC 2.13-20ubuntu5.1) stable release version 2.13, by Roland McGrath et al.
Copyright (C) 2011 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.
There is NO warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
Compiled by GNU CC version 4.6.1.
Compiled on a Linux 3.0.17 system on 2012-03-07.
Available extensions:
crypt add-on version 2.1 by Michael Glad and others
GNU Libidn by Simon Josefsson
Native POSIX Threads Library by Ulrich Drepper et al
BIND-8.2.3-T5B
libc ABIs: UNIQUE IFUNC
For bug reporting instructions, please see:
<http://www.debian.org/Bugs/>.