[Starkit] Mandrake 7.2 tclkits

[Jean-Claude Wippler]

Tom Poindexter wrote:

> Perhaps QEMU to the rescue?

Good point.  Thanks, I use vmware extensively an it itself it really  
is a great system.  It turns out that the past of least resistance  
for me right now is to simply keep it going and work around the  
trouble spots here (its NFS can't deal with my setup, don't ask...).

So for now, I have a n "md72" build again.

(BTW, Jeff / Andreas, how do you guys deal with this in ActiveState's  
basekits?)

> JC, what is your recipe for building the static Linux tclkits?  Is  
> there
> a genkit.local file you use?   Please post.

Genkit has partial support for fully static builds.  If you do "sh  
genkit B all" you end up with the proper binaries in "install/ 
$hostname/{kit,kitlite}".  I think it's just a matter of  
concatenating runtime-tk.kit at the end and it should all work.  I  
stopped going the fully-static route when glibc started dyn-loading  
things are runtime anyway (for locales & X11 input methods, IIRC).

The md72 build is a hack from a couple of years ago.  It is based on  
two scripts, in an "alt-md72" subdir next to src/ and tars/ - I use  
them as follows:
	cd alt-md72
	sh M.sh                 <-- does the main work
	tclkit Mfinish.tcl	<-- generates .gz and upx variants
The latter script can be done on another system.  Not sure what other  
assumptions these scripts make.

I'll attach them if anyone wants to look into it.  Note that this  
predates - and is completely independent of - genkit.

>> Rhetorical question: could there be some Linux distro out there which
>> is specifically designed to produce binaries which can be used on a
>> maximum number of platforms?  If not, why not?  Does no one else on
>> this planet deploy non-trivial binaries for Linux?
>
> Amen.  I happened to speak to a GCC developer a while back about this
> situation, especially the problem of statically linking libstdc++.  He
> seemed to indicate that the developers of libc and libstdc++ are of a
> mindset "why would you ever want to statically link?", and are not
> persuaded to provide such capability by our pleas.

These developers have never deployed full apps, I guess.

I recently sent out a detailed email about the whole issue to someone  
who might be in a position to change things, but have not heard  
anything since.  It looks like there are only three ways to deal with  
this:
	- muddle along, as we've been doing for a few years now
	- collect a large set of build variants
	- get tclkit into all linux distro's
All seem losing battles to me.  The latter fails when tclkit builds  
are rejected because of the binary data involved (it's not an all- 
from-source build, neither are Haskell / Common Lisp but somehow they  
seem to get accepted anyway).  Debian is one distro which does not  
appear to accept anything that is not fully source code AFAIK (not  
sure that's an important one for our purposes).

-jcw

PS.  I've uploaded new Mandrake 7.2 (md72) and Ubuntu 5.10 (u510)  
builds.  The Ubuntu one uses gcc4, so it's actually ahead in  
versioning of all the others - but it might be useful anyway.  Steve  
Landers submitted a Redhat 7.3 (rh73) build (thx!).  I'll be happy to  
collect and post more builds for the 8.4.13 series, and will move  
things to a more permanent spot on the website when I have some  
time.  For now, see http://www.equi4.com/pub/tk/newer/

-------------- next part --------------
A non-text attachment was scrubbed...
Name: M.sh
Type: application/octet-stream
Size: 2966 bytes
Desc: not available
Url : http://www.equi4.com/pipermail/starkit/attachments/20060425/637f6d79/M.obj
-------------- next part --------------
  
-------------- next part --------------
A non-text attachment was scrubbed...
Name: Mfinish.tcl
Type: application/octet-stream
Size: 357 bytes
Desc: not available
Url : http://www.equi4.com/pipermail/starkit/attachments/20060425/637f6d79/Mfinish.obj