sunburnt wrote:
0 ) Is it correct that none of these Cs will run apps. made on the other ones?
___ This could be a really serious problem for portable apps. ( hope not...)
Basically correct. Also largely irrelevant.
Almost every desktop linux (but not DeLi, pupngo, alpine, sabotage, a few other rarely used distros, or android) uses glibc2/libc6 or eglibc (a fork of glibc that's fully compatible)
musl is currently (0.9.1) working on LSB ABI support, which means a degree of interoperability with glibc.
uclibc doesn't even retain compatibility across versions (binaries built with 0.9.29 won't run on 0.9.30).
HOWEVER, if you compile statically (-static or -Bstatic), you can build one program and run it on just about any machine of the same architecture. You do not need ANY C library installed to run a static binary.
1 ) "-nostdinc -I..." used only in CFLAGS and "-nostdlib -L..." in LDFLAGS ?
___ This seems to be a very critical piece of info...
I would use -nostdinc -I... in CFLAGS & CPPFLAGS; -nostdlib -L... would go in CFLAGS & LDFLAGS
This is because I've seen several subtly broken build systems that used gcc $CFLAGS for linking, or ran a preprocessor that ignored CFLAGS, or ignored CPPFLAGS altogether...
2 ) To use -nostdinc or -nostdlib means all "ldd" lib. deps. are needed?
Yes, including -lc
3 ) Used alone, -L locations are searched before the system`s lib. paths are?
Yes, as long as they come before the libraries that are searched for.
IIRC, gcc .... -L./ -labc would find ./libabc.a, while -labc -L./ would not.
If you had ./libm.so, the first pattern would link against it, while the second pattern would use /lib/libm.so
4 ) -D(symbol) , but how to know what potentially unneeded items there are?
In advance? Find someone else's build scripts or read the source code.
It's simplest to try building, then look up whatever stops the build.
5 ) -static is used with make? Need a clear picture of what it does exactly.
When using make or any normal build system,
before configuring or building.
CFLAGS is extra options (flags) for the C compiler to use.
With a simple make-based build system,
make CFLAGS=-static
should be enough.
I'll try giving a simple example:
If compiling with gcc,
Code: Select all
gcc -Os -static -D_XOPEN_SOURCE minimp3.c -lm -o minimp3
will/"should" compile minimp3 fully static.
In other words, only .a libraries are searched for symbols/functions *; any code that the program needs will be linked into the binary. When I say linked into, I mean that the object files become part of the statically linked program/app/binary.
Dynamically linked (using shared libraries/ .so files) programs just request at runtime that the .so file be put in RAM with its code available for anything to call. Sometimes "linked into" is used to refer to this, but it doesn't quite fit what's happening.
(*it may fallback to shared libraries, according to technosaurus)
6 ) Using downloaded .so files. is a gamble. Is there a good way to do it?
7 ) The advantage to .a files is they compile with and into the app.?
___ Possible at the same time to compile .so files with and into the app.?
Not clear what you mean compile with and into.
Do you mean "Will running
produce the .so files and an app linked against them at the same time " ?
If so: yes
Long answer: a .so file contains code that is
not included in the binary (app) linked against it. So no, it is not linked into the app.
8 ) Method to make complete tree files for app. cataloging and statistics?
___ There`s no way to do this for uncompiled apps.? Need working app.?
### This is for "relatively" self contained Squash file apps.
# Target is: ./configure --prefix=/SqApp/mnt/( AppPackageNameNoExt.)
I'm guessing this would be like
?
(if I understand correctly)
DESTDIR makes it install as if DESTDIR were /