So I've recently been obsessed with this long dormant project known as ion1 and its first iteration (as its really debloated and very simplistic, later iterations included a lot of unnecessary lua scripting). Heres its Github repository;
https://github.com/apenwarr/ion1
On almost all my 32 bit machines it built perfectly fine however on all my 64 bit machines such as the one I'm on right now I recive this error;
Any help would be immensively appreciated. Best regards,
Thomas

The C language and its compiler have developed significantly since then (15 years ago) and the old compile recipes, maybe even the code itself, do not work anymore.
Maybe you can provide switches to gcc to work in some sort of backawards-compatibility mode.

Here's a search for the error: https://www.startpage.com/sp/search?...ith+array+type

Also see:
https://en.wikipedia.org/wiki/Ion_(window_manager)
https://tuomov.iki.fi/software/ion/

Thats true, however its odd how it works basically perfectly on rolling release 32 bit machines without error (e.g. void i686) especially since the compilers up to date on those. Could it be that it doesn't take account for 64 bit systems? Also good to see another startpage user

These are precompiled binaries. Check Void Linux (?) repositories and package listing web pages, maybe they have a recipe on how to compile it (I know ArchLinux provides this).

PS: if you manage to compile it I don't really see a reason why it shouldn't work for 64bit, too.

With due deference to any programmers helping you: If this is a 32bit app you're trying to run on 64bit, you may have the libraries problem. Libraries are not transferable, i.e. 32bit libs ≠ 64bit libs. Take /lib/ld-linux.so, which handles the basic I/O, and every program links against it. There can only be one /lib/ld-linux.so. If it's 32 bit, all 64 bit stuff is in trouble, and vice-versa.

Slackware & I believe Fedora get around this. Slackware uses /lib & /usr/lib for 32bit libs, and /lib64 & /usr/lib64 for 64bit. So there can be 2 ld-linux.so files. Every 64bit package is compiled "--with-libdir=/usr/lib64". GCC & Glibc are special concoctions. There's a special range of multilib packages. I haven't looked at Fedora in a long time.

Yeah that'd be correct if you were to use its recent fork notion or ion3 however the issues with the later releases it they add a lot of unnecessary lua bloat, whereas the experience in the first iteration though ancient is alltogether suckless.

I'm compiling this using a decomissioned sun so it has tons of rack space for extra hard drives. If I were to, say, compile on Slackware 15 and then transfer over the compiled image to an average 64 bit system (e.g. read over the make install directory transfers then copy them all into a data folder) would it work properly? I may not be a coder but perhaps I could also compare and contrast notions source code and ion1's source code and see what changes were made to make it work with modern 64 bit libraries

I understand that ion1 was a 32 bit app. It is quite common for difficulties to be encountered when trying to compile a 32 bit app for a 64 bit system. Especially one where the code has not been updated for many years.

In addition to the code itself, many included or linked libraries have changed dramatically or may not even be available on the 64 bit system. The compiler has also been updated a lot, so matching old code, old & new libraries, and old compiler & new compiler changes becomes difficult.

One thing you might try would be to load an OS from the same era as the source code for that app into a VM, then see what you may be able to achieve there first. It would not be the same as compiling it for a current OS, but is a thought on how to get it to work for you.

What?
You yourself said:
I thought you meant ion1 when you said "it" works perfectly on Void. In that case my statement stands: Look for a compile recipe.

So do Debian and Arch and, I believe, most distros nowadays.

Sounds like an idea however wouldnt it have issues if I moved the compilation to a 64 bit machine?

If you have a 64bit machine running a possibly vintage 32bit OS in a VM, not on x86_64 cpus. If you had a 64bit OS in the VM, you'd have big issues. Other scenarios I'd have to think.

Maybe in that case using an old core 2 duo thinkpad may bridge the gap

I don't understand this fixation on bitness.

All I see is a compile error, which is rather common when trying to compile old code on a new compiler.

But gcc has switches for backward compatibility, that's the direction I'd concentrate my efforts.

And again, didn't you say it (a compiled version I presume) works on Void? What recipe did they use to compile it???

Depending on where/when the code originated the author(s) mightn't even have conceived of 64 bits! Remember Dos with it's A20 handler? They were thinking 16 bits, which was big for the time.

The emphasis on bits comes from experience 32bitlibs ≠ 64 bit libs. Every program is linked to /lib/ld.so for basic I/O. But you can't have a 32bit & 64bit /lib/ld.so - a symlink has to point at one or the other. That's the issue.

Slackware & fedora solve thios by compiling --with-libdir=/usr/lib64 (or --prefix=/ --libdir=/lib64) so you have /lib64/ld.so(=64bit) & /lib/ld.so(32 bit). Slackware64 then has packages of 32bit compatability libs.

Debian and Arch also do this, and, I believe, most distros nowadays.

I won't contradict, but I'm surprised.