From: Sam S. <sd...@gn...> - 2009-08-14 14:23:35
|
Bruno Haible wrote: > Sam wrote: >> -fPIC is used for DYNAMIC_MODULES and only for the modules code, not for the core. > Yes, it is on purpose. -fPIC is only needed for code in shared libraries. the idea (see clisp/src/TODO) is to replace lisp.run and lisp.a with lisp.so and have the driver clisp load base/lisp.so and the applications embedding clisp link against lisp.so instead of lisp.a >> is it OK to compile core with -fPIC? > > It's possible. Last time I measured it, it caused a performance decrease of 17%, > on x86. You have to know that position-independent code means that every access > to a global variable needs special code so that the access goes through %eip. this pretty much kills the idea. however, these 17% looks like a lot - if it were true, people should have screamed about it it should have been fixed. >> 1. creating lib-rawsock.dll on win32 fails with may errors about >> undefined reference to `_STACK' > > This is normal: STACK is a normal variable, and you did nothing particular to > export it from the lisp executable. In lispbibl.d I see only > extern gcv_object_t* STACK; > and no use of __declspec(dllexport). Recommended reading: [1] this basically kills c++ compilation, right? >> 2. creating lisp.dll fails with >> "relocation R_X86_64_32S against `modules' can not be used when making a shared >> object; recompile with -fPIC" > > Now this is about -fPIC indeed. When you create shared libraries from .o files, > the .o files *must* be compiled in PIC mode. On some platforms (such as AIX and > BeOS), all code is compiled in PIC mode, so it's a no-brainer on these platforms. looks like win32 is always PIC, so this is OS-dependent, not arch-dependent: dirkey.m.c:1: warning: -fPIC ignored for target (all code is position independent) BTW, why does win32 insist on all library dependencies to be mentioned on the command line? e.g., on linux, this works (foo.c calls cos): $ gcc -shared -o foo.so foo.o but on win32 I have to write $ gcc -shared -o foo.dll foo.o -lm > On other platforms, like Linux/x86, the linker does not warn when you put > non-PIC objects into a .so - simply the loading time of the .so will be > unproportionately high. But everywhere else, it is mandatory to compile object > files twice, once without -fPIC, for use in a clisp executable, and once with > -fPIC, for lisp.dll. The naming convention for lisp.a thus created could be > "lisp_static.a" and "lisp_static_pic.a". but why would I want to create lisp.dll if it is 17% slower?! > Btw, I hope you are creating your DLLs with libtool? no, I use XCC_CREATESHARED in makemake.in > libtool is a pain to use, > but everything else is a Royal Mess. I don't see the usefulness of libtool. it appears that it only supports gcc: $ libtool --mode=compile gcc -g -O -c hello.c what if I am not using gcc? what if I am not using C? The manual mentions C++, but I also have lisp code to compile. Sam. |