Hi

I am not able to run an executable ELF file that was compiled in 2008. Unfortunately this is a closed source program, which I downloaded from here:
https://sites.google.com/site/sbcarc...inux.amd64.zip

When run from the command line, the program (an archiver) starts normally and displays the available options, but when attempting to create an archive, an error message is displayed, telling the user that there is a problem with the memory/cache.

My OS is Manjaro 18, running on a latest generation laptop powered with an i7 CPU and 16 GB of RAM, so this is not a matter of insufficient hardware resources.

I guess there is some kind of incompatibility between the compiled code and the latest Linux kernels, preventing the program to work.
Incidentally, I have also tried to run this program on a 10-year old laptop running on Manjaro 17, and I encounter the same problem. That is why I don't think this is a hardware incompatibility issue but a software one.

Does anyone know how to solve this issue and get the program to run normally?

Note: the copyright date displayed when running the program says 2002, but this particular modified version of the program was recompiled by the author in 2008.

Thank you in advance,

Grabby

Probably not the kernel as "normal" programs do not have much interaction with the kernel, but with the shared libraries, especially the C library (of which the later versions aren't at all that compatible anymore with i.e. glibc 2.0).
One of the things which happened after 2.0 was making library calls "thread safe", which resulted in more and different types of arguments to certain functions.
Current version of glibc is something like 2.28 and without relinking the program against newer libraries you probably won't be able to get it to run anymore.
Try creating a Virtual Machine (VirtualBox or such) with IN the VM an old enough release of Linux (and its shared libraries) so that the program can still run with it.

With the commandyou can sometimes see for which version of glibc it was compiled.

1 members found this post helpful.

Thanks for your reply. Is there a way to tell a program to use an old library instead of the latest ones? Running the program in a VM would be too much of a hassle for me, and it would not be worth the effort.
Any solution that does not require running a VM?
Thanks

I did it, and it only says: GLIBC_PRIVATE

Sometimes yes, when the library CALL is versioned (that is: the program is looking for lib<library>.so.<major_version>, but normally not for glibc as they all are called through the symbolic link "libc.so.6" and changing that link will break most of the rest of your system as glibc is used by almost all of the executables and THEY will have been compiled for the newer version.
The libraries lib.so.5 (older ELF format. pre 1999) and libc.so.4 (a.out format) aren't around anymore.
By the way: glibc 2.1 (the thread-safe mod) has been around since 1999 and i.e. 2.3 since 2002. The C library is re-released normally every 6 months but as long as the interfaces do not change older compiled programs will still run.

So it might not be glibc it's stumbling against but some other shared library.
What doestell you about which shared libraries it uses?

It says: not a dynamic executable

I don't know if this may help, but among other things the executable file contains these strings:

/lib64/
/usr/lib64/
/etc/ld.so.cache
search cache=%s
ld.so-1.7.0
glibc-ld.so.cache1.1
dl-cache.c
cache != ((void *)0)
_dl_load_cache_lookup
dl-lookup.c
do-lookup.h

../sysdeps/x86_64/dl-machine.h

../sysdeps/unix/sysv/linux/dl-origin.c

GCC: (GNU) 4.2.1 (SUSE Linux)

Can you run the Windows version in WINE?

I've just tried and it runs in WINE (thanks dugan!), so this partly solves my problem, although I was looking for some Linux-native solution.

I remember reading somewhere that there are Linux distros that allow you to set custom environment variables for each program, so you could define that a program uses a particular library instead of the standard one. In other words, the system-wide settings can be overridden on a per-program basis. If I am not mistaken it was NixOS, but I am not sure.

You're thinking of LD_LIBRARY_PATH and LD_PRELOAD.

1 members found this post helpful.

Would this allow me to define a specific set of libraries for a given program?

Yes.

1 members found this post helpful.

Not in this case as it's not a dynamic application, using shared libraries, according to ldd so every way it runs, it will keep on using its internally compiled-in (static) functions.
Probably this was done because even then this 2002 program couldn't work with the shared libraries present in a 2008 release of Linux, so the builder may have used a still older release to compile this static executable.