LinuxQuestions.org
Welcome to the most active Linux Forum on the web.
Go Back   LinuxQuestions.org > Forums > Linux Forums > Linux - Software
User Name
Password
Linux - Software This forum is for Software issues.
Having a problem installing a new program? Want to know which application is best for the job? Post your question in this forum.

Notices


Reply
  Search this Thread
Old 12-25-2018, 03:11 PM   #1
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Rep: Reputation: Disabled
Executable compiled in 2008 does not run anymore


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

Last edited by Grabby; 12-25-2018 at 03:12 PM.
 
Old 12-25-2018, 03:35 PM   #2
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,674

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
Quote:
Originally Posted by Grabby View Post
I guess there is some kind of incompatibility between the compiled code and the latest Linux kernels, preventing the program to work.
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 command
Code:
strings <your-executable>|grep GLIBC
you can sometimes see for which version of glibc it was compiled.

Last edited by ehartman; 12-25-2018 at 03:39 PM.
 
1 members found this post helpful.
Old 12-25-2018, 03:41 PM   #3
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ehartman View Post
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.
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
 
Old 12-25-2018, 03:43 PM   #4
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ehartman View Post
With the command
Code:
strings <your-executable>|grep GLIBC
you can sometimes see for which version of glibc it was compiled.
I did it, and it only says: GLIBC_PRIVATE
 
Old 12-25-2018, 04:13 PM   #5
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,674

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
Quote:
Originally Posted by Grabby View Post
Thanks for your reply. Is there a way to tell a program to use an old library instead of the latest ones?
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.

Last edited by ehartman; 12-25-2018 at 04:19 PM.
 
Old 12-25-2018, 04:17 PM   #6
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,674

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
Quote:
Originally Posted by Grabby View Post
I did it, and it only says: GLIBC_PRIVATE
So it might not be glibc it's stumbling against but some other shared library.
What does
Code:
ldd <executable>
tell you about which shared libraries it uses?
 
Old 12-25-2018, 04:34 PM   #7
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by ehartman View Post
What does
Code:
ldd <executable>
tell you about which shared libraries it uses?
It says: not a dynamic executable
 
Old 12-25-2018, 04:44 PM   #8
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Original Poster
Rep: Reputation: Disabled
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)
 
Old 12-25-2018, 04:49 PM   #9
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 9,822

Rep: Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420
Can you run the Windows version in WINE?
 
Old 12-25-2018, 05:20 PM   #10
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Original Poster
Rep: Reputation: Disabled
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.
 
Old 12-25-2018, 05:24 PM   #11
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 9,822

Rep: Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420
You're thinking of LD_LIBRARY_PATH and LD_PRELOAD.
 
1 members found this post helpful.
Old 12-25-2018, 05:43 PM   #12
Grabby
Member
 
Registered: Feb 2016
Posts: 68

Original Poster
Rep: Reputation: Disabled
Quote:
Originally Posted by dugan View Post
You're thinking of LD_LIBRARY_PATH and LD_PRELOAD.
Would this allow me to define a specific set of libraries for a given program?
 
Old 12-25-2018, 06:00 PM   #13
dugan
LQ Guru
 
Registered: Nov 2003
Location: Canada
Distribution: distro hopper
Posts: 9,822

Rep: Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420Reputation: 4420
Yes.

Code:
LD_LIBRARY_PATH=/path/to/libraries/for/program ./program
 
1 members found this post helpful.
Old 12-25-2018, 10:17 PM   #14
ehartman
Senior Member
 
Registered: Jul 2007
Location: Delft, The Netherlands
Distribution: Slackware
Posts: 1,674

Rep: Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884Reputation: 884
Quote:
Originally Posted by Grabby View Post
Would this allow me to define a specific set of libraries for a given program?
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.

Last edited by ehartman; 12-25-2018 at 10:20 PM.
 
  


Reply

Tags
executables


Thread Tools Search this Thread
Search this Thread:

Advanced Search

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is Off
HTML code is Off



Similar Threads
Thread Thread Starter Forum Replies Last Post
Compiled program not showing up as compiled and not able to run. hjoshuaj Linux - Newbie 3 03-27-2014 05:49 AM
Why I cannot run the compiled executable in other pc? christyyim Linux - Newbie 5 12-23-2008 03:18 AM
version GLIBC_2.3 not found error when cross compiled executable is run on targert sateeshgalla Programming 3 05-14-2008 10:42 AM
Run executable file compiled by kylix and mysql in Fedora Core 4 aa_husni Fedora 0 09-15-2005 12:14 AM
Executable compiled w/gcc won't run brancheb Programming 5 05-16-2004 01:56 PM

LinuxQuestions.org > Forums > Linux Forums > Linux - Software

All times are GMT -5. The time now is 12:41 PM.

Main Menu
Advertisement
My LQ
Write for LQ
LinuxQuestions.org is looking for people interested in writing Editorials, Articles, Reviews, and more. If you'd like to contribute content, let us know.
Main Menu
Syndicate
RSS1  Latest Threads
RSS1  LQ News
Twitter: @linuxquestions
Open Source Consulting | Domain Registration