0

I have already figure out how to staticly link v8 with my own GLIBC/STDC++.

$(GCC_ROOT)/bin/g++ samples/bench.cpp -o bench -isystem$(GLIBC_ROOT)/include/ -I. -Iinclude -isystem$(GLIBC) -nodefaultlibs  -DV8_COMPRESS_POINTERS -static $(V8_OBJ)/libv8_monolith.a -Wl,--start-group $(GCC_ROOT)/lib64/libstdc++.a  $(GLIBC_ROOT)/lib/libpthread.a $(GLIBC_ROOT)/lib/libdl.a $(GLIBC_ROOT)/lib/libm.a $(GLIBC_ROOT)/lib/librt.a $(GCC_GCC)/libgcc.a $(GCC_GCC)/libgcc_eh.a $(GCC_GCC)/libcommon.a $(GLIBC_ROOT)/lib/libc.a -Wl,--end-group

However, I find it not good to link all stuff staticly, and I want to GLIBC/STDC++ dynamicly, and my strategy is:

  1. For all .a which is staticly linked, I use -Wl,-rpath= to specify its path.
  2. For those .a which has no corresponding .so, such as libgcc.a, I still link them staticly.

So I write the following command

$(GCC_ROOT)/bin/g++ samples/bench.cpp -isystem$(GLIBC_ROOT)/include/ -I. -Iinclude -isystem$(GLIBC_ROOT)/ -o bench_dyn -nodefaultlibs  -DV8_COMPRESS_POINTERS -Wl,--start-group $(V8_OBJ)/libv8_monolith.a  -Wl,-rpath=$(GCC_ROOT)/lib64/ $(GCC_GCC)/libgcc.a $(GCC_GCC)/libgcc_eh.a $(GCC_GCC)/libcommon.a -Wl,-rpath=$(GLIBC_ROOT)/lib -Wl,--end-group

However, this strategy won't work, because lots of symbols are not found, such as

  1. pthread_mutex_*
  2. std::ostream::operator<<(int)

I think these are all GLIBC/STDC++ symbols, and I linked them dynamicly, so they should not remain undefined?

What's wrong here?

calvin
  • 2,125
  • 2
  • 21
  • 38
  • Context: [Why pthread_rwlock_t's ABI differs a lot among versions](https://stackoverflow.com/questions/65230865/why-pthread-rwlock-ts-abi-differs-a-lot-among-versions/65235265#65235265). – John Bollinger Dec 10 '20 at 13:41
  • To statically link Glibc on a system that defaults to dynamic linking, you have to jump through several hoops that are simply unnecessary with dynamic linking. I suggest rewriting your link command from scratch instead of trying to convert it from the static version. – John Bollinger Dec 10 '20 at 13:48
  • Also, shared and static libraries often mix poorly. I strongly recommend that all reusable libraries be built as shared libraries on systems that use shared libraries. – John Bollinger Dec 10 '20 at 13:50

0 Answers0