Need examples of static compiling of various apps.

For discussions about programming, programming questions/advice, and projects that don't really have anything to do with Puppy.
Message
Author
User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#21 Post by technosaurus »

-static just reverses the preference to prefer linking lib*.a from $LD_LIBRARY_PATH (or by passing -L/path/to/libdir) ... and then if the static lib is not found, it will link the lib*.so (or is that -Bstatic? - one or the other will fail if all static libs aren't found, but I don't recall which)
Check out my [url=https://github.com/technosaurus]github repositories[/url]. I may eventually get around to updating my [url=http://bashismal.blogspot.com]blogspot[/url].

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#22 Post by jpeps »

technosaurus wrote:-static just reverses the preference to prefer linking lib*.a from $LD_LIBRARY_PATH ...
It might actually build them into the binary ?

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#23 Post by Ibidem »

technosaurus wrote:-static just reverses the preference to prefer linking lib*.a from $LD_LIBRARY_PATH (or by passing -L/path/to/libdir) ... and then if the static lib is not found, it will link the lib*.so (or is that -Bstatic? - one or the other will fail if all static libs aren't found, but I don't recall which)
man ld does not indicate this difference; gcc -static occasionally warns about symbols that will need shared libraries...

Ibidem
Posts: 549
Joined: Wed 26 May 2010, 03:31
Location: State of Jefferson

#24 Post by Ibidem »

sunburnt wrote: ### Ibidem;
Both the *.a and *.so files can be used in the build dir. in their proper paths?
Meaning both the *.a and *.so files can be compiled / added into the pkg.
*.a files are not shared, *.so files could be shared but not likely if in the pkg.
If a package builds and produces *.a files, only include them if the sfs is supposed to be used for producing static binaries.
If it produces *.so files, you need them unless you are compiling a library and only want static binaries to be possible.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#25 Post by sunburnt »

Thanks to all of you, much appreciation for your help.
I be trying to build a few games for experiments, small and simple then bigger.

From my simplistic Bash scripting point of view, it seems easiest to just set
LD_LIBRARY_PATH in an app. run script just before running the app`s. exec.

LD_LIBRARY_PATH is the first thing searched, so no conflicts with other paths.
LD_LIBRARY_PATH is broken or faulty, but in this case it`s used temporarily,
only to add: /Path/MntPt/usr/lib to the beginning of LD_LIBRARY_PATH .
So the app. should find all of it`s in-pkg. libs. while running. Correct ?

###> Does this seem like a bad idea?
.
Last edited by sunburnt on Wed 23 May 2012, 01:52, edited 1 time in total.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#26 Post by jpeps »

I think that's what TC is doing (I checked out their MB for approx 20 seconds :) )

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#27 Post by sunburnt »

jpeps; I just checked and you`re right, all of the SCM files are like that.

I`m thinking that just using "configure --prefix" to setup the pkg. properly.
Then just use LD_LIBRARY_PATH in the run script will be all that`s needed.

### I`m still a bit vague about what to include and what to use shared.
I need to find out the commonly used libs. and make them shared deps.
All other libs. and app. files ( like icons ) are included in the pkg.

Does anyone know media apps.? I think the codecs and maybe some libs.
like the gstreamer set of libs. would be good candidates for being shared.

The games have some common stuff too, openGL, Mesa, and others.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#28 Post by jpeps »

sunburnt wrote: Does anyone know media apps.? I think the codecs and maybe some libs.
like the gstreamer set of libs. would be good candidates for being shared.

ok, here's the problem with anything more complex, like media apps. There's no "static" linux libc. On the other hand, Skype static seems to work, although a few years ago I had trouble with that across different distributions as well. That leaves you with creating "static" apps for one flavor, with the same kernel and libc. I think TC excludes what's in their base.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#29 Post by sunburnt »

Exactly... Statistics to decide what files to include in the base.
Then hiding system libs. while compiling apps. into pkgs. ( as technosaurus
was saying is needed to force usage of other libs. ) becomes unnecessary.

This item I get the feeling is just going to be a very long learning experience.
What to have in the base shared libs., and what to include in the app. pkgs.
All the stuff that makes Linux work goes in the base, and very common libs.

I just don`t know enough about Linux and apps. to make a judgement on it.
.

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#30 Post by jpeps »

and what about the toolchain ? note: many developers feel they should make fresh compiles of all apps for every new distribution


Here's a recent example of why:


http://murga-linux.com/puppy/viewtopic. ... 138#629138

rcrsn51
Wary has a much older version of Ghostscript compared to Lupu, so that might be the problem. Or it might be that Imagemagick in Wary was never built against Ghostscript.

However, it is possible to convert PDFs to JPGs in Wary with a bit of scripting. But it assumes that your PDF is a simple one-page document.

Is that what you are looking for?
Back to top
View user's profile Send private message
Semme

Joined: 07 Aug 2011
Posts: 766
Location: World_Hub


New postPosted: Today, at 11:04 pm Post subject: Reply with quote
Older? BINGO! Right'choo are Rcrsn. Wary 5.1.2- pacman offers v8.15.4.

On your tip I overwrote the existing GS with v8.71 and guess what?

She's FLAWLESS!

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#31 Post by 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
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#32 Post by 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.

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#33 Post by 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
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#34 Post by 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

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#35 Post by 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
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#36 Post by jpeps »

sunburnt wrote: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."...
Here's an example of my calc script, which uses tcl-tk. You can run calc.cde inside the cde-package without installing tcl-tk or anything else. Everything is there, but you could also remove anything you wanted to make the package smaller. I could also add other scripts that use tcl-tk within the same package, and they would just use the same libs. Note my original script is present, which can be altered to suit (files are in the cde-root dir).

http://jpeters.net/apps/cde-package.tar.gz
Attachments
calc.png
(27.77 KiB) Downloaded 512 times

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#37 Post by 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/viewto ... 595#629595

jpeps
Posts: 3179
Joined: Sat 31 May 2008, 19:00

#38 Post by jpeps »

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

User avatar
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#39 Post by 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
Posts: 5
Joined: Sat 14 Apr 2012, 23:49

#40 Post by 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

Post Reply