Tcl Source Code

I'm not a big fan of executing external programs. Aside from security implications, output formats can change between different versions of the program or even between different localized platforms for the same version (at least on Windows, not sure about Linux/Unix).

I suspect the regexp will also fail for alternative Linux runtimes like musl.

Since `platform::identify` on Linux seems to mean the glibc version, would an alternative solution be to include the result of `gnu_get_libc_version` in the `tcl::build-info` and pick up the value from there? (Of course under __GLIBC__ conditional, "unknown" otherwise.)

`tcl::build-info` is meant for information about how Tcl was built. The runtime glibc version doesn't belong there. But it could be added as a ::tcl::unsupported command, picked up by platform::identify if available (giving 'unknown' when not available).

How about [c70ad78618832726|this]?

Thinking about it, I doubt the usefulness of the glibc version number in the identity. It would be more useful to just detect glibc vs musl vs unknown. Applications compiled for musl won't run on glibc-based linux and reverse, so that's useful to detect here.

Since platform::identity is broken already for a long time (always returning *-unknown-*), I doubt it's worth to make it more elaborate than this.

I tried this on Alpine Linux: It doesn't work yet, because "ldd --version" writes to stderr in stead of stdout. This can be handled, but isn't done yet in this branch.

The only use I have personally found for platform::identify is to distribute multiplatform packages on Windows with the shared libraries under the subdirectories as returned by platform::identify. I don't know if this kind of installation also makes sense for platforms other than Windows but if so, would there be compatibility issues by removing the version?

Other than that, not competent enough to comment.

> would there be compatibility issues by removing the version?

I don't expect so, since this has been broken a long time, just returning linux-unknown-${cpu} for a long time. No-one reported this.

For Linux I expect the same usage as you describe for Windows. It would be possible to make subdirectories for every possible value of platform::identity. If we have the glibc version number in it, it would mean the user has to create shared libraries for every possible version of glibc. I don't think that's usefull.

Anyway, I now committed the fix to trunk. It now works for Linux (either 'glibc', 'musl' or 'unknown'). If it causes problems, please report it!

@tomkiti. Are you providing binaries for glibc 2.39, 2.40, 2.41, 2.42, 2.43 .... ? Would it be possible to produce a binary for glibc 2.38 (for example) and store it in a directory linux-glibc-x86_64 in addition to linux-glibc2.38-x86_64? This binary should work with higher glibc versions as well, isn't it?

I realize this is a change, but since glibc versions change twice a year I don't think it's reasonable to provide a binary for so many different glibc versions.

Thanks! I'll revisit this after my vacation

The `platform::patterns` problem should be fixed [aa19237f0855e463|here]

Still having a further look ....

Are you going to remove the glibc version number? If so, I'll have to maintain my own version of platform.tcl forever because I depend on it.

Platform-1.1 has been broken a long time, always giving linux-unknown-$cpu, and it never worked on musl. Also glibc 2.x is always upwards compatible. So, applications compiled with an older glibc 2.x version always works fine on a newer glibc 2.x version. Therefore - the solution is to always compile applications/extensions against the oldest glibc version you want to support.

So, how about upwards/backwards compatibility. I propose to add the linux-glibc-$cpu and linux-unknown-$cpu directories to platform-1.1.2. This way, those directories can always be found, and you can simply place your binary in "linux-glibc-$cpu", without the need for further version numbers. If you still want to support older platform versions, just create a link from the linux-glibc-$cpu directory to linux-glibc?.?-$cpu directory (where ?.? stands for the oldest glibc version you support).

This way, you have the choice to stick with platform-1.1.x or switch to platform-1.2.x, this directory structure will continue to work with both. I won't backport platform-1.2.x to Tcl 9.0, in order to give more time to make the switch.

In short: The "linux-unknown-$cpu" is meant for extensions with statically linked libc (could be glibc, musl or any other). "linux-glibc-$cpu" is meant for linking against glibc, "linux-musl-$cpu" is meant for linking against musl. Note that platform-1.1 won't work with musl at all.

Hope this helps, Jan Nijtmans

Just as a demo, this is what "tclsh platform.tcl" gives on latest Linux (WSL).

I don't think this is reasonable any more:

====================================
tcl_platform(byteOrder)     = littleEndian
tcl_platform(engine)        = Tcl
tcl_platform(machine)       = x86_64
tcl_platform(os)            = Linux
tcl_platform(osVersion)     = 6.18.35.2-microsoft-standard-WSL2
tcl_platform(pathSeparator) = :
tcl_platform(platform)      = unix
tcl_platform(pointerSize)   = 8
tcl_platform(user)          = jan
tcl_platform(wordSize)      = 8
====================================
Generic identification: linux-x86_64
Exact identification:   linux-glibc2.43-x86_64
====================================
Search patterns:
* linux-glibc2.43-x86_64
* linux-glibc2.42-x86_64
* linux-glibc2.41-x86_64
* linux-glibc2.40-x86_64
* linux-glibc2.39-x86_64
* linux-glibc2.38-x86_64
* linux-glibc2.37-x86_64
* linux-glibc2.36-x86_64
* linux-glibc2.35-x86_64
* linux-glibc2.34-x86_64
* linux-glibc2.33-x86_64
* linux-glibc2.32-x86_64
* linux-glibc2.31-x86_64
* linux-glibc2.30-x86_64
* linux-glibc2.29-x86_64
* linux-glibc2.28-x86_64
* linux-glibc2.27-x86_64
* linux-glibc2.26-x86_64
* linux-glibc2.25-x86_64
* linux-glibc2.24-x86_64
* linux-glibc2.23-x86_64
* linux-glibc2.22-x86_64
* linux-glibc2.21-x86_64
* linux-glibc2.20-x86_64
* linux-glibc2.19-x86_64
* linux-glibc2.18-x86_64
* linux-glibc2.17-x86_64
* linux-glibc2.16-x86_64
* linux-glibc2.15-x86_64
* linux-glibc2.14-x86_64
* linux-glibc2.13-x86_64
* linux-glibc2.12-x86_64
* linux-glibc2.11-x86_64
* linux-glibc2.10-x86_64
* linux-glibc2.9-x86_64
* linux-glibc2.8-x86_64
* linux-glibc2.7-x86_64
* linux-glibc2.6-x86_64
* linux-glibc2.5-x86_64
* linux-glibc2.4-x86_64
* linux-glibc2.3-x86_64
* linux-glibc2.2-x86_64
* linux-glibc2.1-x86_64
* linux-glibc2.0-x86_64
* linux-glibc-x86_64
* linux-unknown-x86_64
* tcl
====================================

The biweekly telco of today has agreed to remove the glibc version from the choices for 9.1. Any comments to this, please speak up here.

Thanks for all, Harald