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)();
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
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
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