OpenSmalltalk
sqUnixDragDrop.c missing a declaration of fileRecordSize()
sqUnixDragDrop.c fails to build due to a missing declaration of fileRecordSize()
Error log
clang -Wall -g -O2 -DNDEBUG -DDEBUGVM=0 -msse2 -DCOGMTVM=0 -pthread -DLSB_FIRST=1 -m64 -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -I/usr/include -I/usr/include -DHAVE_CONFIG_H -DSQUEAK_BUILTIN_PLUGIN -I/home/faith/tmp/build/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build -I/home/faith/tmp/build/opensmalltalk-vm/building/linux64x64/squeak.cog.spur/build -I/home/faith/tmp/build/opensmalltalk-vm/platforms/unix/vm -I/home/faith/tmp/build/opensmalltalk-vm/platforms/Cross/vm -I/home/faith/tmp/build/opensmalltalk-vm/src/spur64.cog -I/usr/local/include -I/home/faith/tmp/build/opensmalltalk-vm/platforms/Cross/plugins/DropPlugin -m64 -Wno-missing-braces -Wno-unknown-pragmas -Wno-unused-value -Wno-unused-label -Wno-unused-function -Wno-unused-variable -Wno-unused-but-set-variable -I/usr/include -I/usr/include -I/home/faith/tmp/build/opensmalltalk-vm/platforms/Cross/plugins/FilePlugin -c -o sqUnixDragDrop.o /home/faith/tmp/build/opensmalltalk-vm/platforms/unix/plugins/DropPlugin/sqUnixDragDrop.c
/home/faith/tmp/build/opensmalltalk-vm/platforms/unix/plugins/DropPlugin/sqUnixDragDrop.c:120:66: error: call to undeclared function 'fileRecordSize'; ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
120 | sqInt handle = instantiateClassindexableSize(classByteArray(), fileRecordSize());
| ^
1 error generated.
When building on Debian Linux 12.6 using the Debian build essentials tools + libx11-dev there is a warning in dropRequestFileHandle for an undeclared function fileRecordSize(). However the build continues in that case and the function seems defined in the TEXT segment of FilePlugin.o and undefined in DropPlugin.o. The VM from VMMaker.oscog-eem.3424 seems to work. Also when building on OpenIndiana (UNIX with the Illumos kernel, that is, not on Linux) using gcc 13.3 there is also a warning on fileRecordSize() being undeclared but the VM works. Because I read a different report , are you using Fails to compile on EndeavourOS #685 is this on ArchLinux, Fedora clang/gcc ? I can confirm that I have also seen some build failures during the last weeks with some code cleanup in OpenSmalltalk (for example in sqUnixMain.c) so maybe you could to reproduce the issue by trying a clean new build ?
Yes, I am doing this on ArchLinux. It looks like the compilers have become less tolerant of undeclared functions.
Note the following in the output:
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Clean new build still fails at this point.
Handwave a decade or so back I instigated the need for this, please submitted a git pull request to resolve
Sent from Proton Mail for iOS
On Sun, Aug 18, 2024 at 22:25, Kirtai via Vm-dev @.***(mailto:On Sun, Aug 18, 2024 at 22:25, Kirtai via Vm-dev < wrote:
Yes, I am doing this on ArchLinux. It looks like the compilers have become less tolerant of undeclared functions.
Note the following in the output:
ISO C99 and later do not support implicit function declarations [-Wimplicit-function-declaration]
Clean new build still fails at this point.
— Reply to this email directly, view it on GitHub, or unsubscribe. You are receiving this because you are subscribed to this thread.Message ID: @.***>
During the last weeks or months (since May I think) I've had some build failures due to code cleanup or changes in the opensmalltalk-vm sources. These sources are partly generated by the VMMaker tool so for example the code for FilePlugin or DropPlugin is partly automatically generated (as indicated by the VMMaker header notice). In some cases it is perhaps a solution to use the binaries from the squeak.org website instead of compiling a vm binary yourself.
I am seeing exactly the same issue on the latest commit on Ubuntu 24. Is this a result of the version of clang that I am using? building/linux64x64/HowToBuild does not mention the installation of clang at all so I just did sudo apt install clang which installed
Ubuntu clang version 18.1.3 (1ubuntu1)
Target: x86_64-pc-linux-gnu
Thread model: posix
InstalledDir: /usr/bin
Is a different version required?
The code in sqUnixDragDrop.c emits a warning (implicit function declaration, which was not considered as an error by the C language for the last 50 years or so) but which may be considered by some recent C compilers as an error.
For example the GCC 14.2 compiler is dealing with those warnings as errors now.
https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors
The difficulty is perhaps also here to find the author or maintainer of the DropPlugin.
There is a copyright message "(c) 1996 2004 Ian Piumarta".
Somebody also wrote a comment in the file sqUnixDragDrop.c : "why on earth does this plugin exist at all ??"
So a workaround may be to edit the file plugins.int in the "building" directory and remove the DropPlugin from the file : plugins.int
If you skip the DropPlugin build the file sqUnixDrapDrop.c will not be compiled.
For some C compilers, such as the Sun Microsystems/Oracle C Studio compiler, the implicit function declaration is just a warning, and the DropPlugin builds succesfully.
Hi Christoph,On Apr 7, 2025, at 1:47 PM, Christoph Thiede via Vm-dev @.***> wrote: I am seeing exactly the same issue on the latest commit on Ubuntu 24. Is this a result of the version of clang that I am using? building/linux64x64/HowToBuild does not mention the installation of clang at all so I just did sudo apt install clang which installed Ubuntu clang version 18.1.3 (1ubuntu1) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin
Is a different version required?—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
LinqLover left a comment (OpenSmalltalk/opensmalltalk-vm#693) I am seeing exactly the same issue on the latest commit on Ubuntu 24. Is this a result of the version of clang that I am using? building/linux64x64/HowToBuild does not mention the installation of clang at all so I just did sudo apt install clang which installed Ubuntu clang version 18.1.3 (1ubuntu1) Target: x86_64-pc-linux-gnu Thread model: posix InstalledDir: /usr/bin
Is a different version required?
I’m currently trying to finish the port to Windows arm64. I’m using clang 18 and MSVC Community 2022 edition. I think I’m seeing a compiler bug with clang 18 but have yet to narrow it down. The symptom is a crash half way through running the test suite due to the hash field of Array not being manipulated correctly after segment storage (segment storage uses hash fields to build a map from object to object-in-segment which is undone on return from the primitive).If possible I would use clang 14 for now. I hope to be able to report the bug in clang 18 (& determine when it was introduced) soon. I’ll update vm-dev asap.,,,^..^,,, (phone)
Isn’t hasn’t been involved for some time. Let me ask you to submit a fix yourself. It’s only supplying a suitable declaration and/or including the relevant header file.,,,^..^,,, (phone)On Apr 8, 2025, at 11:14 AM, dcstes via Vm-dev @.> wrote: The code in sqUnixDragDrop.c emits a warning (implicit function declaration, which was not considered as an error by the C language for the last 50 years or so) but which may be considered by some recent C compilers as an error. For example the GCC 14.2 compiler is dealing with those warnings as errors now. https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors The difficulty is perhaps also here to find the author or maintainer of the DropPlugin. There is a copyright message "(c) 1996 2004 Ian Piumarta". Somebody also wrote a comment in the file sqUnixDragDrop.c : "why on earth does this plugin exist at all ??" So a workaround may be to edit the file plugins.int in the "building" directory and remove the DropPlugin from the file : plugins.int If you skip the DropPlugin build the file sqUnixDrapDrop.c will not be compiled. For some C compilers, such as the Sun Microsystems/Oracle C Studio compiler, the implicit function declaration is just a warning, and the DropPlugin builds succesfully.—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.>
dcstes left a comment (OpenSmalltalk/opensmalltalk-vm#693) The code in sqUnixDragDrop.c emits a warning (implicit function declaration, which was not considered as an error by the C language for the last 50 years or so) but which may be considered by some recent C compilers as an error. For example the GCC 14.2 compiler is dealing with those warnings as errors now. https://gcc.gnu.org/gcc-14/porting_to.html#warnings-as-errors The difficulty is perhaps also here to find the author or maintainer of the DropPlugin. There is a copyright message "(c) 1996 2004 Ian Piumarta". Somebody also wrote a comment in the file sqUnixDragDrop.c : "why on earth does this plugin exist at all ??" So a workaround may be to edit the file plugins.int in the "building" directory and remove the DropPlugin from the file : plugins.int If you skip the DropPlugin build the file sqUnixDrapDrop.c will not be compiled. For some C compilers, such as the Sun Microsystems/Oracle C Studio compiler, the implicit function declaration is just a warning, and the DropPlugin builds succesfully.
—Reply to this email directly, view it on GitHub, or unsubscribe.You are receiving this because you are subscribed to this thread.Message ID: @.***>
Fixing the warning for this particular case will however not fix the warning at other locations of the source code where also implicit function declarations are being used.
There is indeed a warning at line 143 'implicit function declaration' in sqUnixDragDrop.c of the (optional) DropPlugin.
But this has been the case for a long time. And it does not fail the build on for example Solaris with Sun C Studio C compiler.
In the case of GCC 14.2 it requires (now) -Werror=implicit-function-declaration or -fpermissive
@LinqLover is it possible to change operating system ?
Instead of using Ubuntu 24 , you could use something like Debian Bookworm stable 12.0 or an older version of Ubuntu ? This will use an older version of the C compiler and also an older version of autoconf such as autoconf 2.69.
https://packages.debian.org/bookworm/autoconf2.69
The autoconf / automake / pkg-config generated script in platforms/unix/config is maintained on autoconf 2.69 if I'm not mistaken.
@LinqLover can you check the results in Ubuntu 20 or Ubuntu 22 ?
For example Ubuntu focal (20.04 LTS) : https://packages.ubuntu.com/focal/autoconf
or Ubuntu jammy (22.04 LTS) : https://packages.ubuntu.com/jammy/autoconf
You may have less problems with a build on "focal" with clang 10 the version of clang with focal : https://packages.ubuntu.com/focal/clang
Eliot recommended clang 14 and in that case Ubuntu 22.04 could be used because it looks like Ubuntu 22.04 comes with clang 14.
It may be possible to setup a VMMaker environment on Ubuntu 20.04 (which is now out of support or nearly out of support), but it may be possible to generate new sources on Ubuntu 20.04 that compile on platforms such as Ubuntu 22 or Ubuntu 24 or on ArchLinux using a VMMaker environment on Ubuntu 20.04 ...
The advantage of something like Ubuntu 20.04 is likely that it will be easier to "make configure" in platforms/unix/config using automake/autoconf/pkg-config because the autoconf versions of more recent Linux or UNIX distributions are ahead of what is currently in the OpenSmalltalk repository (based on autoconf 2.69) from Debian 12.0 I think.
Hi David,
On Wed, Apr 9, 2025 at 10:51 AM dcstes @.***> wrote:
Eliot recommended clang 14 and in that case Ubuntu 22.04 could be used because it looks like Ubuntu 22.04 comes with clang 14.
It may be possible to setup a VMMaker environment on Ubuntu 20.04 (which is now out of support or nearly out of support), but it may be possible to generate new sources on Ubuntu 20.04 that compile on platforms such as Ubuntu 22 or Ubuntu 24 or on ArchLinux using a VMMaker environment on Ubuntu 20.04 ...
The advantage of something like Ubuntu 20.04 is likely that it will be easier to "make configure" in platforms/unix/config using automake/autoconf/pkg-config because the autoconf versions of more recent Linux or UNIX distributions are ahead of what is currently in the OpenSmalltalk repository (based on autoconf 2.69) from Debian 12.0 I think.
— Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/693#issuecomment-2790508622, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY5VUH3WLJM4TB7FPX6JCL2YVM27AVCNFSM6AAAAAB2USGQ6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJQGUYDQNRSGI . You are receiving this because you commented.Message ID: @.***> dcstes left a comment (OpenSmalltalk/opensmalltalk-vm#693) https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/693#issuecomment-2790508622
Eliot recommended clang 14 and in that case Ubuntu 22.04 could be used because it looks like Ubuntu 22.04 comes with clang 14.
It's not that I recommend clang 14 so much as that we know clang 14 compiles the VM correctly. I'm investigating a bug with clang 18, and my hope is that a) it will turn out to be a clang bug, and b) that the clang maintainers will fix the issue.
It may be possible to setup a VMMaker environment on Ubuntu 20.04 (which is now out of support or nearly out of support), but it may be possible to generate new sources on Ubuntu 20.04 that compile on platforms such as Ubuntu 22 or Ubuntu 24 or on ArchLinux using a VMMaker environment on Ubuntu 20.04 ...
I feel strongly that generating sources outside of the opensmalltalk-vm repository is for personal use only. For general use one should use the opensmalltalk-vm repository. If changes are needed to get the system to compile on different platforms then those fixes should be integrated into the main branch. Having different versions for different platforms, or worse still, having different generated sources, leads in the direction of unmaintainability and forking. That's the last thing we should want.
The advantage of something like Ubuntu 20.04 is likely that it will be
easier to "make configure" in platforms/unix/config using automake/autoconf/pkg-config because the autoconf versions of more recent Linux or UNIX distributions are ahead of what is currently in the OpenSmalltalk repository (based on autoconf 2.69) from Debian 12.0 I think.
— Reply to this email directly, view it on GitHub https://github.com/OpenSmalltalk/opensmalltalk-vm/issues/693#issuecomment-2790508622, or unsubscribe https://github.com/notifications/unsubscribe-auth/ADY5VUH3WLJM4TB7FPX6JCL2YVM27AVCNFSM6AAAAAB2USGQ6OVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDOOJQGUYDQNRSGI . You are receiving this because you commented.Message ID: @.***>
-- ,,,^..^,,, best, Eliot
Thanks for your pointers! Confirming that it works with clang 14 for us and we are now happily building and running VMs. Unfortunately, I don't have an older Ubuntu version at hand right now. When staying at clang 14, it might be helpful to note this in the documentation - it took us some time to figure out why it worked on CI but not on our machines until we discovered the CI is still using Ubuntu 20. :-)
I hope that Ubuntu 18 and Ubuntu 20 are supported by OpenSmalltalk.
It's actually a good thing if CI is using Ubuntu 20.
Ubuntu 20 will have development tools like automake, autoconf , pkg-config, openssl, libffi various supporting libraries and c compiler of specific version.
Anyway this particular issue (for DropPlugin) is an example of a more general issue (not a bug) which I opened : issue #712
In the case of DropPlugin the workaround could be simply to skip compile/build of DropPlugin by editing plugins.int and removing the line "DropPlugin".
So far as I can tell my xubuntu-box is running ubuntu 20.0.4 -
uname -a
Linux gravious 5.15.0-134-generic #145~20.04.1-Ubuntu SMP Mon Feb 17 13:27:16 UTC 2025 x86_64 x86_64 x86_64 GNU/Linux
Squeak runs perfectly well on it.
I hope that Ubuntu 18 and Ubuntu 20 are supported by OpenSmalltalk.
We should be clear about this. There is no official support for any platform. The opensmalltalk-vm is a community effort. While I am remunerated for working on the opensmalltalk-vm, that remuneration is to further the goals of the companies kind enough to pay for my services, and not specifically for supporting the opensmalltalk-vm for any Smalltalk-centric community on any platform.
So while the opensmalltalk-vm is available on several platforms, and it is desirable to make opensmalltalk-vm available on as many useful platforms as possible, there is no guarantee of support on any platform.
That said, I do strive to be supportive of community members who do want to if necessary port and then maintain opensmalltalk-vm on any commodity platform. I certainly have no interest in frustrating such efforts.
So David, as it has been said, “if it is to be it is up to me”. If you want opensmalltalk-vm on Ubuntu 18 or any other, you will have to do the work. I will help you with information and fixes as I am able, but the only guarantee will come from your own commitment.
@LinqLover is using the "wrong" version of Ubuntu. Christoph Tiede wrote about using Ubuntu 24 and not having access to Ubuntu 20. However this contradicts the fact that "the CI is still using Ubuntu 20", so if the CI is still using Ubuntu 20 then fortunately @LinqLover has access to a "good" version of Ubuntu, namely Ubuntu 20 on the CI. I think that the goal is to have support for Ubuntu 24, but that can be done by development on Ubuntu 20. For example fixing "implicit function declaration" can be done on Ubuntu 20 and does not require Ubuntu 24. Ubuntu 24 could be used to check a version of opensmalltak-vm that is being developed on Ubuntu 20.