undefined reference to link, unlink, execve, wait, fork

[michaK]

Hi,

I'm getting pretty close to porting my engine to nacl, everything
builds fine and links with a few libs from the ports.
I'm pretty happy with this toolchain. It's so much better than the
Android ndk makefiles. Nice Job!

Well, I'm still stuck with a few libc calls link errors:

/Users/michaK/nacl/nacl_sdk/pepper_16/toolchain/mac_x86_newlib/bin/../
lib/gcc/x86_64-nacl/4.4.3/../../../../x86_64-nacl/lib/../lib32/
libcrt_common.a(lib_a-unlinkr.o): In function `_unlink_r':
unlinkr.c:(.text+0x1c): undefined reference to `unlink'
/Users/michaK/nacl/nacl_sdk/pepper_16/toolchain/mac_x86_newlib/bin/../
lib/gcc/x86_64-nacl/4.4.3/../../../../x86_64-nacl/lib/../lib32/
libcrt_common.a(lib_a-execr.o): In function `_wait_r':
execr.c:(.text+0x1c): undefined reference to `wait'
/Users/michaK/nacl/nacl_sdk/pepper_16/toolchain/mac_x86_newlib/bin/../
lib/gcc/x86_64-nacl/4.4.3/../../../../x86_64-nacl/lib/../lib32/
libcrt_common.a(lib_a-execr.o): In function `_fork_r':
execr.c:(.text+0x9c): undefined reference to `fork'
/Users/michaK/nacl/nacl_sdk/pepper_16/toolchain/mac_x86_newlib/bin/../
lib/gcc/x86_64-nacl/4.4.3/../../../../x86_64-nacl/lib/../lib32/
libcrt_common.a(lib_a-execve.o): In function `execve':
execve.c:(.text+0xa): undefined reference to `_execve'
/Users/michaK/nacl/nacl_sdk/pepper_16/toolchain/mac_x86_newlib/bin/../
lib/gcc/x86_64-nacl/4.4.3/../../../../x86_64-nacl/lib/../lib32/
libcrt_common.a(lib_a-linkr.o): In function `_link_r':
linkr.c:(.text+0x3c): undefined reference to `link'
collect2: ld returned 1 exit status

But there's no call to execve in my source tree:

Orange:Sparks michaK$ grep -r execve .
Orange:Sparks michaK$

Anyone already ran into this ?

Best,

M

[michaK]

I finished porting our first nacl game! Everything compiles smothly.

I must say, this is the most easy & pleasant port I had to make so far even though the sdk is still at beta level. 
I was using 4 of the libraries in the ports repo and I'm linking with all your patched versions fine.

But I'm still stuck with this link error!!!

Any idea why I can't link with link, unlink, execve, wait, fork ?

Can somebody help, I can't wait to start debugging.

Cheers,

M

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

--
Michel Courtine | CEO | iVoltage
+33 6 189 354 89 | mic...@ivoltage.me

http://ivoltage.me

[Adam Villalobos]

You can link to nosys lib (-lnosys) to get rid of the linker errors,
it will fail if you actually use the functions though.

> Michel Courtine | CEO | iVoltage+33 6 189 354 89begin_of_the_skype_highlighting            +33 6 189 354 89      | mic...@ivoltage.me
>
> http://ivoltage.me

[Jim]

I got these errors too, I did not use any of these functions. Can
anyone shed some light on why they are linked in.

[Bennet Yee (余仕斌)]

On Sat, Dec 17, 2011 at 7:07 PM, Jim <jamesf...@torapp.info> wrote:

I got these errors too, I did not use any of these functions. Can
anyone shed some light on why they are linked in.

i think these are just functions implemented in libc (newlib, in this case) which wrap the underlying system calls.  it was easier for us to provide the syscall wrappers -- even if they don't actually invoke any syscalls and all they ever do is return an error -- than to dive into newlib (or glibc) and remove that code.  plus, often when porting other libraries (e.g., image processing) all that anybody might want to do is to call a few functions that we know don't involve such unimplemented syscalls (e.g., doing image transforms in memory, never invoking code that need to write them to disk), and if these libc-level functions were removed and unavailable (no libnosys), then these other libraries would not link and would also require more surgery.

(it is not great in that doing so safely so that the functionality that we want will still work require knowledge of how libraries are implemented, violating all sorts of abstraction rules.  but it's expedient.)

-bsy

 

On Dec 17, 4:27 pm, Adam Villalobos <a...@ziplinegames.com> wrote:
> You can link to nosys lib (-lnosys) to get rid of the linker errors,
> it will fail if you actually use the functions though.

--
You received this message because you are subscribed to the Google Groups "Native-Client-Discuss" group.
To post to this group, send email to native-cli...@googlegroups.com.
To unsubscribe from this group, send email to native-client-di...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/native-client-discuss?hl=en.

--
bennet s yee
i usually don't capitalize due to mild tendonitis

[michaK]

Thanks! Good flag to know! Links correctly now and doesn't crash... there ;)

Cheers,

M

Michel Courtine | CEO | iVoltage