Recent

Author Topic: Are linux .o files portable between versions of debian with same cpu?  (Read 525 times)

Чебурашка

  • Hero Member
  • *****
  • Posts: 568
  • СЛАВА УКРАЇНІ! / Slava Ukraïni!
Problem: given a fpc project that compiles and works using a "modern" fpc in recent debian 64 distribution, using same sources, create executable(s) or so-library(ies) also for some older debian distros both 32 and 64.

In my case situation is:

developing on deb 11.5 64 with fpc 3.2.0, must create exe/so also for deb 9 64, deb 9 32 and deb 6 32

NOTE: compiling on deb 11 64 and the copying exe on deb 9 64, does not work due to glibc version invalid, as observed also in other threads of the forum.

Therefore the more obvious solution was to recompile the source one the target distro. The big problem is that older debian distributions have older compiler that very soon stops compiling because of some newer constructs (generic, type helpers, ans so on). Using fpcupdeluxe I could compile fpc 3.2.0 in deb 9 (by chance backports include fpc 3.0.4, which is needed to compile 3.2.0), but it seems to me impossible to do the same on deb 6.

So I decided to try another way:

1. compile the pascal code in deb 11 64/fpc 3.2.0 with the option -s = stop before linking
2. copy the .o generated + link.res and ppas.sh on the target 64 machines
3. on target 64 machines, do sh ppas.sh
(same 1, 2, 3 for 32 bit)

I tried with a simple program that does not include so much things and after some fixing to the directories in the target machines that have a structure different from deb 11 (all resolved by means of symlinks), it links and works. Testing the real software is a little more complicated so I did not do yet.

Is this a senseful way or can create other problems (especially things that don't generate link time errors but eventually screw up the program execution)?


ERRATA CORRIGE:

I did not explain correclty that the operation is done "separately" on the two different architectures 32 and 64 bit.

PROCEDURE
0. develop on deb 11 64

1. compile the pascal code in deb 11 64/fpc 3.2.0 with the option -s = stop before linking (resulting .o supposed to be suitable for 64bit)
2. copy the .o generated + link.res and ppas.sh resulting from previous on the target 64 machines
3. on target 64 machines, do sh ppas.sh

4. copy project source code from deb 11 64 to debian 11 32bit and compile with fpc 3.2.0 with the option -s = stop before linking (resulting .o supposed to be suitable for 32bit)
5. copy the .o generated + link.res and ppas.sh resulting from previous on the target 32 machines
6. on target 32 machines, do sh ppas.sh
« Last Edit: May 04, 2023, 03:22:00 pm by Чебурашка »
FPC 3.2.0/Lazarus 2.0.10+dfsg-4+b2 on Debian 11.5
FPC 3.2.2/Lazarus 2.2.0 on Windows 10 Pro 21H2

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
In principle it is ok.  Bootstrapping is also done like this(*), but bootstrapping is usually the compiler binary that doesn't have library dependencies.

Over longer times, changes in as/ld, startup code and libraries might complicate this.  Linux is simply not guaranteed binary compatible with itself cross distro, cross version like Windows is (and even windows has minor caveats there)

Another potential problem is that the compiler might do runtime checks and adapt the generated ppas.sh and link.res to that.

(*) e.g. the some of the BSD ports were sometimes bootstrapped this way.

Чебурашка

  • Hero Member
  • *****
  • Posts: 568
  • СЛАВА УКРАЇНІ! / Slava Ukraïni!
In principle it is ok.  Bootstrapping is also done like this(*), but bootstrapping is usually the compiler binary that doesn't have library dependencies.

Over longer times, changes in as/ld, startup code and libraries might complicate this.  Linux is simply not guaranteed binary compatible with itself cross distro, cross version like Windows is (and even windows has minor caveats there)

Another potential problem is that the compiler might do runtime checks and adapt the generated ppas.sh and link.res to that.

(*) e.g. the some of the BSD ports were sometimes bootstrapped this way.

Thanks for the answer marcov... do you think any potential issue could come up at linking time with some message (i.e. I can notice it), or can it simply happen that the linker output is a non operating elf?
FPC 3.2.0/Lazarus 2.0.10+dfsg-4+b2 on Debian 11.5
FPC 3.2.2/Lazarus 2.2.0 on Windows 10 Pro 21H2

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11383
  • FPC developer.
If you use binutils (g)LD, as is usual, then the chances are great you get an error and no silent fail.

A special case is the game library SDL.

But as said, there is no guaranteed compatibility, so nothing is guaranteed in these cases.

I wouldn't ship cross-distro *nix binaries without testing them.

 

TinyPortal © 2005-2018