Recent

Author Topic: mint executable run on debian fails  (Read 6043 times)

MVT

  • Newbie
  • Posts: 3
mint executable run on debian fails
« on: January 24, 2022, 06:49:21 am »
I wrote a simple "hello world" console program using a new installation of Lazarus/FreePascal on my Linux Mint computer, where it runs fine.

I copied the executable to my Debian based openmediavault computer.

It would not run there... permission denied.

So I tried both chmod +x   and   chmod 777
both of which set the x bits.  Sill did not run.

I tried changing ownership of the file and the directory I had created to match the main user on my openmediavault machine, still did not run.
Then I changed ownership to root, and it did not run.
I tried running with sudo, still did not run.

Always the same error... permission denied.

I suspect I'm missing something simple... any help would be appreciated.

both machines are 64 bit

uname -a on the Mint machine:
Linux Elk 5.4.0-96-generic #109-Ubuntu SMP Wed Jam 12 16:49:16 UTC 2022 x86_64 x86_64 x86_64 GNU/Linux

uname -a on the openmediavault machine:
Linux Vault 4.19.0-0.bpo.5-amd64 #1 SMP Debian 4.19.37-3~bpo9+1 (2019-05-18) x86_64 GNU/Linux

I am logged into my openmediavault machine using SSH.

I do not wish to install Lazarus on the openmediavault computer, as I want it kept as clean as simple as possible.

Thaddy

  • Hero Member
  • *****
  • Posts: 14164
  • Probably until I exterminate Putin.
Re: mint executable run on debian fails
« Reply #1 on: January 24, 2022, 07:08:19 am »
If you compiled in 32 bit mode  then it may be that the second machine has no Multiarch support installed?
If that is the case, then:
1. Either install Multiarch. It is in de standard Debian libraries en also in the mint libraries.
2. Or compile with an fpc64 compiler or cross-compiler (ppcx64 or ppcrossx64)  <---- the recommended option!

Case in point is that for such a simple program, AFAICS it couldn't be any dependencies except for Multiarch.

See https://wiki.debian.org/Multiarch/HOWTO

Tested with
Code: Pascal  [Select][+][-]
  1. program hw;
  2. begin
  3. writeln('hello,world');
  4. end.
Compiled for 32 bit on a multiarch machine and copied to a debian64 machine (buster) w/o multiarch and presto, replicated!
« Last Edit: January 24, 2022, 02:56:24 pm by Thaddy »
Specialize a type, not a var.

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: mint executable run on debian fails
« Reply #2 on: January 24, 2022, 07:19:45 am »
Try the 'file' command on the binary, see what it tells us.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

Thaddy

  • Hero Member
  • *****
  • Posts: 14164
  • Probably until I exterminate Putin.
Re: mint executable run on debian fails
« Reply #3 on: January 24, 2022, 07:29:28 am »
Yes, forgot about that. file -s <executable file>
BTW - in case I diagnosed the issue correctly - the preferred option is of course compiling for 64 bit, to maintain the second machine's integrity. It seems setup as a server and a 64  bit server usually does not need a 32 bit subsystem installed. (Multiarch is rather big)
Debian core is phasing out 32 bit i386 anyway. 32 bit i386 support may not even be in Debian 12 (Bookwurm)
See: https://www.theregister.com/2021/01/14/debian_bullseye/
« Last Edit: January 24, 2022, 10:38:26 am by Thaddy »
Specialize a type, not a var.

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: mint executable run on debian fails
« Reply #4 on: January 24, 2022, 08:47:49 am »
Hmm, Multiarch is in bookworm now but that sure does not mean its going to be there in 18 months time, when they are thinking of a freeze. I guess it makes sense to consider dropping it. Sigh. I see about 10% to 20% of the downloads of my app as 32bit.

I most certainly agree that compiling for 64bit is preferable to installing multiarch on a server !

One other possibility, did you compile for PIE Hardening (ie with  -k-pie ) ?  Being a small, test app, it will be statically linked, and statically linked apps cannot be hardened.

See https://wiki.freepascal.org/hardening

EDIT: removed extra characters that I somehow added to above URL.

Davo
« Last Edit: January 24, 2022, 02:18:08 pm by dbannon »
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

Thaddy

  • Hero Member
  • *****
  • Posts: 14164
  • Probably until I exterminate Putin.
Re: mint executable run on debian fails
« Reply #5 on: January 24, 2022, 10:37:05 am »
Well, the problem is really that there is the suggestion that, although Multiarch may still be installable - after all it is a 64bit x86 package - , the i386 packackes may be fased out/only third-party supported. Note that ALL major flavors of Linux either have dropped i386 support already or have announced to do so, including Ubuntu, Mint and Manjaro and now Debian. The same goes for the non-Debian derivatives. It is time for fpc and lazarus to make 64 bit the default distribution on linux intel.
And I can see no problems since I use the combination of fpc x86_64 and Lazarus x86_64 for at least three years.
(But I always bootstrap it myself from source.)
LTS distributions will probably/likely adhere to the time-line they promised.

I wonder why you still use some many 32 bit, though. I am not discussing speed gains or addressable memory and such.
I am merely explaining that important players - that we need - focus on 64 bit development likely at the cost of the quality of 32 bit support..
« Last Edit: January 24, 2022, 10:47:38 am by Thaddy »
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: mint executable run on debian fails
« Reply #6 on: January 24, 2022, 12:00:49 pm »
Well, the problem is really that there is the suggestion that, although Multiarch may still be installable - after all it is a 64bit x86 package - , the i386 packackes may be fased out/only third-party supported. Note that ALL major flavors of Linux either have dropped i386 support already or have announced to do so, including Ubuntu, Mint and Manjaro and now Debian. The same goes for the non-Debian derivatives. It is time for fpc and lazarus to make 64 bit the default distribution on linux intel.
And I can see no problems since I use the combination of fpc x86_64 and Lazarus x86_64 for at least three years.
(But I always bootstrap it myself from source.)
LTS distributions will probably/likely adhere to the time-line they promised.

I'd be surprised if Debian dropped Multiarch, although 32-bit support doesn't get much love from anybody any more. That's basically down to Debian being as much a "meta-distro" as one intended for end users.

Having said which, I've seen very few downsides to making sure that sourcecode is 64-bit compatible even when also being maintained for older Linux and Linux on e.g. ARM, which in practice means using ptrint/ptruint where required.

One thing I found disappointing that that User Mode Linux, which was effectively the first shot at containerisation, would not support 32-bit guests on a 64-bit host. But that's pretty much history by now.

MarkMLl
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: mint executable run on debian fails
« Reply #8 on: January 24, 2022, 02:16:39 pm »
See https://wiki.freepascal.org/hardeningavo

I think you meant https://wiki.freepascal.org/hardening instead?

Sure do, I have no idea where the "avo" came form, it was a simple copy and paste !  Thanks, will edit.

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

Thaddy

  • Hero Member
  • *****
  • Posts: 14164
  • Probably until I exterminate Putin.
Re: mint executable run on debian fails
« Reply #9 on: January 24, 2022, 06:38:21 pm »
@trev
I regret that move, you should not have done that, since it is not operating system specific. It is the trend for all major desktop/phone OS's.
Windows does the same : dropping 32 bit. Apple has already done the same on:dropping 32 bit, Android does the same, so it is really a general question, although the discussion here focusses on Linux merely by accident ..... >:D >:D

Now you have made it way too specific. :o Horror.
All these OS's suffere or will suffer in the near future the same or nearly the same issue.
« Last Edit: January 24, 2022, 06:53:19 pm by Thaddy »
Specialize a type, not a var.

MVT

  • Newbie
  • Posts: 3
Re: mint executable run on debian fails
« Reply #10 on: January 24, 2022, 06:42:59 pm »
UPDATE ---

I ran file -s on my executable, and found this:

Test1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, stripped

So, it already is a 64 bit executable.  (The default Lazarus installation on 64-bit Linux Mint must be set to that.)

And, I still have the problem.  Any other ideas?

Thaddy

  • Hero Member
  • *****
  • Posts: 14164
  • Probably until I exterminate Putin.
Re: mint executable run on debian fails
« Reply #11 on: January 24, 2022, 06:58:02 pm »
No. Note that FPC does not officially package as 64 bit x86_64 AFAIK.
But I could reproduce the error: only with a 32 bit executable on a non-MutiArch server..
Specialize a type, not a var.

MarkMLl

  • Hero Member
  • *****
  • Posts: 6647
Re: mint executable run on debian fails
« Reply #12 on: January 24, 2022, 07:17:10 pm »
I ran file -s on my executable, and found this:

Test1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, stripped

So, it already is a 64 bit executable.  (The default Lazarus installation on 64-bit Linux Mint must be set to that.)

The only thing I can think of is that you're going to need to look very carefully at what libraries the program is expecting to be present and is linking to when it's pulled into memory (i.e. as distinct from libraries being linked to under program control).

I'm sure I've seen something like this on at least one occasion, and equally sure that I can't remember how I tackled it.

Something like this might help (noting that the binary is unstripped):

Code: [Select]
$ file -s zoasm-x86_64-linux
zoasm-x86_64-linux: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), dynamically linked, interpreter /lib64/ld-linux-x86-64.so.2, for GNU/Linux 2.4.0, BuildID[sha1]=0ffd59233d5806810535458276c6055c4392e602, with debug_info, not stripped

$ readelf -d zoasm-x86_64-linux | grep Shared
 0x0000000000000001 (NEEDED)             Shared library: [libpthread.so.0]
 0x0000000000000001 (NEEDED)             Shared library: [libdl.so.2]
 0x0000000000000001 (NEEDED)             Shared library: [libc.so.6]

A definite gotcha is that if a library name or path traverses a symlink this is fully-resolved at the time of linkage... I don't know whether there are any situations where that isn't true or if it's in any way controllable. The result of that is that Debian's symlinked library structure might be causing you problems:

Code: [Select]
lrwxrwxrwx   1 root root     7 Jun  8  2019 lib -> usr/lib
lrwxrwxrwx   1 root root     9 Jun  8  2019 lib32 -> usr/lib32
lrwxrwxrwx   1 root root     9 Jun  8  2019 lib64 -> usr/lib64
lrwxrwxrwx   1 root root    10 Jun  8  2019 libx32 -> usr/libx32

Another possible Debian-specific gotcha caused me to write this:

Code: Pascal  [Select][+][-]
  1. {$IFDEF UNIX }
  2.         if (GetLastOSError = 0) and (Pos(': invalid ELF header', LastError) > 0) then begin
  3.  
  4. (* I believe this is a Debian special: libusb-0.1 has been declared obsolete    *)
  5. (* and "replaced by a linker script, in the hope it will make everybody happy." *)
  6. (* The error message above might be subject to i18n, so users in non-English    *)
  7. (* speaking locales might have at least as much grief as I've just had. Blame   *)
  8. (* Aurelien Jarno :-)                                                           *)
  9. ...
  10.  

However I don't think you'll encounter that one unless you're doing program-controlled dynamic loading of an early libusb.

MarkMLl
« Last Edit: January 24, 2022, 07:32:54 pm by MarkMLl »
MT+86 & Turbo Pascal v1 on CCP/M-86, multitasking with LAN & graphics in 128Kb.
Pet hate: people who boast about the size and sophistication of their computer.
GitHub repositories: https://github.com/MarkMLl?tab=repositories

dbannon

  • Hero Member
  • *****
  • Posts: 2778
    • tomboy-ng, a rewrite of the classic Tomboy
Re: mint executable run on debian fails
« Reply #13 on: January 25, 2022, 01:03:50 am »
Test1: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, stripped

Code: Bash  [Select][+][-]
  1. dbannon@dell:~/Pascal/CLI$ fpc hello.pas
  2. Free Pascal Compiler version 3.2.0 [2020/06/14] for x86_64
  3. Copyright (c) 1993-2020 by Florian Klaempfl and others
  4. Target OS: Linux for x86-64
  5. Compiling hello.pas
  6. Linking hello
  7. 6 lines compiled, 0.1 sec
  8. dbannon@dell:~/Pascal/CLI$ file hello
  9. hello: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.4.0, stripped
  10. dbannon@dell:~/Pascal/CLI$ ./hello
  11. Hello

I have attached a gzip of my hello programme, please untar -

Code: [Select]
tar xzf hello.tgz <enter>
And try that one.

Will at least tell us which end the "something" is happening. Note my file command gives the same output as yours, my guess is my app will not run on your debian box either. Be interesting....

Davo
Lazarus 2, Linux (and reluctantly Win10, OSX)
My Project - https://github.com/tomboy-notes/tomboy-ng and my github - https://github.com/davidbannon

PascalDragon

  • Hero Member
  • *****
  • Posts: 5444
  • Compiler Developer
Re: mint executable run on debian fails
« Reply #14 on: January 25, 2022, 09:20:13 am »
See https://wiki.freepascal.org/hardeningavo

I think you meant https://wiki.freepascal.org/hardening instead?

Sure do, I have no idea where the "avo" came form, it was a simple copy and paste !  Thanks, will edit.

Davo

I think it came from you deleting your name signature or something like that, cause avo is after all the three last letters of Davo ;)

@trev
I regret that move, you should not have done that, since it is not operating system specific. It is the trend for all major desktop/phone OS's.
Windows does the same : dropping 32 bit. Apple has already done the same on:dropping 32 bit, Android does the same, so it is really a general question, although the discussion here focusses on Linux merely by accident ..... >:D >:D

While Microsoft is dropping support for 32-bit OS the support for 32-bit applications won't be gone any time soon, cause Microsoft is caring very much about backwards compatibility and many legacy applications are 32-bit only (even Visual Studio itself up to and including 2019 is 32-bit only!).

Also the move to the Linux forum is correct: this is about getting a Linux application working on a different Linux. This is not about getting a Linux application working on non-Linux or the other way round.

No. Note that FPC does not officially package as 64 bit x86_64 AFAIK.
But I could reproduce the error: only with a 32 bit executable on a non-MutiArch server..

Only for Windows x64 we don't provide a native compiler. All other x86_64 targets have native x86_64 distributions.

 

TinyPortal © 2005-2018