I'm re-adding the CC to the list and quoting liberally to preserve the
context for other readers.
"Yang Tse" <yangsita_at_gmail.com> 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 <simon_at_josefsson.org> 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_at_lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/libssh2-devel
Received on 2007-04-05