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 Wed 01 Jul 2015, 13:03
All times are UTC - 4
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Compiling
Compiling wxWidgets library
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
Page 1 of 1 Posts_count  
Author Message

Joined: 28 Oct 2008
Posts: 772
Location: Brisbane, Australia

PostPosted: Sun 10 Nov 2013, 13:04    Post_subject:  Compiling wxWidgets library  

This usually works pretty much according to their documentation.
The following is a script I use to do this:


cd ${WXROOT}
rm -r -f ${WXBUILD}
mkdir -p ${WXBUILD}
../configure --enable-unicode --disable-debug_flag --disable-shared --disable-compat28 --prefix=${WXPREFIX} --with-gtk

make install

rm *.o

ln -s "${WXPREFIX}/bin/wx-config" "${WXCONFIGPATH}/wx-config"
ln -s "${WXPREFIX}/bin/wxrc" "${WXCONFIGPATH}/wxrc"

A number of considerations concerning the build are contained in the first 3 symbols;
WXROOT is simply the path to the directory created by extracting their tar.bz2 file.
WXPREFIX defines where it will end up. It would be easy to just install it into /usr/local, but then it's not quite so easy to cleanup if you want to replace it. So I always install it some where else.
WXCONFIGPATH has to be a directory that appears in the "PATH" list. Compilers and IDE's need to be able to run "wx-config" without specifying any path.
(The script also makes a link for "wxrc", just in case you find a use for it.)

The other main consideration with building wxWidgets, is "shared" or "disable-shared". I choose "disable-shared" because then I'm finished at this point. But, if "shared" is chosen, then a mechanism to make the shared libraries available to the program at runtime needs to be setup, on this machine, and on every machine where the application is installed.

I know if at least 3 ways to make shared libraries available to a program at runtime:
1) Put links to the libraries in a directory in the "LD_LIBRARY_PATH" list.
2) Run the application via a wrapper script that modifies the "LD_LIBRARY_PATH" list, just before executing the application.
3) Use the "rpath" facility to embed a path to the libraries within the applications executable file.

Anyway, these runtime issues don't bother me anymore.

Back to top
View user's profile Send_private_message 
Moose On The Loose

Joined: 24 Feb 2011
Posts: 595

PostPosted: Sun 10 Nov 2013, 13:38    Post_subject: Re: Compiling wxWidgets library  

gyro wrote:
This usually works pretty much according to their documentation.

I compiled wxWidgets as part of making kicad. It went so easily I didn't even think it was something worth comment. I then made my first cut of a kicad pet and put up the link in the comments. I put the needed libraries in and also put a copy of ldconfig in my-applications/bin so that the pinstall.sh script could run it. I then tested it on a clean-006 528 CD boot and the method seems to work.

The only real worry was the risk of stomping on an existing wxWidgets install. I don't like dependencies in my pets so I have been thinking of a solution. I think I may have one.

Since at least in theory, a library with the same name (all the way to the .so.5) will do the same functions, a pet file can carry the libraries it needs along but not in the normal places. Instead, it can have the pinstall script move them into place if they are not already in the system.

Back to top
View user's profile Send_private_message 

Joined: 28 Oct 2008
Posts: 772
Location: Brisbane, Australia

PostPosted: Sun 10 Nov 2013, 20:24    Post_subject:  

Moose On The Loose,

One of the reasons I put these comments here, is to emphasise how easy it is to do. So there is really no need for anyone to go searching for a ".pet" or ".sfs" of a particular wxWidgets version/build, just do it yourself.

Shared libraries for use at runtime, can be moved wherever you like, as long as the application can find them. I have set "rpath" to "$ORIGIN/../lib" with success. Thus keeping the needed libraries within the application bundle.

On the other hand, moving the "installed" wxWidgets as used by IDE's and compilers, is another story. If you move it, you either have to fix "wx-config" to report the new location, or place a link at the old place so that the "installed" path still works.

But now I don't do either. I use a "static" build of wxWidgets, so that the bits of it I use get loaded into the executable. And since I compile wxWidgets myself, I make sure that it gets installed where I want it.

On the ".pet" issue, I have created ".pets " that contain a ".tar.bz2" file in "/tmp" and the pinstall script unpacks it into place, and then the now useless ".tar.bz2" file simply disappears at the next boot, thus not wasting space in "pup_rw".

Back to top
View user's profile Send_private_message 

Joined: 18 May 2008
Posts: 4518

PostPosted: Wed 11 Dec 2013, 01:25    Post_subject:  

or you can build a static wx (and no shared version) and building will automatically link it right into your packages with no wx dependency (other than architecture independent resources such as images and config files)
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send_private_message 
Display_posts:   Sort by:   
Page 1 of 1 Posts_count  
Post_new_topic   Reply_to_topic View_previous_topic :: View_next_topic
 Forum index » Advanced Topics » Additional Software (PETs, n' stuff) » Compiling
Jump to:  

You cannot attach files in this forum
You can download files in this forum

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