i'm having many many build stops building qupzilla-1.8.0 on a "pure GNU system" (unhacked by distributors), and think i'll have to skip plugins (apparently build will allow it)

missing headers galore. ie: uses c++ hacked by redhat "sort()" ummm class. but never includes header for any class at all: yes qupzilla cannot build on even a working "all version compatible" system: its broken right in the code so it CAN NEVER compile (1.8.0)

half of it sint' qupzilla's fault: it's "not Quick Time quick time" (free qt that apple does not support). they are insuring that only a small minor release version change means all software that had worked: now fails cannot build. (ie, parse errors in user interface script parsing, dead stop)

cmake wont allow me to use CFLAGS ... cannot auto build without line editing ".pro" files which are a qmake hack. gughgh. and it doesnt find simple things either.

i was really hoping qupzilla would break the "not linux mozilla , now firefox by gov grant funded mozilla copr." trend. not be coded in "one version only" language, not be full of errors, not be full of features that'd make a "large corp. happy" linux would fail.

i can't say so. qupzilla has been a pain in the _ss. (not as much as gdk/gtk, nothing is or can be as bad as that)

problems and fixes:

(1) many missing #include <foo.h> i think the developer used "an IDE" which tampers with the C programming process. PROBLEM: if the ide "helps you" it means you can't put GPL on your code because YOU DONT HAVE ALL OF YOUR CODE. you dont have what the ide was "fooling with". that part is "lost" and you cant distribute what you never had.

(2) linux distributors. they often have a hand in hacking everything away from "original developer defaults" (in any given version differently too) so that when a developer "thinks they are linking with a lib" they are linking to the libs "NON-DEFAULTS". the lib may be on another path and be diffucult or not even have (orig pkg) what the developer is "thinks everyone has"

rule of thumb: if it works on your "big distro" linux: assume your release is totally hacked and will not work when others attempt to compile it

solution: use automake "make distclean". it wont lie to you hardly

solution 2: follow the rules of the C programming language, it will always work for decades on end, for libs: see below. (where distro hacked things, C will have missing files, etc, etc)

if your "distributor" uses PGP keys, blocks anyone who voices out negative opinions, blocks certain users from uploading SOFTWARE while enabling others to "be admins and hack other peoples code": there's a good chance your distributor is practically a terrorist: it's MALWARE.

(2) linux distros. promote ignoring Sun Microsystems Unix (and ibm and other) "library rules" and compatibility seeking. some distros are infact malware (were not but are today), promote breakage and compatibility woes: they dont fix it they are FORCING others to do it.

minor versions should NEVER cause a compatibility failure (not one that prevents application loading and use), a newer version always fully supports previous.

IMPORTANT: a person running a newer app on an older lib should also not fail. the app should always test "feature additions" of a lib before assuming they are there.

IMPORTANT: the OS IS NOT SUPPOSED TO automatically prevent an app from loading if version is lesser: rather it is the APPS responsibility to "look before they step" (check interfaces during runtime, disable buttons as needed). MORE GRACEFULLY THAN A QUEEN.

major versions SHOULD support as much of past versions as possible perhaps fully, but ultimately the

note: when i find a "fix" for older software to compile it tends to work across many versions. new software? sometimes not even the same version when options change. code is just getting terrible.

its a very bad habbit these days of "demanding libs of same version". also: old apps used to load binary patches that came with app (they didn't ALWAYS use operating system runtime library if it was code for their app they were loading: no need for that mess)

and again: you shouldnt compile your app for "version 5.9" if your app is only using "5.2" capabilities: "that's just upping the ante", even "5" is wrong perhaps "4" is better; the least lib needed is correct (NOTE: distros have made this extremely difficult, and many simpoly are too lazy). old libs SHOULD be fixed and become bullet proof. they had been. distributors telling you "only the current one matters?" they are just going to steal code and insure even the author cannot use it IN THE FUTURE, since only they have the keys to what breaks.

(3) c++ is malware. first thing hackers did is cause changes so that STL failed in ALL EXISTING c++ code everywhere. then it was input/output. now they're practically code terrorists: c++ code works only for the version of c++ used.

The C programming language, C gcc, (asm too, gas), supports C versions 1 and 2. it's all you need it does absolutely everything you only have to read Kernigan and Ritchie C book. There isn't anything possible you need that C version 2 cannot do.

c++ is a monster of incompatibility and demands. but at it's best it's bad: type "helping" templates. the more information you give it about types the more it wants: but it makes bad code at assembler level. in C all that trash is far EASIER and one has ACTUAL CONTROL of what goes on.

i have an app i wrote myself in c++ and my problem is getting c++ out. the classes ARE TOTALLY USELESS AND HARMFUL. they never added the "lingual ability" a macro could have due to many limitations: but also bad things happen, like 3x copies of certain objects, and c++ becoming a terrorist / malware tool. it bottlenecked my app from going to the next level and must be C. i dont know if i'll ever have the time to convert it to C (sob).

thank goodness Linux Torvals suggested using C straight down code and i kept that in mind, and had seen advice from so many others

----------------------------
it's simple. use C (or asm) version 1 or 2. assume nothing in your distro is "real" (your users wont have it), assume it must be done somehow. your code will have no problems.

use automake to build: others will have an easy time installing/uninstalling and become aware if their "rad system" is missing something essential you app uses.

or a good script language that has no compatibility issues hounding and demanding upgrade for features

briefly: if you wand bullet proof code that last for centuries

use C version 1 or 2: there really is NOT anything C cannot do

your code will survive, your users will be happy, and have no problem if they choose to run on "a fully sourced system"

or use a good scripting language that isn't malware (i'll only say mathematica or mathcad (noting either may become malware), or bc, and not try to say who is naughty or nice). no i have no idea if java became malware when, sorry. one mention is Intel x86 32bit emulator with isa/pci support bochs: if it works in that (some hw issues aside), it always will and also a good deal of real hardware (unlike 64 where no silicon feature is for sure supported even by same maker).

libs are a good idea if maintained by saints. otherwise: if you need X11R6 to do a widget, use motif (something rock solid) or just cut and paste code from another app. relying on "a lib in a linux distro": will only work when you try it, it's malware hacked, it'll never work for others.

need an X11 wrapper lib? no you dont. just cut and paste code that works from an app that does it, make sure you have the whole widget. it's not that hard! X11 does absolutely everything necessary for graphics. sound? well open source "big free distros" removed sound (.au) support from X11. but alsa seems not to be malware today (i could be wrong i dont know, it just works i'm happy).

full multimedia? really are forced to use (apple, microsoft, intel, ...) and it's quite possible reason linux has ornary multimedia is that all the malware in linux is: injected by these poisoners. there are some how much (if a little or almost wholey, todays linux distros) cannot say, sorry.

i remember when software (mosaic?) had buttons "load module" "disable module". specifically the software had such to save users from unnecessary "features" in memory (bloat) and also compatibility issues. "only give users the headaches they ask for and not until they ask for them" -jh

any code can be a bug, unecessary bloat, or be a compatibility issue. good software defers "libs" till after givin gthe user an interface with preferences, and allows about anything to be loaded or disabled (not accessible, not in memory, not active).