Puppy Linux Discussion Forum Forum Index Puppy Linux Discussion Forum
Puppy HOME page : puppylinux.com
"THE" alternative forum : puppylinux.info
 
 FAQFAQ   SearchSearch   MemberlistMemberlist   UsergroupsUsergroups   RegisterRegister 
 ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

The time now is Fri 18 Apr 2014, 19:38
All times are UTC - 4
 Forum index » Off-Topic Area » Programming
Need examples of static compiling of various apps.
Post new topic   Reply to topic View previous topic :: View next topic
Page 2 of 4 [57 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Author Message
sunburnt


Joined: 08 Jun 2005
Posts: 4981
Location: Arizona, U.S.A.

PostPosted: Sat 19 May 2012, 23:20    Post subject:  

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

Thanks for the code technosaurus; I think I`ll rename the links for restoring.
Quote:
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?
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 430
Location: State of Jefferson

PostPosted: Sun 20 May 2012, 00:13    Post subject:  

sunburnt wrote:
Thanks Ibidem; Clarification is everything to understanding.
As my grandfather used to say, whelks!
Quote:

# 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.
Quote:

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)
Quote:

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.
Quote:

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
Quote:

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)
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3219

PostPosted: Sun 20 May 2012, 02:42    Post subject:  

http://www.yolinux.com/TUTORIALS/LibraryArchives-StaticAndDynamic.html
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 4981
Location: Arizona, U.S.A.

PostPosted: Tue 22 May 2012, 15:21    Post subject:  

Thanks jpeps; From your link I got this static lib. compile:
Code:
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:
 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;
Quote:
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
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3219

PostPosted: Tue 22 May 2012, 18:31    Post subject:  

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.
Back to top
View user's profile Send private message 
technosaurus


Joined: 18 May 2008
Posts: 4134

PostPosted: Tue 22 May 2012, 18:39    Post subject:  

-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)
_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3219

PostPosted: Tue 22 May 2012, 18:53    Post subject:  

technosaurus wrote:
-static just reverses the preference to prefer linking lib*.a from $LD_LIBRARY_PATH ...


It might actually build them into the binary ?
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 430
Location: State of Jefferson

PostPosted: Tue 22 May 2012, 19:29    Post subject:  

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...
Back to top
View user's profile Send private message 
Ibidem

Joined: 25 May 2010
Posts: 430
Location: State of Jefferson

PostPosted: Tue 22 May 2012, 19:37    Post subject:  

sunburnt wrote:

### Ibidem;
Quote:
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.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 4981
Location: Arizona, U.S.A.

PostPosted: Tue 22 May 2012, 21:30    Post subject:  

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 Tue 22 May 2012, 21:52; edited 1 time in total
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3219

PostPosted: Tue 22 May 2012, 21:35    Post subject:  

I think that's what TC is doing (I checked out their MB for approx 20 seconds Smile )
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 4981
Location: Arizona, U.S.A.

PostPosted: Tue 22 May 2012, 22:12    Post subject:  

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.
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3219

PostPosted: Tue 22 May 2012, 22:27    Post subject:  

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.
Back to top
View user's profile Send private message 
sunburnt


Joined: 08 Jun 2005
Posts: 4981
Location: Arizona, U.S.A.

PostPosted: Tue 22 May 2012, 22:49    Post subject:  

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.
.
Back to top
View user's profile Send private message 
jpeps

Joined: 31 May 2008
Posts: 3219

PostPosted: Tue 22 May 2012, 22:54    Post subject:  

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.php?p=629138#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!
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 2 of 4 [57 Posts]   Goto page: Previous 1, 2, 3, 4 Next
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Off-Topic Area » Programming
Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You can download files in this forum


Powered by phpBB © 2001, 2005 phpBB Group
[ Time: 0.0888s ][ Queries: 12 (0.0105s) ][ GZIP on ]