We may need a better description of what you mean by "a particular file's functions are not called".
But it brings to mind an issue some of my coworkers struggled with when porting a .dll from Windows into a .so for Linux:
If a function is both called in a .dll and defined in that .dll then the instance of that function defined in that .dll is the instance of that function that will be called by that .dll. That is the behavior our software wanted.
But if a function is both called in a .so and defined in that .so and some other instance of a function with the same name is loaded earlier, then that other instance of the function will be used.
To my limited understanding of the relative behavior of the linkers: Linking a DLL on Windows defaults to resolving local to the DLL anything that can be resolved local to the DLL and importing/exporting only those things it needs to and/or is told to. But linking a .so in Linux defaults to importing/exporting anything it can, so a lot more can change at load time.
If that isn't your issue, sorry I jumped in.
If that is your issue, hopefully someone with better understanding of the GNU linker will tell us both how to get better control of linking a .so to force some (for me almost all) symbols to be resolved with finality at link time and not left open for the loader.
Last edited by johnsfine; 02-21-2008 at 03:16 PM.