(old)Puppy Linux Discussion Forum

This usually works pretty much according to their documentation.
The following is a script I use to do this: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.

gyro

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.

Comments?

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

gyro

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)