[Gllug] Mysql Configure problem

Nix nix at esperi.demon.co.uk
Fri Apr 18 21:37:21 UTC 2003


On Mon, 14 Apr 2003, Paul Nasrat stipulated:
> On Mon, Apr 14, 2003 at 11:28:33AM +0100, James Bailey wrote:
>  
>> > As a relatively new subscriber to this list, what kind of machine does
>> > Nix run?  The above conversation has left me mystified...
>> 
>> I _think_ he runs fairly standard hardware, he is however a _very_ scary C
>> hacker.  On the few occasions I have exchanged emails with on list regarding
> 
> Hmm, AFAIK *Nix runs a lot of sparc-32 and sparc-64 systems, both
> Solaris (with GNU userspace) and Linux.

While I've got some Solaris binaries and libs around to check
compatibility, the only Solaris boxes I use these days are at work. My
home net has a couple of SPARC/Linux boxes on it (32-bit userspace) and
a pile of variously cheap and aged Intel boxes.

>                                         Lots of NFS, bleeding edge

And how I wish intermezzo was usable enough that I could replace much of
the NFS with it. I don't think *anyone* who uses NFS heavily likes it.

> glibc and probably bleeding edge gcc.

On the GCC front, I've got installed binaries and source trees for
 - GCC-2.7.2.3 (to check for regressions quickly); not much used and may
   be discarded one of these days
 - egcs-2.92.11, likewise rarely used
 - gcc-2.95.4pre as of 2003-01-14
 - gcc-3.0.4
 - gcc-3.2.2 (the workhorse and default compiler)
 - gcc-3.3-branch, autorebuilt every four days
 - gcc-3.4 (the trunk), likewise autorebuilt
 - gcc-regalloc-branch, rebuilt whenever I need it
 - gcc-ssa-branch, rebuilt every two days (guess where I spend my time)

plus I do regression hunts with scripts from Janis Johnson that can do
dozens of builds of GCC while hunting down the date of introduction of a
bug by a (really slow) binary search.

All the builds, automatic or no, are done by scripts that queue up
builds until no other build is happening at the same time, optionally
autoinstall them if they introduce no new test failures, and allow me
to say `pause that build, I have one I'd rather you do *right now*'.

Most of those versions of GCC are actually *useful*, although I'll admit
that the amount of software I build with 2.95.4pre or the -ssa-branch is
negligible (the one is more a `dead stable baseline' for bug hunts, the
other is more for experimentation, and, well, for making work, to be
honest :) )


The bleeding-edge glibc is in a chroot; I'm not *that* much of a
risk-taker. :)

>                                       Linux system is built from
> scratch. [1]  

Since long before there were web pages to help ;)

> Maybe he should do a gllug talk on how to create a completely binary
> incompatible system in 3 easy steps :)

Oh, *that* is easy. Just swap around a couple of the registers in the C
function-calling convention --- changes to gcc/config/i386.md,
gcc/config/i386.c, and that's it (well except for GDB). But that just
makes sure you can't run anyone else's binaries; actually *improving*
the ABI is a little harder. And that ABI is horrible enough that
improving it is rewarding; my last tests (several years back) showed a
~5% speedup, and that's before GCC got onto cross-function optimizations
or proper inlining. I expect the improvement is a good bit more now.

> [1] Note this is just from memory of postings to this list

Remarkably accurate; you are to be congratulated for the degree of
attention you have paid to totally useless information ;)

-- 
`It is an unfortunate coincidence that the date locarchive.h was
 written (in hex) matches Ritchie's birthday (in octal).'
               -- Roland McGrath on the libc-alpha list

-- 
Gllug mailing list  -  Gllug at linux.co.uk
http://list.ftech.net/mailman/listinfo/gllug




More information about the GLLUG mailing list