What is the "___emutls_get_address" symbol?

Question

Oh, I am a newbie in GCC and MAC and Makefile. Today I intended to build a dynamic lib using MAC OS X and GCC 4.4.2, but when linking the .o files, the compiler complains like this:

Undefined symbols:
  "___emutls_get_address", referenced from:
      _malloc in michael.o
      _malloc in michael.o
ld: symbol(s) not found

I googled this info, but I can't understand the results well, I wonder what does the symbol mean, and why lots of programs have this linking error. I also wonder what is the possible cause for this error, the linking command is:

g++ -Dx86 -D_GNU_SOURCE -D_REENTRANT  -Wall -m32 \
    -fno-strict-aliasing -fno-pic -O3 -ggdb \
    michael.o malloc_new.o -o libmichael.so \
    -lpthread -lm -lstdc++  -shared

Acevedo

You shouldn't need to link with -lstdc++ explicitly, g++ should pick up the right one itself. Try removing that. – Debidebilitate

I tried to start CSVExample from "DeepLearning4j Examples" project and after lines "DataSetIterator iterator = new RecordReaderDataSetIterator(recordReader,batchSize,labelIndex,numClasses); logger.info("test point 3."); DataSet allData = iterator.next();" received: "dyld: lazy symbol binding failed: Symbol not found: ___emutls_get_address Referenced from: /Users/firstname/.javacpp/cache/nd4j-native-1.0.0-beta5-macosx-x86_64.jar/org/nd4j/nativeblas/macosx-x86_64/libnd4jcpu.dylib Expected in: /usr/lib/libSystem.B.dylib" at macOS 10.15 and OpenJDK Runtime Environment build 14... – Sheela

...and upgrading till Xcode version 11.1 11A11027. – Sheela

After upgrading the version of the org.deeplearning4j from 1.0.0-beta5 to 1.0.0-beta6 it is ok. – Sheela

Answer 1

This symbol is part of TLS (thread-local storage) emulation by gcc for Mac Os X. There are some bugs in gcc bugzilla about this, e.g.: http://gcc.gnu.org/bugzilla/show_bug.cgi?id=39888

Using thread local storage (e.g. OpenMP ThreadPrivate variables) on Darwin requires manually linking to TLS emutls, via either -lgcc_s.so.1 or -lgcc_eh

See the threads: http://gcc.gnu.org/ml/gcc/2008-12/msg00145.html http://gcc.gnu.org/ml/gcc/2008-12/msg00107.html

From the above threads, this is evidently quite a mess. However, as I was just bit by this I hoped it useful to have a bug tracking the issue.

...

TLS works fine if I manually link to gcc_s.so.1 or gcc_eh as mentioned above.

So, one of possible solutions is to add -lgcc_s.so.1 or -lgcc_eh option to linking step. And other is to update your gcc, because this is bug of gcc.

Bayne

I have tried these two libraries, and the first one not found. After using the second one, the emutls symbol now can be found, but GCC continues to complains that "absolute addressing (perhaps -mdynamic-no-pic) used in _DescRetire from michael.o not allowed in slidable image. Use '-read_only_relocs suppress' to enable text relics", I still haven't an idea about that. – Acevedo

JustQieTry, I think this is from ' -fno-pic ' option. try to recompile your project without this option. You trying to build .so library and any dynamic library should be compiled in -fpic mode. – Bayne

If -fpic is on, there is another problem, it complains that "can't find a register in class ‘BREG’ while reloading ‘asm’", I googled for that and find that for mac, the -fpic is on by default, so I switch it to off....... is that wrong? – Acevedo

JustQieTry, the wrong is that you should not build dynamic library without '-fpic'. This is because dynamic library can be loaded at any beginning address and to be correct in all cases, is must use position-independent code (abbreviated to pic, option is -fpic). Can you show the asm statement, for which there is an error? – Bayne

people.cs.vt.edu/~scschnei/streamflow I use this the michael.tar under this url, and try to build it in Mac, it then shows the 'ask' problem, then I switch it to Linux, it can be build, but when doing dynamic link, compiler tells me that skip incompatible lib... – Acevedo

-lgcc_s.1 found the .dylib Mac OS X library for me, but didn't solve the runtime error. -lgcc_eh was the charm for me - thanks! – Limbert