ISVs providing Linux downloads [LWN.net]

ISVs providing Linux downloads

Posted Sep 14, 2012 16:55 UTC (Fri) by khim (subscriber, #9252)
In reply to: ISVs providing Linux downloads by sciurus
Parent article: Meeks: Linux on the (consumer) Desktop

Perl is in the same ballpark as PHP, Python, Ruby, TCL, PHP and other popular Linux scripting languages: totally incompatible between versions at the C ABI level. You can not even link two modules together in a single program if they use different versions of Perl!

The only sane way to use it is to never use it as a glue code and bundle one specific version of the interpreter with your application (this is how OpenOffice uses python on Windows, BTW). Now, what distribution developers think about this idea? Yeah, I've hear the howls, they are loud and clear.

No, Perl is very much part of the problem, not part of the solution. It (like bazillion other things in Linux) is created with the assumption that you can “recompile the world”.

(Log in to post comments)

ISVs providing Linux downloads

Posted Sep 15, 2012 17:31 UTC (Sat) by khim (subscriber, #9252) [Link]

I think you have missed one small yet vital letter. I'll highlight: totally incompatible between versions at the C A⇒B⇐I level. ABI, not API. Here we go:
$ objdump -T /usr/lib/libtcl8.[45].so.0 | grep 'g DF' | cut -b 62- | sort | uniq -d | head _fini _init Tcl_Access Tcl_AddErrorInfo Tcl_AddInterpResolvers TclAddLiteralObj Tcl_AddObjErrorInfo Tcl_AlertNotifier Tcl_Alloc TclAllocateFreeObjects $ objdump -T /usr/lib/libtcl8.[45].so.0 | grep 'g DF' | cut -b 62- | sort | uniq -d | wc -l 639

You can not easily use TCL in any library or plugin because of that. If one plugin will use TCL 8.4 and another plugin will use TCL 8.5 you'll have Russian Roulette: it may work for sime time, but nobody can predict when (and if!) it'll kill you.

Note that even Microsoft is guilty: .NET framework 1.x is totally incompatible with .NET framework 2.x. Thankfully they quickly dropped this insane idea and .NET frameworks 3.x were built on top of the CLR 2. .NET frameworks 4.x use different (and incompatible!) runtimes, but you can use in-process side-by-side hosting to run multiple versions of the CLR in a single process.

Sure, you can do with TCL using some tricks with dlopen and some recompileable shims (nVidia does this even with Linux kernel ABI which is infamous for it's instability!), but… this is not something TCL authors propose and support. They push for the same tried and found wanting "recompile the world" approach.

ISVs providing Linux downloads

Posted Sep 15, 2012 17:52 UTC (Sat) by anselm (subscriber, #2796) [Link]

I suggest you read up on »Tcl stubs«, which is a feature that was introduced in Tcl 8.1 especially to make Tcl extensions in C usable with different (notably future) versions of Tcl.

I used to do a lot of C-level programming with Tcl and this proved to be a very valuable feature because you didn't have to recompile your extensions whenever a new Tcl version came out. So no, you don't need to »recompile the world«, and indeed that is not something the Tcl authors recommend – they recommend using stubs instead so your extensions will be compatible with future Tcl versions without recompilation. In other words, you're wrong.

ISVs providing Linux downloads

Posted Sep 15, 2012 18:39 UTC (Sat) by khim (subscriber, #9252) [Link]

Thanks you for the pointer. I take my words back.

Yes, Tcl stubs is about what's needed for the stable ABI. So we have at least one scripting language whose authors are serious about compatibility.

Now we need to convince developers of extensions to use this mechanism, but this is indeed a good start.

Too bad the Tcl itself is not all that popular. And there is also the unfortunate fact that distributions often don't use Tcl stubs but link with one single version of Tcl directly - but yes, in this particular case authors of the language did their part.

ISVs providing Linux downloads

Posted Sep 16, 2012 13:31 UTC (Sun) by anselm (subscriber, #2796) [Link]

Tcl/Tk – once you get used to it – is much better than its reputation would suggest (Sun would have been able to make a difference when John Ousterhout was at Sunlabs but by that time they had another language to hype).

As it is, Tcl/Tk remains one of the better-kept secrets of the industry; lots of people use it as a work horse but it isn't as »hip« as some of the other languages in the same space – even though it is very well engineered and documented and has been quite innovative in lots of areas. For example, Tcl offered full Unicode support with the release of Tcl 8.1 in 1997, way before any of the other popular languages followed suit, and of course Tk revolutionised X11 GUIs in the early 1990s when everyone else's idea of GUI programming involved C and OSF/Motif. Tcl/Tk can do things like cross-platform single-file deployment that are very helpful and simply not available with most other similar languages. Too bad it doesn't get the attention it deserves.