libblas and liblapack depend on f2c, but the shared libraries don't contain that dependency. As a result, attempts to load those libraries dynamically (say, into Numerical Python) fail when the dependency is triggered. *** there is no dependency on libf2c: nitrox:Test$ ldd /usr/lib/libblas.so.2 libm.so.6 => /lib/libm.so.6 (0x40074000) libc.so.6 => /lib/libc.so.6 (0x40091000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) nitrox:Test$ ldd /usr/lib/liblapack.so.2 libblas.so.2 => /usr/lib/libblas.so.2 (0x403b1000) libm.so.6 => /lib/libm.so.6 (0x40424000) libc.so.6 => /lib/libc.so.6 (0x40441000) /lib/ld-linux.so.2 => /lib/ld-linux.so.2 (0x80000000) *** yet, libblas depends on the symbol e_wsfe, defined in libf2c nitrox:Test$ nm -o /usr/lib/libblas.so.2 | grep e_ws /usr/lib/libblas.so.2: U e_wsfe nitrox:Test$ nm -o /usr/lib/libf2c.so.0 | grep e_ws /usr/lib/libf2c.so.0:0000e670 T e_wsfe /usr/lib/libf2c.so.0:00007de0 T e_wsfi /usr/lib/libf2c.so.0:0001055c T e_wsle /usr/lib/libf2c.so.0:00008068 T e_wsli /usr/lib/libf2c.so.0:0000ea68 T e_wsue nitrox:Test$
Actually, this isn't from the libf2c but from the libg2c which is part of the g77 compiler and automatically used by it for compiler-internal symbols.