On Sun, Jan 25, 2009 at 11:38:48AM +0100, Jean-Daniel Dupas wrote:> > Le 25 janv. 09 à 06:01, Jack Howarth a écrit : > > > After trying the recommended use of -O4 -fvisibility=hidden to > > compile xplor-nih with full LTO optimizations, I discovered three > > symbols become undefined... > > > > llvm-gcc-4 -O4 -fvisibility=hidden -o xplor xplor.o \ > > \ > > -L. -lxplorCmd -lxplor -L/Users/howarth/xplor-nih-2.21/ > > bin.Darwin_9_x86/ -lfft -lintVar -lvmd -lpy -lswigpy-xplor - > > ltclXplor -lswigtcl8-xplor -lnmrPot -lcommon -lmarvin \ > > -lcrypto -L/sw/lib/llvm-gcc-4.2/lib -lgfortran -llapack - > > lblas -L/Users/howarth/xplor-nih-2.21/bin.Darwin_9_x86/ \ > > > > Undefined symbols: > > "_xplorwrapproc_slave_", referenced from: > > llvm bitcode in xplor.o > > "_python_interp_", referenced from: > > llvm bitcode in xplor.o > > "_tcl_interp_", referenced from: > > llvm bitcode in xplor.o > > ld: symbol(s) not found > > > > These are all defined as extern as follows... > > > > extern "C" void > > FORTRAN(tcl_interp) (const long& canReturn, > > long& qterm, > > long& fd) > > > > extern "C" void > > FORTRAN(python_init)(const long& argc, > > char** argv) > > > > extern "C" void FORTRAN(xplorwrapproc_slave)(); > > > > defining them as extern is not enough to mark them as "exported". > > You should use the visibility attribute. > > extern "C" void FORTRAN(xplorwrapproc_slave)() > __attribute__((visibility("default"))); > > > The only symbols that become undefined are those extern > > symbols which calling fortran routines from c++ code. > > I'll look into creating a testcase and opening a PR for > > this issue. > > Jack > > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevJean-Daniel, Doing that changes the error messages into a bus error on the darwin linker. I'll try using -fvisibilityhidden first with current gcc trunk's compilers and come back to llvm-gcc4.2 later. I noticed that there are known issues with using -fvisibility with fortran... http://gcc.gnu.org/bugzilla/show_bug.cgi?id=35827 I have removed all of the -fvisibility=hidden flags from the gfortran compiles but wonder if this is still an issue since the fortran calls are being accessed from c++ files with the -fvisibility=hidden flag in use. Perhaps PR35827 also includes fortran calls in c++ not understanding the use of -fvisibility as well as fortran code itself. Jack
Hi Jack, On Jan 25, 2009, at 10:00 AM, Jack Howarth wrote:> Doing that changes the error messages into a bus > error on the darwin linker.Pl. file bugzilla report (or radar) with a reproducible test case so that we can investigate this linker crash. As you know, one way to control symbol visibility is to use gcc's (inherited by llvm-gcc) visibility support. GCC supports, 1) command line options 2) attributes and 3) pragmas in this regard. Following document provides good summary... http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html#/ /apple_ref/doc/uid/TP40001670 Another way to control symbol visibility is to use linker's interface. See ld man page for more info on -exported_symbols_list, - exported_symbols, -unexported_symbols_list etc.. flags. If you're going to try this approach, pl. read ld man page first. - Devang
On Mon, Jan 26, 2009 at 09:57:28AM -0800, Devang Patel wrote:> Hi Jack, > > On Jan 25, 2009, at 10:00 AM, Jack Howarth wrote: > > > Doing that changes the error messages into a bus > > error on the darwin linker. > > > Pl. file bugzilla report (or radar) with a reproducible test case so > that we can investigate this linker crash. > > As you know, one way to control symbol visibility is to use gcc's > (inherited by llvm-gcc) visibility support. GCC supports, 1) command > line options 2) attributes and 3) pragmas in this regard. Following > document provides good summary... > > http://developer.apple.com/documentation/DeveloperTools/Conceptual/CppRuntimeEnv/Articles/SymbolVisibility.html#/ > /apple_ref/doc/uid/TP40001670 > > Another way to control symbol visibility is to use linker's interface. > See ld man page for more info on -exported_symbols_list, - > exported_symbols, -unexported_symbols_list etc.. flags. If you're > going to try this approach, pl. read ld man page first. > - > Devang > > > > _______________________________________________ > LLVM Developers mailing list > LLVMdev at cs.uiuc.edu http://llvm.cs.uiuc.edu > http://lists.cs.uiuc.edu/mailman/listinfo/llvmdevDevang, I was surprised to discover that I could build all of pymol with -fvisibility=hidden using gcc 4.4 or llvm-gcc-4.2 with only a single header change... --- pymol-1.1/layer4/Cmd.h.orig 2009-01-30 18:58:58.000000000 -0500 +++ pymol-1.1/layer4/Cmd.h 2009-01-30 19:00:17.000000000 -0500 @@ -18,7 +18,8 @@ #include"os_python.h" -void init_cmd(void); +void init_cmd(void) +__attribute__((visibility("default"))); extern PyObject *PM_Globals; One of the advantages of running as a python module I guess. I was also able to build pymol with -O4 using the llvm 2.5 libLTO.dylib so that full Link Time Optimizations were performed. Everything compiled and linked fine. The resulting pymol runs its demos without regressions. Nice. Jack