a standard compiling puppy

What features/apps/bugfixes needed in a future Puppy
Post Reply
Message
Author
User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

a standard compiling puppy

#1 Post by sc0ttman »

My horrible rant (sorry):

I personally don't like seeing new apps appearing for Puppy that have been compiled in Wary/Lupu or any other Puppy which has newer libc, gtk, (etc) when it is not absolutely necessary - particularly when we are talking about simple or command line apps.

This means users of older Puppies, even the great 431, cannot have access to these new apps, as they will not work. In the future it may mean users of Puppy 4 and 5 users cannot use most of the stuff built for Puppy 6.

Is it not in the interest of Puppy to have at least one 'puplet' that focuses primarily on compiling for a wide range of Puppy versions?

A solution?

Could the devx of later Puppies (5xx) not be updated (downgraded?) so that it compiles stuff which will work on older Puppies?

OR, if not...

It would be nice to see dev and frequent compilers (and anyone who wants to give it a go) use a standard "compiling Puppy" puplet - based first and foremost around a solid compiling environment, designed to reliably build packages (separating DEV, NLS, etc) that works across the widest range of Puppies possible.

Some past experiences:

I like to compile stuff on Puppy 4.2.1 (to be precise) whenever possible, so most people can use the packages. But unfortunately, I am a real novice at compiling, and have trouble making many source packages compile in Puppy 420, which can be done 421, but more easily in 431 (some packages built still work in 420).

However, we have experts around:

- Ttuuxxx likes to keep Puppy 214X alive, and has complied loads of great stuff for that series.
- Ttuuxxx also has fixed and updated the devx part of various Puppy versions, making them compile more stuff, and build smaller, better packages/binaries.
- Dingo likes to compile stuff on Puppy 3, so whatever he compiles will work on nearly all Puppies for the rest of us!
- Jemimah has compiled loads and loads of stuff for Puppeee and Fluppy (which is 431) - a lot of which works on older pups.

Good for them!

So I wonder how many of the things that supposedly require Puppy 5, could be made available to all Puppy users. I had trouble getting Deadbeef to compile in 421, but I know it can be done (by someone who actually knows what they are doing) in Puppy 2.

How "retro", "stable" or "old" can a Puppy devx be, and still maintain an up-to-date, relevant, working compiling environment? I know different apps require different versions of libc, gtk, etc, but how far back can we go in the devx, and still build the latest stuff?

This entire post is probably not gonna bother most people

I know most users are happy to upgrade their Puppy versions when they feel like they are missing out on the latest developments (usually meaning the latest apps), particularly as it is so easy to upgrade or switch Puppy versions, or even run multiple Puppies alongside each other (which is great, don't get me wrong).

Just thought I'd ponder out loud this time.

User avatar
Dingo
Posts: 1437
Joined: Tue 11 Dec 2007, 17:48
Location: somewhere at the end of rainbow...
Contact:

#2 Post by Dingo »

well said. :lol:

I try, as long as possible, to build statically (so any later puppy can hopefully use app I compile in Puppy 3.01)

I'm planning to create an sfs for a fully-featured compiler (including fortran and other languages other newer libs), but this task is very problematic, my first attempt to do this has been unsuccessful since compiling environment of puppy 3.01 lacks in needed dependencies to build new gcc and these dependencies, (that are many) need to be at their time compiled from source, so this task it is tedious an very long

common issues I experimented compiling new apps in Puppy 3.01:

. intltool tool old (solved using intltool from debian lenny)
- X11 libs not found (I symlinked from /usr/X11R6/lib/ to /usr/lib)
- gtk+ too old (some times it is possible set an older gtk version in configure script, other times no)

and so on...

a reason to try to build latest gcc for older puppies is the ability to use the switch -mtune=native. this switch has been added in gcc from 4.3.x series, and give ability to have the maximum from own processor (this regards only self-compilers, since when we compile for others must use the generic optimizations, so apps can run on any i486 and higher)

how can older puppy users benefit of app compiled in newer puppies?

several ways:

- we can try to portabilize apps witch

*cde*
- http://www.stanford.edu/~pgbovine/cde.html
CDE: Automatically create portable Linux applications

DE (formerly known as CDEpack (formerly known as CDE)) is a tool that automatically packages up your Linux programs so that they can run on other computers with no installation or configuration, thereby eliminating dependency hell.

CDE makes it easy to perform reproducible research, share research prototypes, run software in non-native environments, deploy applications to the cloud, and create reproducible bug reports
using the .ermine strategy
- http://magicermine.com/index.html
Ermine
Tools for Professional Software Deployment
One executable running everywhere

Do you often find yourself struggling with your GNU/Linux application's dependencies? Did you ever ask yourself whether it is not possible to make deployment of your application just work instead of adapting to external libraries and target host configurations?

Ermine is the answer to these questions.
What can Ermine do for you?

Ermine packs a GNU/Linux application together with any needed shared libraries and data files into a single executable.
This file can be copied to any GNU/Linux host and run without further modifications.
What are the advantages?

Deploying applications with Ermine offers a lot of advantages which we have summarized here:
Basic functionality

* Only one file is installed
* Escape from “dependency hell
replace .co.cc with .info to get access to stuff I posted in forum
dropbox 2GB free
OpenOffice for Puppy Linux

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#3 Post by big_bass »

1.) Narcissism and linux dont mix
no "one person" maintains linux it is a joint effort following standard linux practices

buildscripts are for compiling across different systems with different dependencies




*provided only as a definition of the term
http://en.wikipedia.org/wiki/Narcissism

linux is possible to us today because of the greater linux community
thanks to all the good people
that were thoughtful to provide sources of their work
that could be built across many systems



Joe

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#4 Post by sc0ttman »

not sure anyone was being narcissistic... so anyway, you wanna provide more info on build scripts and how they can help people compile across different systems? That would be helpful to improve things a bit..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

User avatar
BarryK
Puppy Master
Posts: 9392
Joined: Mon 09 May 2005, 09:23
Location: Perth, Western Australia
Contact:

#5 Post by BarryK »

Hi, yes, this is a problem that I think about sometimes. Some thoughts, correct me if you think any of these generalizations are wrong or a bit off...

If it is a commandline application written in C, it most likely doesn't matter which version of Puppy you compile it on. If you compile it in Lucid, it should work in 431.
On the otherhand, an app written in C++ is much more sensitive to which version of libstdc++ it is compiled against, and going backwards or forwards may break the app.

Apart from the language and libc, there is the problem of shared libraries. Very generally, if you compile against older shared libraries, the app is more likely to work in a later Puppy, but less likely if you try the reverse.
So, some people compile apps in Puppy 431 or even earlier, for greatest possibility of it working in a later Puppy.

Personally, I am trying to use Quirky 1.3 or the upcoming 1.5, as that has fairly conservative library versions, for example GTK 2.16.6 (GTK is a prime example of where going back breaks the app). Yet, the library versions in Quirky are not very old, as that can also be a problem, with library API changes occurring in very old libraries.

So, I expect my apps compiled in Quirky to work fine in all recent "generation 5" puppies, such as Spup, Lucid and Wary, but I less likely in 431 and older.
[url]https://bkhome.org/news/[/url]

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#6 Post by sc0ttman »

Forgive me if I am talking nonsense, and my ideas are unrealistic, impractical or just plain unworkable.. But...

It would perhaps be nice if the newer devxs allowed users to use the oldest libs/dependencies available, and really nice if the oldest required versions could be detected before 'configure' and 'compile'...

Is it possible to include in the devx a set of older libs, stored away outside LD_LIBRARY_PATH, that can be used in a PATH variable (or CFLAGS, or whatever is used when compiling), whenever a build script or configure script finds them to be usable in the compiling process?

Example: a CLI bash script called 'check-min-build-deps' which runs some tests on the package to be compiled, and reports back the oldest versions of XX and YY required, and gives you a path variable to these (older) files, to be used when compiling - if, of course, they are stored away somewhere in the devx...

...

Or... even better (IMHO), an even more dynamic devx... I'd LOVE to have a devx, which temporarily symlinks in the oldest versions of the required compile dependencies, whenever the shell script 'check-min-build-deps' is run on a source dir or package..

.... I know that ttuuxxx manually adds lots of CFLAGS and what not into his configure and make commands, to reduce size, use GTK stock icons, etc... and I just wonder, if this process can be automated beforehand a little bit, by running a shell script on the package to be compiled...

Generally, I am thinking about (I guess!) a bigger devx, with support for older Pups built in, plus a generic 'build script' or setup script that helps locate and install (by symlinking to LD_LIBRARY_PATH) the oldest (most widely compatible) dependencies before compiling begins.

However, this all may be wasted thought, a I've no idea as to how to use BASH to retrieve the oldest required deps from a load of source files... And from the looks of things, many source packages seem to report information in their own way, making such a task a real hassle.
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

big_bass
Posts: 1740
Joined: Mon 13 Aug 2007, 12:21

#7 Post by big_bass »

All is possible but some things should be avoided
because they not only reinforce bad habits
that will hurt you when and if you decide to use a major distro
but they create problems that are very hard to track down
because packages are linked at compile time to different shared
libs and with different configure options that are not obvious
when installing a pre compiled binary packages from another distro


Thinking about magical binaries that work for every possible version
is a bad plan it also reinforces "mooching"
this isn't all that bad for a new user that doesn't write in bash code yet
and needs some packages to test out
but this practice leads to not being able to build correct packages
when needed

this is why build scripts build the package correctly
on the version you are running
I spent a lot of time setting up slackware compatabilty
(not to directly use their packages) but to be able to build them from scripts
maintaining perfect compatablity to the running system

about different compilers or multiple compilers this is also possible but leads to even more sticky problems to sort out when it comes to linking your shared libs

a quick summary if you want to supply packages to other users start out making simple build scripts for each package prebuilt packages
will only in therory work correctly on the system they were compiled on




Joe

User avatar
jemimah
Posts: 4307
Joined: Wed 26 Aug 2009, 19:56
Location: Tampa, FL
Contact:

#8 Post by jemimah »

sc0ttman wrote:Forgive me if I am talking nonsense, and my ideas are unrealistic, impractical or just plain unworkable.. But...
Sadly, this sort of thing does require real expertise. It's not easy to automate! Stuff like adding cflags and manually trimming unneeded things is a creative process and often needs a lot of trial and error - so does figuring out what versions of libraries will actually work with each other. Even getting things to compile statically can be a real challenge - a lot of packages are very stubborn.

Amigo's src2pkg is about the best it gets for automatic compiling.

Most newer programs won't build on 4.2 or 4.3.1 anymore. :(

muggins
Posts: 6724
Joined: Fri 20 Jan 2006, 10:44
Location: hobart

#9 Post by muggins »

Another factor is that backwards compatibility depends on what librarys the developer has used in getting their app to work. See the source for Turma2. It has 3 .c files & 2 includes, but I was unable to compile it on 4 series as it's using gtk2 function calls requiring a newer gtk2.

User avatar
technosaurus
Posts: 4853
Joined: Mon 19 May 2008, 01:24
Location: Blue Springs, MO
Contact:

#10 Post by technosaurus »

for novices to intermediate users you can try my pcompile GUI
www.murga-linux.com/puppy/viewtopic.php?p=320609
(I included useful cflags as of gcc-4.2 and some other options)

or src2pkg if it fails and are comfy in cli

there are always sweet spots for various packages, ... gtk-2.16.6, pango-1.24.5, xorg-7.3, samba-3.0.37, cups-1.3.11, etc... mostly recently from the end of 2009... we seem to be in the new feature part of the cycle still.

BTW autotools is the reason for a lot of the incompatibilty, to the point that I often replace pkgconfig files for gtk deps with a symlink to a "fixed" gtk*.pc ... just to keep the linker from adding functions from the deps into the binary's hash table.
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].

User avatar
Lobster
Official Crustacean
Posts: 15522
Joined: Wed 04 May 2005, 06:06
Location: Paradox Realm
Contact:

#11 Post by Lobster »

I did have a go with tmxxine photon to create a Puppy developer ISO. It only really worked on my machine . . .
http://www.mindmeister.com/78004/linux-tmxxine

As the devx is an SFS can we click on and use various versions of the devx with 'on the fly sfs' allowing multiple compiles with different devx?
That is likely not possible because different Puppys have different dependencies?

It may be too complex and having multiple frugall installs or virtualboxes might be more feasible?
Puppy Raspup 8.2Final 8)
Puppy Links Page http://www.smokey01.com/bruceb/puppy.html :D

User avatar
sc0ttman
Posts: 2812
Joined: Wed 16 Sep 2009, 05:44
Location: UK

#12 Post by sc0ttman »

technosaurus wrote:for novices to intermediate users you can try my pcompile GUI
www.murga-linux.com/puppy/viewtopic.php?p=320609
(I included useful cflags as of gcc-4.2 and some other options)

or src2pkg if it fails and are comfy in cli

there are always sweet spots for various packages, ... gtk-2.16.6, pango-1.24.5, xorg-7.3, samba-3.0.37, cups-1.3.11, etc... mostly recently from the end of 2009... we seem to be in the new feature part of the cycle still.

BTW autotools is the reason for a lot of the incompatibilty, to the point that I often replace pkgconfig files for gtk deps with a symlink to a "fixed" gtk*.pc ... just to keep the linker from adding functions from the deps into the binary's hash table.
I tried pcompile - very simple, easy to use... Also src2pkg, which I like a lot, athough it fails to build some things that can be done manually, for some reason, not clever enough to work out the specifics half the time...

I'd love to learn some of these sweet spots... Saw a few tables and a matrix thing, showing what worked well together, regarding gcc, glibc, etc..

I need to learn more about autoconf, linkers and pkgconfig... and more no doubt.. I came across errors with pkconfig reporting that my GTK DEV files do not matching the GTK version installed, even though I had installed the correct DEV PET package for my GTK version..
[b][url=https://bit.ly/2KjtxoD]Pkg[/url], [url=https://bit.ly/2U6dzxV]mdsh[/url], [url=https://bit.ly/2G49OE8]Woofy[/url], [url=http://goo.gl/bzBU1]Akita[/url], [url=http://goo.gl/SO5ug]VLC-GTK[/url], [url=https://tiny.cc/c2hnfz]Search[/url][/b]

Post Reply