I've got a moderate sized shared library of C++ code, which only has about 25 'extern "C"' functions which are its public interface. None of the C++ code is intended to be used by users of the library. Normally, in the interests of getting C code optimized as heavily as possible when it is spread across multiple source files, I compile all the source files together using '-combine -fwhole-program', and annotate the functions that should be visible in the resulting binary with the "externally_visible" attribute. This works quite well and has resulted in faster/smaller code in a number of cases where we couldn't achieve it before without actually combining the code into a single source file and explicitly marking non-exported functions as 'static'. Now I'm trying to do this with C++ code, and I have run into a stumbling block. I'm compiling using gcc 4.4.1 on an x86-64 system, and since the goal of this is a shared library, I'm compiling with -fPIC as well. This step is actually to produce a single .o, which is later linked with another .o to create the .so shared library. When I specify -fwhole-program for this compile, gcc ends producing R_X86_64_PC32 relocations, which causes the linker to fail and tell me to recompile with -fPIC... which I did in the first place. Removing -fwhole-program resolves this problem, but of course won't produce as much optimization as I'm looking for. Is there some inherent reason why -fPIC and -fwhole-program are incompatible for C++ code? If not, I'll try to produce a test case. -- Kevin P. Fleming Digium, Inc. | Director of Software Technologies 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA skype: kpfleming | jabber: kpfleming@xxxxxxxxxx Check us out at www.digium.com & www.asterisk.org
