| ID: | 5831 |
| From: | rn...@igor2.repo.hu |
| Date: | Fri, 2 Sep 2022 09:22:19 +0200 (CEST) |
| Subject: | Re: [pcb-rnd] pcb-rnd on OpenBSD |
| in-reply-to: | 5829 from rs...@disroot.org |
On Thu, 1 Sep 2022, rsykora@disroot.org wrote: >rnd2@igor2.repo.hu wrote: >> >> Anyway, let's look at one of these that looks relevant: >> >> >pcb-rnd:/usr/X11R6/lib/libX11.so.16.1: /usr/X11R6/lib/libX11.so.18.0 : WARNING: symbol(_XimXTransSocketINETFuncs) size mismatch, relink your program >> >> if I understand it correctly, this is the dynamic linker saying that >> pcb-rnd executable was originally linked against binary version 16.1 of >> libX11.so, but your system currently has version 18.0 and the new version >> is potentially binary-incompatible with the old. >> >> It asks you to re-link pcb-rnd, which is a reasonable thing to do in that >> situation. We don't have a "make relink", so what you could do is this: >> >> 1. go to pcb-rnd trunk/src >> >> 2. rm pcb-rnd >> >> 3. make >> >> This should not recompile anything, only link the executable again. >> >> > >> > >> >I don't understand if these messages are related to the pcb-rnd program >> >itself, or if it points to some deeper system-wide problem. Can anybody >> >comment on this? >> >> If it is what I think it is, then it's sort of normal operation: you >> compiled pcb-rnd from source on a (specific state of) system then upgraded >> the system but not pcb-rnd. Your dynamic linker figures that upon startup. > >The thing is that I have not upgraded the system in the meanwhile. The >behaviour is as described immediately after the compilation of the program; ie, >not even removing pcb-rnd in the src directory and running make changes the >matter. [I actually had this idea, too, and I recompiled both librnd >and pcb-rnd, starting from the .tar.gz in both cases again, but to no avail...] That's interesting! I can only guess. There are two components to this: 1. during the linking process, we call your system's linker, ld, (through the C compiler), using -l to address libs. Your ld will go, make a search (because with -l we vaguely address a lib by name, like -lX11, and not a specific .so file by path), look at the resulting .so files and generate some stub code into the executable. This generated code depends on some apsects of the specific .so file it picked up. It'd be useful to see your link command line (printed when you run make). 2. when you run the executable, your system's _dynamic_ linker, which is a different program than ld, will look at the executable to see what .so files it depends on. Then it does a (different) search for .so files and loads and links them against the executable. (I recommend picking a single .so for these tests, let's say libX11, and concentrate on that one. If we solve this for one, we probably solve this for all). So my guess is that your ld is doing the search differently than your dynamic linker, and finds different version of the files. To verify this, we'd need to look at exactly which .so files ld picks up (maybe strace it) and which .so files your dynamic linker picks up (strace pcb-rnd or run ldd on the executable). Plus it would be nice to know if you really have both versions of the .so files available on yoru system. Maybe they are not in the same dir. Maybe one version in /usr/local/lib, the other in /usr/lib. (To complicate matters further, we do not directly depend on some of these libs, but we depend on a lib that brings in another lib as its own dependency. This adds a whole new search mechanism on top of the above, which an differ between ld and your dynamic linker.) HTH, Igor2
Reply subtree:
5831 Re: [pcb-rnd] pcb-rnd on OpenBSD from rn...@igor2.repo.hu