ld command on OSX - c++

Question

I wanted to use a Dynamic shared library ".so" file using ld command on Mac OS X.
I'm able to compile without errors and create the file using
ld -dynamic -dylib -arch x86_64 -macosx_version_min 10.10.0 -o libpacket.so obj/SpectrumClient.o obj/socket.o obj/packetCounters.o -lSystem /Applications/Xcode.app/Contents/Developer/Toolchains/XcodeDefault.xctoolchain/usr/bin/../lib/clang/6.1.0/lib/darwin/libclang_rt.osx.a
To check the file generated is for OS X..
~ vamsi$ file libpacket.so
libpacket.so: Mach-O 64-bit dynamically linked shared library x86_64
To allow ld to search for this I move the .so file to
/usr/lib
(I get error "ld: library not found for -lpacket" when I don't do so.)
To check if this works I run the command
ld -lpacket -v
I get the following error:
#(#)PROGRAM:ld PROJECT:ld64-242
configured to support archs: i386 x86_64 x86_64h armv6 armv7 armv7s armv7m armv7k arm64
Library search paths:
/usr/lib
/usr/local/lib
Framework search paths:
/Library/Frameworks/
/System/Library/Frameworks/
ld: warning: -arch not specified
ld: warning: -macosx_version_min not specified, assuming 10.6
Undefined symbols for architecture x86_64:
"start", referenced from:
implicit entry/start for main executable
ld: symbol(s) not found for inferred architecture x86_64
I'm running on updated OS X (10.10.5)
Even though I'm specifying the architecture and Minimum OS X version why am I getting the error?
I know I don't have start function in this .so file, but when I link this in other the functions are not linked.
Can someone point out the mistake I'm doing?
Thank you.

Answer 1

ld interprets your command ld -lpacket as a request to link a complete program executable from the object files in the specified library. That would make most sense if packet referred to a static library.
In any case, your library isn't sufficient to build a complete executable. The linker is implicitly looking for a start routine and not finding it. The start routine would not normally be in your code, it would be in the C runtime library. When you use the compiler to drive the link step, the compiler specifies the C runtime library, which provides start. However, the C runtime library then has a dependency on your code providing a _main symbol, so that just moves the problem one step along.
In short, ld -lpacket is not a sensible link command. You can't link just a dynamic library. What is it being linked to? What did you expect that command to accomplish?
The other stuff about -arch and -macosx_version_min not being specified is about this link command. The fact that you specified them when building the library is irrelevant. For this invocation of the linker, you're forcing the linker to guess what you intend, so it's telling you what it guessed.

Answer 2

I found out the issue with why the project wasn't able to link the .so file.
While compiling ".so" file, have additional config
-DTARGET_OS_MAC
Now I don't get the error "Can't find the method..." while linking the .so file to the other project.
#KenThomases.. You were right about "ld -lpacket -v" command not giving any useful information. Thank you!