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 Sun 23 Nov 2014, 16:25
All times are UTC - 4
 Forum index » Taking the Puppy out for a walk » Suggestions
a standard compiling puppy
Moderators: Flash, Ian, JohnMurga
Post new topic   Reply to topic View previous topic :: View next topic
Page 1 of 1 [12 Posts]  
Author Message
sc0ttman


Joined: 16 Sep 2009
Posts: 2386
Location: UK

PostPosted: Sun 10 Apr 2011, 16:53    Post subject:  a standard compiling puppy
Subject description: it would be nice....
 

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


Joined: 11 Dec 2007
Posts: 1423
Location: somewhere at the end of rainbow...

PostPosted: Sun 10 Apr 2011, 17:48    Post subject:  

well said. Laughing

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
Quote:
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
Quote:
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”
* Independence from package management (RPM, DEB, TGZ, ...)
* No version mismatch between the executable and its auxiliary files
* No host-dependent side-effects: the application and the target host's software environment do not interfere with each other

Additional features

* An executable prepared on an x86 can run on x86_64 without 32-bit compatibility libraries.
* No need for root privileges at installation time
* Offers your users a pleasant experience with your application and decreases your installation support costs

All of these are explained in more detail on the Products and Features pages.
Windows Support

Ermine currently supports only Linux, but a similar product for Windows is available from BoxedApp.

_________________
replace .co.cc with .info to get access to stuff I posted in forum
dropbox 2GB free
OpenOffice for Puppy Linux
Back to top
View user's profile Send private message Visit poster's website 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Mon 11 Apr 2011, 13:17    Post subject:  

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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send private message 
sc0ttman


Joined: 16 Sep 2009
Posts: 2386
Location: UK

PostPosted: Mon 11 Apr 2011, 18:57    Post subject:  

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..
_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send private message 
BarryK
Puppy Master


Joined: 09 May 2005
Posts: 7082
Location: Perth, Western Australia

PostPosted: Mon 11 Apr 2011, 20:30    Post subject:  

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.

_________________
http://bkhome.org/news/
Back to top
View user's profile Send private message Visit poster's website 
sc0ttman


Joined: 16 Sep 2009
Posts: 2386
Location: UK

PostPosted: Thu 14 Apr 2011, 08:40    Post subject:  

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.

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send private message 
big_bass

Joined: 13 Aug 2007
Posts: 1747

PostPosted: Fri 15 Apr 2011, 14:27    Post subject:  

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

_________________
debian wheezy ,linux mint, slackware I use them all and they all have good points
Mint would be best for general users though
Back to top
View user's profile Send private message 
jemimah


Joined: 26 Aug 2009
Posts: 4309
Location: Tampa, FL

PostPosted: Thu 28 Apr 2011, 01:04    Post subject:  

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. Sad
Back to top
View user's profile Send private message Visit poster's website 
muggins

Joined: 20 Jan 2006
Posts: 6690
Location: lisbon

PostPosted: Fri 13 May 2011, 01:39    Post subject:  

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


Joined: 18 May 2008
Posts: 4376

PostPosted: Sat 21 May 2011, 00:24    Post subject:  

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.

_________________
Web Programming - Pet Packaging 100 & 101
Back to top
View user's profile Send private message 
Lobster
Official Crustacean


Joined: 04 May 2005
Posts: 15117
Location: Paradox Realm

PostPosted: Sat 21 May 2011, 00:55    Post subject:  

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 WIKI
Back to top
View user's profile Send private message Visit poster's website 
sc0ttman


Joined: 16 Sep 2009
Posts: 2386
Location: UK

PostPosted: Sun 22 May 2011, 06:31    Post subject:  

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

_________________
Akita Linux, VLC-GTK, Pup Search, Pup File Search
Back to top
View user's profile Send private message 
Display posts from previous:   Sort by:   
Page 1 of 1 [12 Posts]  
Post new topic   Reply to topic View previous topic :: View next topic
 Forum index » Taking the Puppy out for a walk » Suggestions
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.1070s ][ Queries: 12 (0.0041s) ][ GZIP on ]