/lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.34' not found

[TRon]

Ah thank you for pointing out my mistake Robert. I was (still) referring to your post https://forum.lazarus.freepascal.org/index.php/topic,58888.msg483544.html#msg483544 when I wrote my reply. I'll have to check that  thank you for the continues contribution on the subject.

My apologies to Fred vS (and you Robert), I am/was wrong there.

[DonAlfredo]

This approach might (also) be useful for fpcupdeluxe, when cross-compiling towards Linux.
I will do some testing.

[DonAlfredo]

Linking with your custom libdl.c works well.
In my case, I needed few more extras:
void openlog() { }
void closelog() { }
void syslog() { }
void sysconf() { }
If above added, the cross-compiled fpcupdeluxe linux binary is fully GLIBC-unversioned !

[Fred vS]

Linking with your custom libdl.c works well.
In my case, I needed few more extras:
void openlog() { }
void closelog() { }
void syslog() { }
void sysconf() { }
If above added, the cross-compiled fpcupdeluxe linux binary is fully GLIBC-unversioned !

Fantastic!

@Rob: 

[dbannon]

I think this is a seriously important development !

It really needs a wiki page rather than risking getting lost in the steady roll out of forum posts. It will not be that long before the OS Systems that will not run a binary compiled on a new system are themselves no longer supported and the excitement here will die down.

But it will happen again, something will be changed again in glibc and people will again have this problem. So, a record of this excellent work must be readily available in the wiki for it to be reapplied.

Robert, do you want to write a Wiki page, maybe called, simply, "glibc symbols" or something similar ?

Congratulations to all involved in this project !   (I readily confess I thought it was a dead end, Wrong!)

Davo

[Fred vS]

It is just what it is and if not mistaken you've dealt with such things in the past before (mse etc).

Hard to be the Jiminy Cricket of FPC. 

[robert rozee]

Robert, do you want to write a Wiki page, maybe called, simply, "glibc symbols" or something similar?

i would be happy to help with writing a wiki page, however my knowledge of glibc symbols is pretty much summed up in what has been presented here. i am far from an expert, and proceeded mostly through trial-and-error hacking away at a problem i had a hunch should be solvable. the major breakthrough actually occurred when another forum member emailed that he had added __libc_start_main to the library libdl.so where it did not belong. it was from there that i guessed what was going on - that when the glibc developers (as of glibc 2.34) merged the functionality of libdl.so into libc.so they had to leave a 'back door' for older binaries to continue working, in the form of a placeholder libdl.so that simply 'handed symbols on' to the new expanded libc.so.

now that we know what is possible, much more widespread testing is needed. we need to discover the limitations introduced with unversioned symbols, and look at ways to catch any resulting errors at run-time. this requires cooperation from the experts - the FPC developers. they know the inner workings of FPC's RTL far better than anyone else, and the how and why of the RTL's use of libc functions.

there is also the interesting question of: why are libc functions so widely bound to using EXTERNAL? certainly it makes for simple one-line code, but could one not equally well use a combination of dlopen('libc.so.6', flags) and dlsym()? in one fell swoop this could considerably shrink the list of symbols in a binary's Dynamic Symbol Table to... just three (__libc_start_main, dlopen, and dlsym).


cheers,
rob   :-)

[sketch]

In the version file

Code: [Select]

GLIBC_2.2.5 {
  global: dlopen; dlsym; dladdr; dlclose; dlerror;
};

Why not just wildcard it?

Code: [Select]

GLIBC_2.2.5 {
  *;
};


[Fred vS]

In the version file

Code: [Select]

GLIBC_2.2.5 {
  global: dlopen; dlsym; dladdr; dlclose; dlerror;
};

Why not just wildcard it?

Code: [Select]

GLIBC_2.2.5 {
  *;
};


With the last solution, no need anymore of the map file. 
https://forum.lazarus.freepascal.org/index.php/topic,58888.msg483626.html#msg483626

[sketch]

however it does leave all six of the symbols unversioned in your application's Dynamic Symbol Table.

Create a fake libdl.so file using the following libdl.c:

Code: C  [Select][+][-]

1. void dlopen() { }
2. void dlsym() { }
3. void dladdr() { }
4. void dlclose() { }
5. void dlerror() { }
6. void __libc_start_main() { }

A version script has three purposes:

* Define versions.
* Specify some patterns so that matched defined symbols (which do not have @ in the name) are tied to the specified version.
* Scope reduction
   * for a matched symbol, its binding will be changed to STB_LOCAL and will not be exported to the dynamic symbol table.
   * for a defined unversioned symbol, it can be matched by a local: pattern in any version node. E.g. foo can be matched by v1 { local: foo; };
   * for a defined versioned symbol, it can be matched by a local: pattern in the associated version node. E.g. both foo@@v1 and foo@v1 can be matched by v1 { local: foo; };.

Since it's an ABI change, don't you want to use a version file and so it won't be exported to the dynamic version symbol table?

[robert rozee]

* Scope reduction

1. it is a fake libdl.so file, the code within is never executed. the file exists purely to guide the linker at compile-time towards arriving at a particular conclusion - that the symbols therein should be unversioned.

2. our goal is not scope reduction, but instead scope expansion. this expansion only avoids ending in tears because the original scope reduction was done to achieve purely philosophical objectives that lacked any useful intersection with the real world.

3. please stop using ChatGPT to generate your postings. perhaps i am being a bit harsh, but your posts do seem to be coming from way off left field.


cheers,
rob   :-)

[sketch]

I don't use ChatGPT, Einstein. So go fuck yourself. Delete this comment if you want, but I'll never know because I am never coming back here and refuse to let some elitist piece of shit talk down to me.

[Fred vS]

@sketch.

Everybody, not only you, who have participated to this topic, is hyper-stressed.

Fisrt those who did try to solve the problem.
It is a hard battle, if fact, even the fpc team is helpless in the face of the goodwill of the glibc developers.

Your post may have felt like a misguided attempt to only annoy and maybe the reader was in bad mood.
Please, try to do like all of us try to do, breathe calmly, think about something else and still remain creative and open-mind.

Your contribution is precious, dont forget we are all in the dark.

[Lulu]

Hi, I thanks you all of your, because I'm know programming in Pascal but I'm not aware about what append in the backstage of the compiler/linker. Reading all this discussion was VERY constructive for me ! Actually, I can say that about the whole Lazarus forum.
And I say that in all sincerity.

[robert rozee]

Delete this comment if you want, but I'll never know because I am never coming back here and refuse to let some elitist piece of **** talk down to me.

my apologies, i had detected a certain style in your posting that had triggered my ChatGPT 'detector', quite falsely as it turns out. i have now read through your other forum postings, and it seems to just be a writing style thing; i found your comments on left-pad and layers of abstraction highly interesting. a search with google revealed a good background: https://qz.com/646467/how-one-programmer-broke-the-internet-by-deleting-a-tiny-piece-of-code.

when someone writes with detailed examples and an extremely even timbre these days, i tend to be suspicious. coupled with a toothache that has been with me for nearly a week (am off to the dentist in a few hours), and i did respond without due deliberation. again, my apologies.

from your past postings on the forum it does look like you have some knowledge of how map files work - if you could figure out how to version __libc_start_main to GLIBC_2.2.5 using just the fake libdl.so that would 'close the circle' on the GLIBC 2.34 problem. it evaded me, hence the need to edit the FPC RTL to handle that one symbol. unversioning everything, as you've noticed, was far easier.


cheers,
rob   :-)