I have c++ file a.cpp, which uses references to libx.so. a.cpp is made a shared library itself, liba.so by doing:

g++ -shared -fpic  a.cpp -o liba.so

This works fine under linux, yet in OSX, I'd need to readd the reference to x.so:

g++ -shared -fpic  a.cpp -o liba.so -L. -lx

or else:

Undefined symbols for architecture x86_64:
  "foo()", referenced from:
      bar()    in cctvRwlZ.o
ld: symbol(s) not found for architecture x86_64
collect2: error: ld returned 1 exit status

However in Linux if I wish to use liba.so, I also have to add libx.so on the command line, whereas in OSX I can get by, by merely including liba.so.

Linux

g++ main.cpp -L. -la -lx

vs

OSX

g++ main.cpp -L. -la

• Are these differences due to changes in executbale format, ELF vs Mach-O - could someone elaborate?
• Why is the exact order of dependents needed in the case of linux?

Update

Looking at the libraries referenced:

Mac

Darwin/liba.so:
    Darwin/liba.so (compatibility version 0.0.0, current version 0.0.0)
    Darwin/libx.so (compatibility version 0.0.0, current version 0.0.0)

Darwin/main:
    Darwin/liba.so (compatibility version 0.0.0, current version 0.0.0)

Linux

ldd liba.so
    [none, besides default]

ldd a.out
    liba.so => /home/gandalf/BTSync/tutorials/cpp/sharedlibosx/liba.so (0x00007fcf89097000)
    libx.so => /home/gandalf/BTSync/tutorials/cpp/sharedlibosx/libx.so (0x00007fcf88a9f000)

So it shows nicely that linking for liba is deferred until it is actually used in something like a main.