f2py and Symbol Tables (Part 2)

A Note on Object File Formats

Before we resume our discussion, I wanted to note that I intended to post Part 2 earlie. But as I was testing my code I realized that my "overloaded" symbol table example worked just fine on the Linux side without the --export-dynamic flag in Linux. It seemed necessary during my first test but the Hello/Goodbye example at the end of the last post ran as intended after I removed the flag.

Also, I'm very sure that -flat_namespace is indeed necessary for Darwin-based (read: OS X) systems. This is because Darwin uses the Mach-O object file format as opposed to Linux's ELF object file format. The difference between the two formats that is relevant to this discussion is that Mach-O objects have a two-level namespace. Basically, each symbol is encoded into an (object, symbol name) pair. When a symbol is requested, the corresponding object is first sought out and then the attached symbol.

Therefore, I believe that compilation error occurs in OS X when compiling the test_goodbye program because the linker is looking for the object containing the speak_ symbol in the library libgoodbye.dylib. However, that object doesn't exist in libgoodbye.dylib but rather in libhello.dylib. The two-level namespace is somehow preventing the linker from recognizing that it has to make it's way over to libhello.dylib to find the necessary symbol.

Next Time...

Since I have to get to work now, I'll post a Part 3 where I actually discuss symbol overloading with f2py. Until then, methinks I'll read up some more on object file differences just for fun.