Puppy Linux Discussion Forum

[sunburnt]

Agreed, doing programming of any type, or compiling anything is an exercise
in thankless and endless updating, sometimes needed and many times not.

The idea is for app. pkgs. that are widely usable and will keep working longer.
I made a static Skype SFS many years ago, and it still works in many cases.
The hope is to leap frog generations of apps. and libs., thus reducing effort.

I see little difference between app. versions, browsers are the exception.
Wait until they do the inevitable, they make the old versions unusable ( M$ ).

[jpeps]

In general, it's probably easiest to just choose the distro that already includes most everything you need. I wonder what percentage of users have ever compiled anything.

[sunburnt]

Very few I`m sure, I`ve avoided it for years now as I`ve had such bad luck.

I`d hope some well traveled app. compilers would help list media and games.
What are the common deps. for the popular media apps., and for the games?
Also X, xVesa, xOrg, GTK+, pango, cairo, and so many more needed items.

Tiny Core`s stripped, a good starting point, but it needs lots more added to it.
Debian or Ubuntu are probably the best choices for building the app. pkgs.
But would the apps. run properly on Tiny Core? Static apps. should, but...

[jpeps]

Have you checked out CDE? Automatic packaging of Code,Data,Environment. I used it a while ago to send exactimage to Dingo, and he was able to run it his own distro.
http://www.pgbovine.net/cde.html

[sunburnt]

Thanks jpeps; I downloaded it, not sure what to try it on.
The big problem I see is the "having to use everything in the app."...

# I compiled Fox Kit, I realized I should have put it in: /SqApp/mnt/Xfe/usr
But the only *.a libs. are: /lib/libCHART-1.6.a and: /lib/libFOX-1.6.a
Do I need to recompile it, or as the libs. are to be included, does it matter?
I think the path would not matter if just the code in the .a files is being used.

As was said, I should remove all Fox`s *.so libs. and links from the build dir.

# I was surprised to see the kit has calculator, file browser, and editor apps.!

Note: I need a faster PC, Fox Tool Kit took forever to compile at 20 MB total.

[jpeps]

[sunburnt]

Thanks, I`ll take a look at it, examples are the best learning tool.

In thinking about it, you need a working app., so a big distro. with everything?
You could try all the apps. and use the ones you want with out all the building.

Plus he talks about compressing it, and then uncompressing it to use it.
But if it were in a Squash file then all the effort isn`t needed, just mount it.

### Please look at the new forum thread I started in "Compiling":
http://www.murga-linux.com/puppy/viewtopic.php?p=629595#629595

[jpeps]

The other advantage is that you can move the package anywhere (pen drive, etc), since nothing gets installed.

[sunburnt]

More thoughts about static compiling...

# 1) How to point to libs. to be used in the build?
............. If I build libs. for the app. pkg., I don`t want them in /lib or /usr/lib

# 2) Tried pointing to a lib.: LD_LIBRARY_PATH=/Path/Lib:$LD_LIBRARY_PATH
............. LD_LIBRARY_PATH is the first thing parsed for finding libs. Didn`t work.

# 3) In a static build, how to control what`s to be added and what`s not?
............. If it`s totally static, the kernel would be in the pkg. too. Add / Deny lists?

[penguinpowerppp]

Add -L/path to your CFLAGS, where path is the directory with your lib
if you don't want it to even look in /lib or /usr/lib use -nostdlib
similarly use -nostdinc and -I/path to do the same for includes

There is no way to link in the kernel all you can do is interact via syscalls
Which is what libc does but glibc is really bad for static links...musl or uclibc are better and dietlibc has other issues

[sunburnt]

Thanks penguinpowerppp; More of the picture is taking shape.

So glibc is not so good and libc is good. Are musl and uclibc better than libc?
libc seems like a good one as it`s main stream, and I think none are compatible.
Another words, apps. compiled with one are not going to work on any others.

Clarify: "Add -L/path to your CFLAGS", Correct use is: "configure -L/path"?

Please clarify the difference between -L CFLAGS and -I includes (RPATH?).

### -L sets /PathToLib , -I copies the lib. into the build and sets /PathToLib ?

None of this has to do with static libs. (*.a) which are compiled into the build?

Thanks for -nostdlib and -nostdinc , no one has said anything about them.
Both keep system libs. out of the build (good), -nostdinc seems best to use.
In using these I must have all the deps. compiled before building the app.
So I can keep a dir. of compiled libs. and use " -nostdinc -I " to point to it?

Thank again... Terry

[jpeps]

[technosaurus]

glibc is short for gnu libc - it is a libc, but so many things get inlined that a static compile adds half a Mb for a simple hello world. eglibc is slightly better depending on the config options and musl, uclibc and diet were designed with static compiling in mind; whereas Ulrich Drepper formerly (mis-)guided the gnu libc to being only effective as a shared library and only on x86 platforms

-I is for the locations of specific .h files (with -nostdinc it will only look there)
-L is for the locations of .a and .so files (with -nostdlib it will only look there)
-D is used to define a symbol (for example adding -DNODROIDFONT saves mupdf from building in an unnecessary 3Mb font)
you can use as many of these as you want

to add it to CFLAGS/LDFLAGS it would be

[jpeps]

"I do not know where to find the historic references, but yes, static linking is dead on GNU systems. (I believe it died during the transition from libc4/libc5 to libc6/glibc 2.x.)"


http://stackoverflow.com/questions/3430400/linux-static-linking-is-dead

[sunburnt]

Yeah, everyone has their own ideas about how things should be... (glibc)

Thanks again technosaurus; I wanted full examples and I`m getting scraps.
It`s hard to put it all together when you`ve never seen a complete example.

# Lots more Qs to clarify further if I could ( numbered As for each ):

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...)

1 ) "-nostdinc -I..." used only in CFLAGS and "-nostdlib -L..." in LDFLAGS ?
___ This seems to be a very critical piece of info...

2 ) To use -nostdinc or -nostdlib means all "ldd" lib. deps. are needed?

3 ) Used alone, -L locations are searched before the system`s lib. paths are?

4 ) -D(symbol) , but how to know what potentially unneeded items there are?

5 ) -static is used with make? Need a clear picture of what it does exactly.

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.?

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.)

# Things like X, GTK+, other O.S. deps. and other deps. should be shared.
# Different versions of GTK+ and other deps could give problems though...

The more complicated apps. give me lib. problems. Hope this helps!!!