<div dir="ltr">problem is that i am already using "extern C" declaration, <div><br></div><div>and as far as symbol names i'm relying on compiler </div><div><br></div><div>so far i have noticed that some problems go away if i don't include some headers (iostream) and that's fine </div><div>but now when i try to use std::string in nif implementation, when i call it i get:</div><div><br></div><div><pre style="box-sizing:border-box;font-family:consolas,"liberation mono",menlo,courier,monospace;font-size:11.9px;margin-top:0px;margin-bottom:0px;font-stretch:normal;line-height:1.45;word-wrap:normal;padding:16px;overflow:auto;background-color:rgb(247,247,247);border-radius:3px;word-break:normal;color:rgb(51,51,51)">{<span class="gmail-pl-c1" style="box-sizing:border-box;color:rgb(0,134,179)">load_failed</span>,<span class="gmail-pl-s" style="box-sizing:border-box;color:rgb(24,54,145)"><span class="gmail-pl-pds" style="box-sizing:border-box">"</span>Failed to load NIF library: './priv/my.so: undefined symbol: __gxx_personality_v0'<span class="gmail-pl-pds" style="box-sizing:border-box">"</span></span>
</pre></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Sun, Feb 5, 2017 at 9:01 AM, zv <span dir="ltr"><<a href="mailto:zv@nxvr.org" target="_blank">zv@nxvr.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I'm not familiar with ~nifpp~ in particular, but if you are receiving an error like<br>
<br>
> undefined symbol: enif_make_atom<br>
<br>
There are underlying issues beyond symbol mangling.<br>
<br>
I assume you are including erl_nif.h, directly or otherwise. As far as the mangling is concerned, you haven't made it clear if you are using objdump to extract the correct symbol name or if you are relying on the compiler, although Stanislaw has already mentioned the issue so you have a thread to follow.<br>
<br>
If you are getting an 'undefined symbol' on function call, you are dynamically linking your library, which means you need to make sure that your library is on the linker path during runtime as that's how the dynamic library loader will find it (which happens when you load the nif in Erlang, it spiders out to the libraries that library needs until it can resolve all the required symbols).<br>
<br>
An alternative approach would be to make your my.so a static library my.a and then link your nif against that which removes some of these issues in finding libraries.<br>
<br>
You also might want to just consider an "extern C" linkage declaration, totally bypassing any mangling or other C++ symbol decoration idiosyncrasies.<br>
<br>
- zephyr<br>
<br>
______________________________<wbr>_________________<br>
erlang-questions mailing list<br>
<a href="mailto:erlang-questions@erlang.org">erlang-questions@erlang.org</a><br>
<a href="http://erlang.org/mailman/listinfo/erlang-questions" rel="noreferrer" target="_blank">http://erlang.org/mailman/<wbr>listinfo/erlang-questions</a><br>
</blockquote></div><br></div>