login_tty and openpty are cause of broken .deb installs

[robert rozee]

(the below is specific to Lazarus version 3.6 on x86 64-bit linux systems, but likely also applies to i386 (32-bit) as well as some other architectures)

current builds of the Lazarus IDE make use of the two libc functions login_tty and openpty that appear to have been explicitly versioned to do not exist prior to glibc 2.34:

Code: Pascal  [Select][+][-]

1. user@user-DH61BE:~/Downloads/Lazarus FPC/laz/usr/bin$ readelf --dyn-syms -W lazarus-ide | grep GLIBC | grep -v "2.2.5"
2.    409: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND login_tty@GLIBC_2.34 (3)
3.    915: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openpty@GLIBC_2.34 (3)
4. user@user-DH61BE:~/Downloads/Lazarus FPC/laz/usr/bin$

yet all other libc functions are versioned to glibc 2.2.5.

as far as i can determine, the presence of calls to (and use of) these functions render the Lazarus IDE incapable (without modification) of being built on or run on any x86 64-bit linux system using a version of glibc prior to 2.34, thereby breaking the ability - using the IDE - to build ELF binaries compatible with older systems (glibc prior to 2.34). note that this should not prevent the use of lazbuild to build ELF binaries on/for older systems, as it is only lazarus-ide that actually makes use of the two functions.

the presence of these two libc calls in the source code is why folks who download the .deb packages are unable to run the Lazarus IDE on their older systems.

the two functions reside in:

• the file /usr/share/lazarus/3.6.0/components/fpdebug/fpdbglinuxclasses.pas (where they are both referenced and used), and,
• the files /usr/share/fpcsrc/3.2.2/packages/libc/src/ptyh.inc and /usr/share/fpcsrc/3.2.2/packages/libc/src/utmph.inc where they are referenced but not used.

i suspect that the presence of login_tty and openpty may will also affect the ability of FPCUpDeluxe to install Lazarus on older systems, as with systems running versions of glibc prior to 2.34 FPCUpDeluxe may will no longer be able to build the IDE from source.

solutions:

• comment out the source lines that reference login_tty and openpty as they are hopefully/likely only used during development of the IDE
• ask the Lazarus developers to switch to "Dynamic Loading" of these two functions, so that if not actively used they will not affect the ability of lazarus-IDE to load and run

cheers,
rob   :-)


addendum: added in blue above. the symbol versioning seems to somehow be a mix of 'old' and 'new' GLIBC version numbers that may be the result of building the ELF binary lazarus-ide in parts across two different distros - but such a mixture makes no sense.

[PascalDragon]

If you look at the blame of the code in fpdbglinuxclasses.pas then you'll clearly see that these function imports exist like this for 10 years already (though the use of at least login_tty had been removed around a year ago), much longer than the move of openpty and login_tty from libutil to libc inside the glibc project.

The issue is simply as usual that an application compiled on a more modern Linux system isn't usable on an older one.

[Fred vS]

If you look at the blame of the code in fpdbglinuxclasses.pas then you'll clearly see that these function imports exist like this for 10 years already.

So it should have been using this for 10 years already:

Code: Pascal  [Select][+][-]

1. unit FpDbgLinuxClasses;
2. ...
3. const
4.   // allow to assign proper signed symbol table name for a libc.so.6 method
5.   {$if defined(linux) and defined(cpux86_64)}
6.   LIBC_SUFFIX = '@GLIBC_2.2.5';
7.   {$else}
8.   {$if defined(linux) and defined(cpuarm)}
9.   LIBC_SUFFIX =  '@GLIBC_2.4';
10.   {$else}
11.   {$if defined(linux) and defined(cpui386)}
12.   LIBC_SUFFIX = '@GLIBC_2.0';
13.   {$else}
14.   LIBC_SUFFIX = '';
15.   {$endif}
16.   {$endif}
17.   {$endif}
18. ...
19. function login_tty(__fd:longint):longint;cdecl;external 'c' name 'login_tty' + LIBC_SUFFIX;
20. function openpty(__amaster:Plongint; __aslave:Plongint; __name:Pchar; __termp:pointer{Ptermios}; __winp:pointer{Pwinsize}):longint;cdecl;external 'util' name 'openpty' + LIBC_SUFFIX;

Ok, ok, I leave.....   

[robert rozee]

If you look at the blame of the code in fpdbglinuxclasses.pas then you'll clearly see that these function imports exist like this for 10 years already (though the use of at least login_tty had been removed around a year ago), much longer than the move of openpty and login_tty from libutil to libc inside the glibc project.

The issue is simply as usual that an application compiled on a more modern Linux system isn't usable on an older one.

hi PascalDragon - you are right about the two symbols having existed before glibc 2.34 - i see now that they also have 2.2.5 versions. but the use of the 2.34 version these two specific symbols still conflicts with all other libc symbols being versioned to 2.2.5. i have 'toned back' my original posting accordingly.

here is a list of all the libc symbols from lazarus-ide:

     3: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcrtomb@GLIBC_2.2.5 (2)
    17: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openlog@GLIBC_2.2.5 (2)
    36: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tcgetattr@GLIBC_2.2.5 (2)
    51: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND closelog@GLIBC_2.2.5 (2)
    81: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.2.5 (2)
   129: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND read@GLIBC_2.2.5 (2)
   196: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@GLIBC_2.2.5 (2)
   200: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND grantpt@GLIBC_2.2.5 (2)
   221: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND syslog@GLIBC_2.2.5 (2)
   291: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND nl_langinfo@GLIBC_2.2.5 (2)
   306: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@GLIBC_2.2.5 (2)
   313: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __errno_location@GLIBC_2.2.5 (2)
   393: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iconv_close@GLIBC_2.2.5 (2)
   409: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND login_tty@GLIBC_2.34 (3)
   435: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.2.5 (2)
   522: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setenv@GLIBC_2.2.5 (2)
   541: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND strcoll@GLIBC_2.2.5 (2)
   552: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlerror@GLIBC_2.2.5 (2)
   567: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND fcntl@GLIBC_2.2.5 (2)
   591: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iconv_open@GLIBC_2.2.5 (2)
   616: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND unlockpt@GLIBC_2.2.5 (2)
   638: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND write@GLIBC_2.2.5 (2)
   694: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND tcsetattr@GLIBC_2.2.5 (2)
   728: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbrtowc@GLIBC_2.2.5 (2)
   761: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND iconv@GLIBC_2.2.5 (2)
   859: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND wcscoll@GLIBC_2.2.5 (2)
   882: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND ptsname_r@GLIBC_2.2.5 (2)
   915: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openpty@GLIBC_2.34 (3)
   975: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towlower@GLIBC_2.2.5 (2)
  1004: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND sched_yield@GLIBC_2.2.5 (2)
  1062: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dladdr@GLIBC_2.2.5 (2)
  1111: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND close@GLIBC_2.2.5 (2)
  1236: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND setlocale@GLIBC_2.2.5 (2)
  1264: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND mbrlen@GLIBC_2.2.5 (2)
  1324: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND sysconf@GLIBC_2.2.5 (2)
  1325: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND posix_openpt@GLIBC_2.2.5 (2)
  1370: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND towupper@GLIBC_2.2.5 (2)
  1372: 0000000000000000     0 FUNC    WEAK   DEFAULT  UND __cxa_finalize@GLIBC_2.2.5 (2)

(the above is output from: readelf --dyn-syms -W lazarus-ide | grep GLIBC)

note that the above is the output from examining a copy of lazarus-ide extracted directly from the sourceforge .deb file using:
dpkg-deb -R lazarus-project_3.6.0-0_amd64.deb temp

i am at a loss as to how this ELF file was created, likely either a partial set of symbol substitutions was done using a modified FPC compiler (similar to what i have advocated elsewhere but half-baked), or possibly one part of the compilation/make process was carried out on an 'old' linux distro, with the remaining part carried out on a 'new' linux distro. either way, something is seriously wrong.

does anyone know who creates the .deb files that are on sourceforge? i would very much like to have a chat with them.


cheers,
rob   :-)

[Fred vS]

Hello Rob. 

You have a better chance than me of finding only 2 GLIBC_2.34.

I get that:

~/fpcupdeluxe/lazarus$ readelf --dyn-syms -W lazarus | grep GLIBC | grep -v "2.2.5"
   105: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.34 (3)
   375: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlerror@GLIBC_2.34 (3)
   475: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openpty@GLIBC_2.34 (3)
   516: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@GLIBC_2.34 (3)
   786: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@GLIBC_2.34 (3)
   797: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND login_tty@GLIBC_2.34 (3)
   804: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (3)
   937: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dladdr@GLIBC_2.34 (3)

 

[Fred vS]

Ooops, I get it now what you found Rob (sorry, always takes me time)!

Yes, indeed, very strange how they did the binary from the deb file.
It is like they used a "custom fpc with assigned GLIBC_2.2.5 table for all libc methods" to compile Lazarus but did not update fpdbglinuxclasses.pas.


  x 2

[robert rozee]

~/fpcupdeluxe/lazarus$ readelf --dyn-syms -W lazarus | grep GLIBC | grep -v "2.2.5"
   105: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlopen@GLIBC_2.34 (3)
   375: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlerror@GLIBC_2.34 (3)
   475: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND openpty@GLIBC_2.34 (3)
   516: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlsym@GLIBC_2.34 (3)
   786: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dlclose@GLIBC_2.34 (3)
   797: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND login_tty@GLIBC_2.34 (3)
   804: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND __libc_start_main@GLIBC_2.34 (3)
   937: 0000000000000000     0 FUNC    GLOBAL DEFAULT  UND dladdr@GLIBC_2.34 (3)

hi Fred!

that is odd indeed, looks like the person producing the .deb file is experimenting to try and break Lazarus for just a select set of linux distros; if i'm not mistaken your results include the symbols from libdl. this also suggests to me that FPCUpDeluxe does not build lazarus-ide et al locally, depending instead upon downloading pre-built ELF binaries - is this so?

i'm really thinking now that the only safe way of using Lazarus and FPC is to immediately after installing run your rebuild script on FPC, followed by sudo make bigide on Lazarus. this will at least guarantee a sane set of GLIBC symbol versions. of course, even better to first patch the FPC source code for 2.2.5 symbol versions using either your OOTB or my patch234 code!

we really do need the person who is creating the .deb files to chime in here...


cheers,
rob   :-)

[Fred vS]

hi Fred!

that is odd indeed, looks like the person producing the .deb file is experimenting to try and break Lazarus for just a select set of linux distros; if i'm not mistaken your results include the symbols from libdl. this also suggests to me that FPCUpDeluxe does not build lazarus-ide et al locally, depending instead upon downloading pre-built ELF binaries - is this so?

cheers,
rob   :-)

The binary FPCUpDeluxe first download the git source you selected (stable, trunk, ...) then compile lazarus using fpc that also was compiled from git source.
All is done locally and there are no pre-built ELF binaries used, apart of course the initial fpc to build himself.
So it uses the last GLIBC table of the system for each method that accept it  (here GLIBC@2.34 on my system).

And the binary from the deb is strange, if it was build on a older system, ok for __libc_start_main@GLIBC_2.2.5 but why is then openpty@GLIBC_2.34?

Or they used a patched fpc (like fpc-ootb) but should update FpDbgLinuxClasses (see  Reply #2).