OSX: Undefined symbols for architecture x86_64 __d_osx_image_init2

[thelastmammoth]

I followed the instructions given on https://github.com/ldc-developers/ldc/wiki/Installation with a few modifications to make the build successful on OSX (see below for required modifications):

when compiling + linking a hello world program main.d I get the following link error:

ldc2 main.d
Undefined symbols for architecture x86_64:
"__d_osx_image_init2", referenced from:
_main in libphobos-ldc.a(dmain2.o)
ld: symbol(s) not found for architecture x86_64
collect2: ld returned 1 exit status
Error: linking failed:
status: 1

************************************ installation *************************
sudo port install libconfig-hr (install libconfig)
then in ccmake, change llvm path to /opt/local/bin/llvm-config-mp-3.0 (to make it work with the macports version)

ccmake complains (" libconfig++ not found") ("consider manually setting the LIBCONFIG_CXXFLAGS and LIBCONFIG_LDFLAGS"). Unfortunately the instructions given here (http://www.dsource.org/projects/ldc/wiki/OSXBuildInstructions : you also need to set LIBCONFIG_LDFLAGS="-L/usr/local/lib -lconfig++" in advanced options of ccmake (while configuring, press 't', scroll down) didn't work as LIBCONFIG_LDFLAGS doesn't appear in advanced options.

but the following manual way works:
cmake .. -DLIBCONFIG_LDFLAGS="-L/opt/local/lib/ -lconfig++" -DLIBCONFIG_CXXFLAGS=-I/opt/local/include/
followed by make && make install

that compiles fine, ldc2 is created

[dansanduleac]

I am having the exact same issue and I tracked it down to some files that runtime/CMakeLists.txt is deliberately told not to link (i.e. they are globbed into DCRT_D but then explicitly removed), see runtime/CMakeLists.txt:74.
runtime/druntime/src/rt/dmain2.d calls _d_osx_image_init2, which is defined in memory_osx.d (same directory), which in turn needs deh2.dand a thread-local storage array (_tls_data_array).. The problem is I have no idea where _tls_data_array is actually initialized.

[dansanduleac]

Actually _tls_data_array is meant to be declared normally in memory_osx.d, not as extern, so that its declaration becomes extern (C) /* extern */ __gshared ubyte[][2] _tls_data_array; (because it is in this file @onAddImage2 that the array is initialized) and then it works (+ some module path mixup in there too).

Also un-disable (fancy enable?) memory_osx.d and deh2.d in CMakeLists.txt.

There was also a configuration problem in CMake: instead of copying the provided druntime/src/rt/thread.di to the include dir, it ignores it and generates one from the .d file, carrying with it an import from rt, code which user programs don't have access to. So I had to move thread.di manually into /usr/local/include/d/core/.

With all these changes I managed to link a program that uses threads. :) I'll try to make a brew Formula when I get the chance.

[dnadlinger]

Both of the problems are caused by upstream changes being merged in without OS X being tested (which is hard for many devs).

_tls_data_array is defined in core.thread, which is correct. rt.memory_osx just needs to access it, which is arguably not quite clean (but then, Walter committed the change, so…).

It doesn't matter for us in any case – removing memory_osx.d is deliberate, as it contains code specific to how DMD uses magic marker sections to bracket TLS data. The LDC pendant to it is ldc/memory.d, so if any of the changes are applicable to LDC as well (which I doubt, after a quick look), they should go there.

druntime/src/rt/thread.di is also quite new (in terms of releases) and our build system simply has not been updated to use them yet.

Will push a fix for both shortly.

[thelastmammoth]

Hi thanks for your answers; could it be related to a previous regression I reported?
See: http://d.puremagic.com/issues/show_bug.cgi?id=7995
(there was a pull request which worked for me but it got reverted for some reason)

[dnadlinger]

@thelastmammoth: No, this is genuinely a LDC bug – the build error was caused by indadvertedly merging in Walter's fix for Issue 4854, which is DMD only, into our copy of druntime. The fix is trivial, but I still need to test it before pushing it to the repo (hopefully in a few hours or so).

[dansanduleac]

I issued a pull request :) How do I run unittests btw?

[dnadlinger]

Fixed in master.

@dansanduleac: At the moment, you unfortunately need to manually run the DMD/druntime/Phobos test suites from the respective repositories, setting the compiler to ldmd2. This is anything but a nice solution though, and we definitely need an infrastructure for adding our own regression tests – any help would be very much appreciated!

[thelastmammoth]

I can't build from master:

...
Building CXX object CMakeFiles/ldc2.dir/driver/toobj.cpp.o
/Users/timothee/git_clone/ldc2/driver/linker.cpp:172:12: warning: enumeration values 'OSinvalid' and 'OSSolaris' not handled in switch [-Wswitch-enum]
switch(global.params.os) {
^
/Users/timothee/git_clone/ldc2/driver/linker.cpp:320:12: warning: enumeration values 'OSinvalid' and 'OSHaiku' not handled in switch [-Wswitch-enum]
switch(global.params.os) {
^
2 warnings generated.
Linking CXX executable bin/ldc2
[ 97%] Built target ldc2
make[2]: *** No rule to make target ../runtime/druntime/src/object_.d', needed byruntime/src/object_.o'. Stop.
make[1]: *** [runtime/CMakeFiles/druntime-ldc.dir/all] Error 2
make: *** [all] Error 2

[dansanduleac]

You need to git submodule update -i to checkout the druntime and phobos submodules first. Then it should work.

On 2 Jun 2012, at 21:03, thelastmammoth wrote:

I can't build from master:

...
Building CXX object CMakeFiles/ldc2.dir/driver/toobj.cpp.o
/Users/timothee/git_clone/ldc2/driver/linker.cpp:172:12: warning: enumeration values 'OSinvalid' and 'OSSolaris' not handled in switch [-Wswitch-enum]
switch(global.params.os) {
^
/Users/timothee/git_clone/ldc2/driver/linker.cpp:320:12: warning: enumeration values 'OSinvalid' and 'OSHaiku' not handled in switch [-Wswitch-enum]
switch(global.params.os) {
^
2 warnings generated.
Linking CXX executable bin/ldc2
[ 97%] Built target ldc2
make[2]: *** No rule to make target ../runtime/druntime/src/object_.d', needed byruntime/src/object_.o'. Stop.
make[1]: *** [runtime/CMakeFiles/druntime-ldc.dir/all] Error 2
make: *** [all] Error 2

---

Reply to this email directly or view it on GitHub:
#101 (comment)

[thelastmammoth]

thanks, it does! Couple questions while I'm at it:
1)
file main.d:
module fun; void main(){}
ldc2 main => will create ./fun as opposed to ./main as it should (at least that's the behavior of dmd)

2. what's the difference bw ldc2 and ldmd2 ?

3. debugging with lldb still yields mangled D names in the backtrace, even compiling with -g or -g -gc

I really don't understand why it can't demangle those symbols, as it's easy to do with ddemangle for example?

• thread Removed Phobos 1 from LDC tree. #1: tid = 0x1f03, 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8, stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff5ffd00ac) frame #0: 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8
  5 assert(x==2);
  6 }
  7 void fun(int* x){
  -> 8 assert(x[1000000]==2);
  9 }
  10 class A{
  11 //int [] x;
  (lldb) bt
• thread Removed Phobos 1 from LDC tree. #1: tid = 0x1f03, 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8, stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff5ffd00ac) frame #0: 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8
  frame Removed Phobos 1 from LDC tree. #1: 0x0000000100001324 fun_Dmain + 52 at main_bak1.d:21 frame #2: 0x00000001000447ff fun_D2rt6dmain24mainUiPPaZi7runMainMFZv + 31 at dmain2.d:530
  frame bash_completion #3: 0x000000010004478a fun`_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42 at dmain2.d:505

Thanks!

[dansanduleac]

Great!

1. I really don't know. If you think it's a bug, open a new issue for it.

2. ldmd2 is a small shell script (open it) that basically calls ldc2, but does some parameter conversion beforehand. It's there to offer compliance with some dmd2 parameters, such as "-inline" or "-fPIC" which (probably for similarity with other llvm frontends) look differently in ldc2.

3. I'm not familiar with lldb, but I'm assuming it's not set up to know about D symbol mangling, just like in gdb you would use a plugin that demangles C++ symbols. I don't know if anybody wrote one so far.

Hope this helps

On 2 Jun 2012, at 23:00, thelastmammoth wrote:

thanks, it does! Couple questions while I'm at it:
1)
file main.d:
module fun; void main(){}
ldc2 main => will create ./fun as opposed to ./main as it should (at least that's the behavior of dmd)

2. what's the difference bw ldc2 and ldmd2 ?

3. debugging with lldb still yields mangled D names in the backtrace, even compiling with -g or -g -gc

I really don't understand why it can't demangle those symbols, as it's easy to do with ddemangle for example?

• thread Removed Phobos 1 from LDC tree. #1: tid = 0x1f03, 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8, stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff5ffd00ac) frame #0: 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8
  5 assert(x==2);
  6 }
  7 void fun(int* x){
  -> 8 assert(x[1000000]==2);
  9 }
  10 class A{
  11 //int [] x;
  (lldb) bt
• thread Removed Phobos 1 from LDC tree. #1: tid = 0x1f03, 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8, stop reason = EXC_BAD_ACCESS (code=1, address=0x7fff5ffd00ac) frame #0: 0x00000001000012c0 fun_D3fun3funFPiZv + 16 at main_bak1.d:8
  frame Removed Phobos 1 from LDC tree. #1: 0x0000000100001324 fun_Dmain + 52 at main_bak1.d:21 frame #2: 0x00000001000447ff fun_D2rt6dmain24mainUiPPaZi7runMainMFZv + 31 at dmain2.d:530
  frame bash_completion #3: 0x000000010004478a fun`_D2rt6dmain24mainUiPPaZi7tryExecMFMDFZvZv + 42 at dmain2.d:505

Thanks!

---

Reply to this email directly or view it on GitHub:
#101 (comment)

[dnadlinger]

@dansanduleac: Correct – and I'm working on a more capable replacement for ldmd.

[dansanduleac]

Btw, there might not be any way as of yet for lldb to automatically demangle symbols in D, but for gdb there are patches that enable this: http://www.dsource.org/projects/gdb-patches.

[dnadlinger]

… and they are already (or at least to a large part) in mainline GDB since 7.1.

[thelastmammoth]

yes, but in my experience they work on linux but not on OSX (see my other post http://d.puremagic.com/issues/show_bug.cgi?id=8172). I contacted the author of the original gdb patch (Mihail Zenkov) and he has only tested on linux it seems). Is that your experience as well?