I'm tweaking an old build where many of the shared libraries don't link against libraries they actually depend on. There's some circular dependencies that have wormed their way into the build over the years I'd like to tackle, but it'll be far simpler if I can get all the non-circular dependencies worked out. Currently, unresolved symbols get resolved when linking executables -- which is how they managed to [unknowingly] introduce circular dependencies.
Here's a short bash script I put together to test some ideas out:
#!/bin/bash
mkdir -p objs
for ((ii=0; ii<3; ii++)); do
echo 'void FUNC(){}' | g++ -xc++ -DFUNC=f${ii} -fpic - -c -o objs/t${ii}.o
g++ -fpic -shared objs/t${ii}.o -o libtest${ii}.so
done
# In the real-world case, libjoined.so isn't a trivial library.
# Currently, it causes things to implicitly link against other
# libraries libblah.so needs (like boost libraries)
echo | g++ -xc++ -shared -fpic -L. -Wl,-R. -ltest{0,1,2} - -o libjoined.so
g++ -xc++ -fpic - -c -o objs/b.o <<'EOF'
extern void f0();
extern void f1();
extern void f2();
void blah() { f0(); f1(); f2(); }
EOF
g++ -fpic -shared objs/b.o -L. -Wl,-R. -ljoined -o libblah.so -Wl,-zdefs
The last line will end up printing out some undefined symbol errors. If this were Solaris, the linker would examine other libraries that would otherwise satisfy the dependency implicitly and provide a hint:
Undefined first referenced
symbol in file
void f1() objs/b.o (symbol belongs to implicit dependency ./libtest1.so)
... but I don't see similar behavior with GNU ld.
In the real-world case, there's a couple hundred libraries in our build plus all the external libraries they and the executables depend on. After adding -zdefs to the build, I'm getting around 10,000+ undefined references; identifying what dependencies are missing by hand would be rather annoying.
I need a fast way to identify the missing dependencies.
On the solaris side, I will probably try making a library like libjoined.so that just links against all of our libraries (where everything is built without -zdefs initially), then write a script that extracts the link command from logs and re-runs the command with -zdefs and links against this other library and dumps the hints to a text file or something.
On the linux side, I'm not sure what I can do to expedite this process.
Any suggestions are welcome.