I'm re-adding the CC to the list and quoting liberally to preserve the context for other readers.
"Yang Tse" <[EMAIL PROTECTED]> writes: > Just for future reference: "relocation R_X86_64_32 can not be used > when making a shared object" error message is related with this thread > > 2007/3/29, Simon Josefsson <[EMAIL PROTECTED]> wote: > >> I believe this is the wrong solution -- you shouldn't be mixing static >> libraries (non-PIC) with shared libraries (PIC). Either use the >> shared PIC library of libssh2, or build libssh2 using './configure >> --with-pic'. > > I'll try to be gentle. > > I'm not mixing anything. It will be the users of libssh2 which at some > point will be doing it. > > Users are fond of building several static libraries and finally > wrapping or linking all or some of them in a DSO. In this case, on > platform x86_64 those static libraries must be built with PIC. It is > the only way to do it, there is no other option. If it is not done, > they will get error messages as the top posted one. I understand, but there is a good solution to that problem: educate users that they shouldn't link together static and shared libraries. It isn't portable to do so, and on some platforms you can't do it even if you only use PIC-code. If the users don't want to be portable (which some users don't care about, and is sometimes reasonable), they can build libssh2 with `./configure --with-pic'. >> If we install this, it will make all x86_64 libssh2.a files be >> compiled with PIC information, which is unnecessary and will slow >> things down. > > For the case that I've said above, it isn't a matter of being > necessary or not, it is the only option. I believe the options are: 1) Apply the patch. This causes libssh2.a to be PIC only because some users doesn't care to do things in a portable way. 2) Ask users that don't care about portability, and wants to mix static and shared libraries anyway, to build libssh2 --with-pic. That is a standard ./configure option with libtool and is documented. 3) Create a libssh2_pic.a static library with PIC code. There is some tradition in that solution, since there are some rare situations where the best compromise is to link static and shared libraries (I believe the canonical example is libflex). This solution is more reliable than both 1) and 2). I don't know how to implement 3) easily. Possibly libtool should be extended with that capability. > Regarding the slow down you mention..., that is old knowledge which > applies to i386 and other ancient platforms. Facts change. Not too > much time ago we all thought that the earth was flat, and now most > think that the speed of light is the maximum speed, but that might > also change in the future and prove all of us wrong. > > Some compilers are generating PIC code for static libraries and all > code on x86_64 without user choice to avoid this problems. > > I'm not interested in keeping alive this thread. The fix has been > posted and it could be used at any time. Or not. /Simon ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys-and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ libssh2-devel mailing list libssh2-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/libssh2-devel
