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
sunburnt
Posts: 5090
Joined: Wed 08 Jun 2005, 23:11
Location: Arizona, U.S.A.

#16 Post by sunburnt »

This is starting to make some good sense now...

Thanks for the code technosaurus; I think I`ll rename the links for restoring.
Linus Torvalds: Show me the code!
NTFS seems to have the M$ mark of death by design. Ext3 & 4 drivers for Win.

Thanks Ibidem; Clarification is everything to understanding.

# So a complete clarification as to lib. utilization. 5 Qs...

1: Both the *.a and *.so files can be used in the build dir. in their proper paths?
2: *.a files are built with everything else, *.so files are just added to the package?

3: *.a files must have any matching *.so system files hidden for them to be used.
4: But if a *.so file file is in the build dir., also hide matching *.so system files?

5: So if a system *.so file is found, it`s always used before anything in the build?

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

#17 Post by Ibidem »

sunburnt wrote:Thanks Ibidem; Clarification is everything to understanding.
As my grandfather used to say, whelks!
# So a complete clarification as to lib. utilization. 5 Qs...
1: Both the *.a and *.so files can be used in the build dir. in their proper paths?
Don't understand this question.
2: *.a files are built with everything else, *.so files are just added to the package?
*.a files are compiled into the binary, *.so becomes a dependency (must be added to package unless you expect them to hunt em down)

(I'm not using your terminology because it means something different from what you think: literally, it would mean that the *.a libraries are produced by the compilation process along with the binaries)
3: *.a files must have any matching *.so system files hidden for them to be used.
Or you can use -static for a fully static binary, and there might be another option I don't know about, but usually, yes.
4: But if a *.so file file is in the build dir., also hide matching *.so system files?
Only if -L. is in the compiler options
5: But if system *.so file is found, it`s always used before anything in the build?
AFAIK, first paths specified by -L are searched, then system paths.
Current directory is not searched for libraries, only object files (*.o)

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

#18 Post by jpeps »


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

#19 Post by sunburnt »

Thanks jpeps; From your link I got this static lib. compile:

Code: Select all

Compile: cc -Wall -c ctest1.c ctest2.c
Compiler options:

    -Wall: include warnings. See man page for warnings specified.

Create library "libctest.a": ar -cvq libctest.a ctest1.o ctest2.o
List files in library: ar -t libctest.a
Linking with the library:

    cc -o executable-name prog.c libctest.a
    cc -o executable-name prog.c -L/path/to/library-directory -lctest
And this dynamic lib. compile:

Code: Select all

 gcc -Wall -fPIC -c *.c
    gcc -shared -Wl,-soname,libctest.so.1 -o libctest.so.1.0   *.o
    mv libctest.so.1.0 /opt/lib
    ln -sf /opt/lib/libctest.so.1.0 /opt/lib/libctest.so
    ln -sf /opt/lib/libctest.so.1.0 /opt/lib/libctest.so.1
### 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.

# Again... These Squash files will mount but not be unioned ( not sfs files ).

I made a xMahjongg pkg. configured with --prefix (Mount Pt.), and it works
without adding the lib. paths to /etc/ld.so.conf or $LD_LIBRARY_PATH .
All I`ve read says not to use $LD_LIBRARY_PATH , but Puppy does.

rpath is the apps. internal "run path", two ways to set rpath:
> Set the environment variable $LD_RUN_PATH ( Puppy doesn`t have it...)
> Add -R /usr/local/lib (or whatever path) to the link command line.
Web page about paths and rpath: http://www.eyrie.org/~eagle/notes/rpath.html
# Best is: $LD_RUN_PATH ( set in Bash session before start of compile? ).
But if -R is used in the link command line then $LD_RUN_PATH is ignored.
# If Autoconf is used, the easiest way is to set LDFLAGS to "-R /usr/local/lib"
before running configure, which will then stick it into the Makefile.
Failing that, do something like: make CC="gcc -R usr/local/lib ( or path...) ".

# Now I`m not sure what --prefix is doing really, and what -static does also.
# Shouldn`t -static make both the *.a and *.so files "findable" in the pkg.?

Thanks again for all the help guys. Terry

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

#20 Post by jpeps »

sunburnt wrote: # Shouldn`t -static make both the *.a and *.so files "findable" in the pkg.?

Thanks again for all the help guys. Terry
I'll take a novice guess, and say that -static builds the *.a libs into the binary, and that you need to indicate the path to the *.so files.

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.

Post Reply