2

I would like to create file-12.o by linking/loading two files, file-1.o and file-2.o so that function references in file-1.o that can be resolved by symbols in file-2.o are resolved, but leaving other symbols to be resolved in a subsequent load.

Is this possible? I'm using the gnu toolchain on linux (ubuntu 18.04).

I have tried using ld -r -o file-12.o file-1.o file-2.o but the function calls (as seen by objdump -S) are not resolved, i.e., the callq instruction still shows e8 00 00 00 00.

This What is Partial Linking in GNU Linker? seems to indicate that it's not possible, or at least this author didn't know how to ("This also taught me that GCC does not resolve function calls before the final link either TODO rationale, possible to force it to resolve?")

As a little background, I'm trying to link to hdr_histogram in a node 11/12 environment. As part of the Performance Hooks they started using hdr_histogram and my node addon is linking to the node version as opposed to the library I wish to link. So if you know a way for node-gyp to prioritize my library in front of the node library in linking priority that solution would work for me too.

ZachB
  • 13,051
  • 4
  • 61
  • 89
bmacnaughton
  • 4,950
  • 3
  • 27
  • 36
  • What you are looking for is a shared library. – user3344003 May 17 '19 at 01:00
  • maybe not. i have had all the libraries loaded in a `.so` file and the references to `hdr_init` are still satisfied by the node version, not the version in my `.so` file. but maybe i'm missing something there - is there a way to force the resolution of function calls within the components of the `.so` file when building it? – bmacnaughton May 17 '19 at 01:05
  • it's certainly possible that the way the `.so` file is being built leads to this problem. – bmacnaughton May 17 '19 at 01:06
  • 1
    I would not conclude from the fact that the linker did not modify the call instruction that it did not resolve the symbols without further investigation. It might have recorded the segment and offset of the symbol, leaving the instruction fix-up for later. – Eric Postpischil May 17 '19 at 02:12
  • Well, it was worth a try. I added a module that referenced the hdr_histogram* symbols, generated a `.o` file from it, and tried creating both a `.a` file using `ld -r` as well as creating a `.so` file using `gcc -shared`. both approaches still result in linking to the node version of the hdr files. – bmacnaughton May 17 '19 at 13:44
  • @EricPostpischil - you're right, I shouldn't conclude that. So I went back and have verified that even with partial linking, --start-group/end-group, and every other approach that I took I could not get the linker to resolve the symbols to the version I supplied to `ld`. If I wasn't using node-gyp I believe I could accomplish this with a tool that would strip particular symbols that node exports. And I could do that with my local copy, but not for any system doing their own install. It does leave the fixup for later but always uses the node value for the fixup. – bmacnaughton Jun 04 '19 at 11:45

0 Answers0