Home/ Questions/Q 6706763
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-26T07:33:31+00:00

Without modifying and recompiling the gnu gcc and stdc++ library builds, I need to

  • 0

Without modifying and recompiling the gnu gcc and stdc++ library builds, I need to be able to reproduce dynamic loading versions of those libraries with a different embedded soname.

I thought I would be clever and use the available static versions and repackage them with something like this:
ld -E -shared -static "-lstdc++" -lgcc -lgcc_eh -o librepackaged_standard.so

librepacked_standard.so is created, without warnings or errors, but ldd reports its not a dynamic library and readelf reports only these basic symbols:

Symbol table '.symtab' contains 4 entries:
   Num:    Value          Size Type    Bind   Vis      Ndx Name
     0: 0000000000000000     0 NOTYPE  LOCAL  DEFAULT  UND 
     1: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS __bss_start
     2: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS _edata
     3: 0000000000201000     0 NOTYPE  GLOBAL DEFAULT  ABS _end

I am unsure why ld isn’t bringing in all of the symbols defined statically. I also don’t know if there are any other special parameters I need to give it for this to work.

Another option is if there is a know cross platform way to simply change the soname embedded in the original elf libraries. I’m currently only concerned with elf formatted binaries. I am not interested in writting my own tool to change the .soname in existing binaries.

UPDATE:
The reason no symbols were getting compiled is because ld handles static binaries differently than .o files. By default it does not import any symbols from the .a file unless they are required by a another library on the link line. I fixed that by provided the –whole-archive option.

However that gives me another error, relocation R_X86_64_32S against_ZSt12_S_first_one’ can not be used when making a shared object; recompile with -fPICand could not read symbols: Bad value` They are both from libstdc++.a in the bitset.o archive. So I can’t just recompile the .a’s into a dynamic library because the GNU GCC compile, by default, does not compile the object files used for the static libraries with the PIC option.

That leaves me with finding an elf tool or recompiling GNU GCC with modifications to its build.

As stated by one of the answers, licensing issues could be a concern with any of these approaches. My best answer is that we need to change to our requirements and find a different solution that doesn’t involve changing or repackaging the GCC standard libraries in any fashion.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    The reason no symbols were getting compiled into the shared library is because ld handles static binaries differently than .o files. By default it does not import any symbols from the .a file unless they are required by a another library on the link line. The answer to that particular issue is to use the –whole-archive option and linking the .a files directly mostly works.

    However, for this to work the .o files included in the static archive need to have been compiled using the -fPIC option at compile time. However the object files used for the static libraries are not compiled with that option in the static libraries available.

    So, the solution to changing the SONAME is to use an ELF binary utility or rebuilding GNU GCC modified to use different SONAMEs.

    Since there are licensing concerns in this situation any of the solutions are not practical for the project because it is not open source and we do not want the requirement to redistribute a modified source version of GNU GCC for all our platforms.

    • 0