Thank you for your help.

I did what you did, but on my platform. I did ldd libsocket.so to see the list in my context. It was different but I continued.

I tried what you said and linked with
/lib/libsocket.a and /lib/libnsl.a
then I had only a few left and they seemed related to lindl so I tried linking to libdl.a too but discovered there was no libdl.a only a lindl.so so I tried linking to this in hopes that it would resolve the static linkage but then find libdl.so and link dynamically at run time. As I mentioned, I normally avoid .so files to avoid run time linkage issues, but I tried it.

The executable linked but when I ran it all the calls to ioctl returned -1 (error). Keep in mind that when I make these same calls (or similar) on Linux they work. I suspect the linkage more than the calling code. All I am doing at the point I get the error is calling ioctl() with
a handle value of 8, SIOCGIFADDR and IfReq.ifr_name set to "eth0"
The handle is from a call to
socket(AF_INET, SOCK_DGRAM, IP_PROTOIP)

Any other ideas?

Can you tell me in a nutshell how the so system works. For example, when I link with a .so file, does it resolve the static linkage issue and the at runtime go out looking for the same .so file to dynamically link to it?
If this is the case, then what are the rules for finding the .so file (in case the location of the .so file on my compiling platform is different that the end users platform)?
Could I have inked with libsocket.so directly? Is this any better? Or is it just a matter of preference?
My concern is of course two things:
- why did it link and the fail to run properly (assuming my code is OK)?
- how can I be sure my code will run reliably using .so files if I do get it to work?

Thank you for your insights.