OpenSmalltalk
OLD_1002_ATTRIBUTE and VM_TARGET_OS
The function getAttributeString() in sqUnixMain.c has, since end of March 2025, a C preprocessor (cpp) variable OLD_1002_ATTRIBUTE.
When set, the old code that returns VM_TARGET_OS is used.
If not set, the function will do a malloc() and allocate space from the heap to store the platform dependent results from uname() as defined by the operating system in <sys/utsname.h>.
This is in commit e6108a0cd .
VM_TARGET_OS is set by the configure script from $ac_cv_target I think $target_os is from the GNU autoconf target=$ac_cv_target
The function getAttributeString() in sqUnixMain.c has, since end of March 2025, a C preprocessor (cpp) variable OLD_1002_ATTRIBUTE.
When set, the old code that returns VM_TARGET_OS is used.
If not set, the function will do a malloc() and allocate space from the heap to store the platform dependent results from uname() as defined by the operating system in <sys/utsname.h>.
This is in commit e6108a0 .
Thank you David. I must have made some mistake in that new code. I think it is the right idea but I must have implemented it incorrectly. If you ca review it please do. I'll see what I can find.
I think this is fixed with 28712a36aa2a818cd932701d21cd4a60f4d10b4e. Please review.
Why do you prefer an implementation based on uname() at runtime, please ? The code in the past was using a GNU configure implementation at build time (compile time) when VM_TARGET_OS was computed by the GNU configure script, and not by the sqUnixMain.c file at runtime. Anyway this issue is not urgent for me, as you provided a OLD_1002_ATTRIBUTE workaround so the GNU configure based implementation can be selected by setting OLD_1002_ATTRIBUTE . However the name "OLD_1002_ATTRIBUTE " suggests you'd like to migrate to a new approach by using uname() and a runtime computation ... I'll close this issue for now as I'm fine with whatever you prefer, it's just that I was surprised by the change.
Why do you prefer an implementation based on uname() at runtime, please ? The code in the past was using a GNU configure implementation at build time (compile time) when VM_TARGET_OS was computed by the GNU configure script, and not by the sqUnixMain.c file at runtime.
For consistency with the other major platforms, macOS and Windows. On those platforms vm attribute 2002 answers the version of the current OS, /not/ the OS on which the VM was built. Having information on the underlying OS is much more important (e.g. selecting the correct name of the libc library file when using qsort) than info on where the VM was built (which can be inferred from other info).
But initially in #713 I thought you said that there was no change related to UNIX, which is contradicted by the modification of sqUnixMain.c. If you have clear ideas about why you want to make such a change, you can always please clearly indicate this in the git history. I am reopening this issue, because perhaps the "configure" script could be modified to automatically set OLD_1002_ATTRIBUTE. Or perhaps the code could be written in such a way that there is a DO_NOT_USE_AUTOCONF_FOR_1002_ATTRIBUTE which can be set to not use the GNU autoconfigure code for VM_TARGET_OS ?
I was wrong to say it didn't touch unix. I didn't see that what I thought was a trivial change was in fact capable of crashing the VM. However, I do think it is a needed change. Can we just accept that and move on? The fixed code is good right?
the new code is not equivalent to the code that is enabled by setting OLD_1002_ATTRIBUTE
on the squeak wiki the getSystemAttribute is documented at
https://wiki.squeak.org/squeak/314
"1002 - specific OS type: "linux-gnu" or whatever 'configure' provides as host_os on unix"
the GNU autoconf configure helps to support various Unix and Linux operating systems and distributions with slight differences; the VM_TARGET_OS reports what configure defined.
the new code is not equivalent to the code that is enabled by setting OLD_1002_ATTRIBUTE
I know and that’s by design. As I said before the old way doesn’t agree with the other platforms and isn’t useful.
on the squeak wiki the getSystemAttribute is documented at
https://wiki.squeak.org/squeak/314
"1002 - specific OS type: "linux-gnu" or whatever 'configure' provides as host_os on unix"
That says that 1002 should reflect the host is not the build os, which is what the new code does. Right?
the GNU autoconf configure helps to support various Unix and Linux operating systems and distributions with slight differences; the VM_TARGET_OS reports what configure defined.
tested on openSUSE Linux Leap 15.4 and Leap 15.6 on AMD Ryzen 7 cpu : if OLD_1002_ATTRIBUTE=1 you get something like linux-gnu as defined by configure if OLD_1002_ATTRIBUTE is not set, then "Linux 5.14.21 ..." for openSUSE 15.4 and "Linux 6.4.0 ..." for openSUSE 15.6 It depends on whether users of the osVersion message want to have both system identified as "linux-gnu" or whether they need a specific kernel version. Perhaps the getSystemAttribute mechanism can it be extended please for new attributes like 1010,1011,1012 for the various individual fields of uname utsname structure ? The utsname structure may have additional info and fields such as domainname.
I am not convinced this change is an improvement.
If I test on Linux OpenSUSE Tumbleweed (Linux on AMD64), I changed the code to break down the uname() structure utsname in individual system attributes so that:
Smalltalk getSystemAttribute:1010
could return the value 'Linux' and
Smalltalk getSystemAttribute:1011
could return the value '6.14.2-1-default' (the field release in the struct utsname).
Smalltalk getSystemAttribute:1002
would still return 'linux-gnu' as it was before and as provided by the GNU configure script at build time.
In any case, the strcat() concatenation can be done in the Smalltalk image using Smalltalk code where two system attributes can be used to create a new object by manipulating other system attributes objects in Smalltalk code.
Also looking at the C code, it seems that in the case of uname() returning a negative value, it currently returns VM_TARGET_OS while a failure of uname() is some sort of exception or error where it is not possible to determine the running operating system.
I’m open to adding additional system attribute numbers but only if they also make sense on other platforms. But I still think (strongly) that the intent of 1002 is to answer something informing of the underlying host OS, not the build environment. So fir me it is definitely an improvement over the previous hardwired value.
The idea of additional system attributes was just to keep the original 1002 definition. If the new definition is based on uname(2) then that definition will replace the old 1002 definition for Unix in platforms/unix/vm/sqUnixMain.c.
I checked the source code of traditional Squeak VM Classic (which is using "cmake" for builds) and there VM_HOST_OS is returned for getSystemAttribute:1002. This is most likely the same value as VM_TARGET_OS because both build systems use GNU config.guess to determine the OS. For build,target,host there are differences possible if ./configure --host, --build or --target options are used, for cross compiles, but in most cases the values will be the same. The new definition with uname() provides different return values, that differ from the old definition. For example on Solaris the old return value of Smalltalk osVersion was "solaris2.11" while the new return value is "SunOS 5.11".
I am also surprised that the platforms/unix/vm/sqUnixMain.c file is modified because Unix is the main platform from my perspective.
So from my perspective, I do not understand the change.
You mention that you are interested in using qsort() in libc or in a different library.
Having information on the underlying OS is much more important (e.g. selecting the correct name of the libc library file when using qsort) than info on where the VM was built (which can be inferred from other info).
But qsort() is a function that could be checked on GNU autoconf with the autoheader utility from autoconf ,
configure.ac
AC_CONFIG_HEADERS([config.h])
AC_CHECK_LIB(c,qsort)
AC_CHECK_FUNCS(qsort)
AC_CONFIG_FILES([Makefile])
AC_OUTPUT
using the autoconf support for checking which library defines qsort(), autoheader would define a config.h.in file:
/* config.h.in. Generated from configure.ac by autoheader. */
/* Define to 1 if you have the `c' library (-lc). */
#undef HAVE_LIBC
/* Define to 1 if you have the `qsort' function. */
#undef HAVE_QSORT
The config.h file could then #define HAVE_QSORT 1
and LIBS would have the -libc or different library if required.
So basically using GNU configure and autoconf, automake, autoheader and those autotools is a possibility for the qsort() application that you mentioned.
I admit that configure and autotools is complicated, but the benefit is the support for other platforms so the definition of Smalltalk osVersion in terms of "configure" makes sense from that perspective.
One has to remember that quite a lot of these things were added many, many, years ago and sometimes in a bit of a rush. This occasionally leads to confusion, chaos, and platforms not agreeing on what it means to frobble or grimbulate.
It seems pretty clear to me that asking for the host OS is asking for the OS you are currently running on rather than what OS was used to compile the code. After all, in cases where a cross-compiler was used you could end up with a Raspberry Pi VM claiming to be on Windows! Shudder.
OK for crosscompiling VM_HOST_OS was changed to VM_TARGET_OS.
That happened a few years ago in OpenSmalltalk commit 7c1614a06eb16d3d479d324bc343ce9a9dedde15.
But in both cases VM_HOST_OS or VM_TARGET_OS it's config.guess output.
The script config.guess from GNU autoconf is also using "uname" :
UNAME_MACHINE=`(uname -m) 2>/dev/null` || UNAME_MACHINE=unknown
UNAME_RELEASE=`(uname -r) 2>/dev/null` || UNAME_RELEASE=unknown
UNAME_SYSTEM=`(uname -s) 2>/dev/null` || UNAME_SYSTEM=unknown
UNAME_VERSION=`(uname -v) 2>/dev/null` || UNAME_VERSION=unknown
and it is doing additional processing in the shell script.
So originally the computation was in a higher level language (the shell script from the build system).
In the case of OpenSmalltalk-VM being built on Solaris (UNIX) (or on some Linux distributions that I tried) the old code that reported VM_TARGET_OS was more or less correctly reporting the operating system when sending the Smalltalk osVersion message.
One way to look at it is that the value is "hardcoded" (or hardwired) but another way to look at this, is that the value is dynamically computed by the build system.