[Gambas-user] gb3: unable to compile on Debian Wheezy (testing)

[Bruce Bruen]

On Wed, 2011-10-05 at 01:19 -0400, Kevin Fishburne wrote:
> 
> In the interest of getting work done and facing the future of desktop 
> environments, I came to a painful decision and have switched to Kubuntu 
> 11.10. I decided that Debian Wheezy was insufficiently maintained for 
> stability and that GNOME had become a tragic dead end with the 
> abandonment of the 2.x branch and the pure crap that is the 3.x branch. 
> That left me with KDE and Xfce as my only options, and loving 
> customization and beauty I chose KDE.
> 
> Hopefully the Debian or Mint team will get this mess sorted out so gb3 
> can compile without hacks. Thanks for the help anyway, and for anyone 
> else who sees GNOME as the walking dead, I highly recommend Kubuntu or 
> any other well-supported KDE distribution. I should have done this a 
> long time ago.
> 
I feel your pain but it has sparked my interest following both your and
Demosthenes Koptsis posts. I think that there are a few issues here that
I may be able to offer some helpful comments on.

Firstly, I don't know if you know, but there are a couple of things that
you should know.  These are the Linux Standards Base (also known as LSB)
and the File System Heirarchy (also known as FSH). The latter, which is
incorporated in the LSB, defines where and how "things" should be
installed in linux so that other "things2" know where to find them. One
of the important "things2" in this case is the GNU toolchain.  That is,
the C(++) compiler and linker, etc (etc being a whole bunch of other
tools that are used to make creating a program executable simple and
straightforward) so that all developers everywhere can reasonably expect
to be able to provide a source tarball (or svn or git or whatever) that
will compile and link regardless of the target environment.

(Sadly, after the kernel.org hack much of this documentation is not
readily available at the moment.  But when it is back I encourage you to
find it, get a good red wine and relax and browse through it.  It is
very enlightening and very well thought out.)

Secondly, and this is probably emotive but here goes anyway, most
"responsible" distros adhere to the LSB to a very high degree.  There is
one though that follows the "be reasonable, do it my way*" approach.
(* my way being the one I** decide today)
(** "I" being any one of a multitude of undisciplined code whackers)
I won't name it, but let's just say that it might just rhyme with
"voodoo".

According to the LSB (and the FSH) developers ought to expect that all
linkable libraries (static or dynamic) should reside in /lib
or /usr/lib. Nowhere else, not in /usr/lib/fred, nor /usr/lib/fredx64,
nor /usr/lib/fred_x_6pence_and_a_farthing. (There is a caveat here,
which is that the linker will allow you to override a library location
specifically during a single run by using special arguments.  This is so
that the library developer can link in "experimental" versions of a
library while they are testing it. This not meant for people trying to
link to published stable versions of the library.)

Now. (FANFARE!) There is a generally "perceived" problem with the
current hardware mix of 32bit and 64bit architectures.  I won't go in to
them here beyond saying there is at least 20000 wasted blogger-years out
there on the internet and to say that it is "perceived" because it only
exists in the mind of the media.  It doesn't matter if the machine
architecture is 64 bit, 32 bit, 127bit or 6.02 times 10^23 bit, the
library that is compiled for the architecture should reside in /lib
or /usr/lib. (For dog's sake, even Windows went through this argument
somewhere back in the 14th century when they introduced .. can't
remember .. something that jammed a 16bit call into a 12bit stack .. or
something entirely useless like that anyway.)  

The point is, linkable libraries should be in /lib or /usr/lib.

Or at least referable in /lib or /usr/lib ...

Which brings me to links, symbolic or hard.  (I am going to presume that
you know about these things, what they are and why they work.)  The
reason I proposed to Demosthenes that he create the links
between /usr/lib and whatever the strange directory his libfree files
resided in was that it gets around the problem neatly and succinctly.
In fact it is a commonly used method to allow linking (toolchain linker
linking) to a specific version of a library.  If you look at /usr/lib
you will find many examples of this, such as /usr/lib/psylocibin.so is
actually a symbolic link to /usr/lib/psylocybin-a.3.6417.so (or
whatever, if you've followed me so far you'll know what I mean).
Similarly, the links to psylocibin.la and other things follow the same
pattern.

Now here is the bit that I don't understand. libfreetype has been around
since the dinosaurs started feeling a bit chilly.  It's about as stable
as granite. I have diffed the latest version, all the files (.la .a
and .so and the source) they are all the same, no matter whether they
are the 32 bit version or the 64 bit version.  So why some eedjit has
decided to put the 64 bit versions of all these things in some obscure
directory and then not provide the proper links in /usr/lib is entirely
beyond me, but that's voodoo for you.

But by the way, it's not Debian. They provide a proper (source) package
that goes to the proper (/usr/lib) place. I know - I just "make'd" it.

As for mint, well that's just a "voodoo chile".

By the way, Kevin, try LXDE. You may just like it, it's both pretty and
pretty simple (and then there'd be two of us hassling Benoit :-) ).

cheers
Bruce