[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Library path, and related stuff

On Thursday, December 09, 2010 23:03:45 you wrote:
> Hello all,

Hi Ronald,

> Basically, a month or so ago I asked him to make three small but important
> changes to the FreeBSD port of libssh, and he did make all three of these
> small changes, but he requested that I also try to get the actual libssh
> developer(s) to make the last two of these small changes also in base
> sources for libssh.  I promised that I would make an ernest effort in that
> direction.

thanks for your mail and the thoughts.

If libssh should work on your platform there are two possibilites. You send us 
patches for the platform, or you setup a nightly build.

We have a testing system on http://test.libssh.org/

All you have to do is to call ctest once a day. If we break something we will 
be informed immediatley and can fix it. 

> 1) The name of the library that one links against... i.e. the thing that
>    follows the -l option on the compiler (or linker) comand line... is
>    DIFFERENT for the static versus the dynamic version of the library.
>    This breaks longstanding norms and conventions on *NIX systems, where
>    the tradition/standard is that only the suffix of the library filename
>    differs between the static & dynamic versions (.a versus .so).

There are several reasons for this. We wanted to make clear that you're 
linking against the static version of libssh.

One reason is that libssh is a LGPL library, so if you create an application 
and you link it statically against a LGPL library your application will be 
LGPL too.

The other is that you shouldn't link statically against libraries for security 

>    This may not seem like a big thing, and maybe it isn't, but intutively,
>    if one is hacking on a Makefile for something, the existing tradition
>    and practice is and has been that to change linking to static versus
>    dynamic (or vise versa) all one should have to do is to add (or remove)
>    e.g. the gcc "-static" option to LDFLAGS.  No other changes to the
>    Makefile should be necessary.  And as a general rule, with the exception
>    of libssh, the base names of static & dynamic versions of 100% of the
>    libraries I have ever worked with in my entire time working on *NIX
>    systems have always been the same.  Alas, that is not true currently
> with libssh, and so I just want to request that this small quirk get fixed
> in the base sources.  (The maintainer of the FreeBSD port of libssh has
> kindly implemented a temporary work-around for this small problem until it
> can be fixed in the base sources.)

Well if I want to link against a static library I would create a switch in the 
Makefile instead of modifying it all the time. It should be clear that you 
link against the static version and what the problems are if you do that.

> 2) In a similar vein, as I noted above, the general rule... on *NIX systems
>    at least... has always been that one can change from dynamic to static
>    linking JUST be adding or deleting a single well-known compiler option
>    to or from LDFLAGS.  (For gcc this is the -static option.) 
> Unfortunately however, at present it appears that if one wants to change
> from linking with libssh dynamically to linking with libssh statically,
> one actually has to RECOMPILE everything that was compiled with the
> libssh.h header file, this time doing it with the special magic
> -DLIBSSH_STATIC compile- time preprocessor define.

libssh is a muilti-platform library. It is not only available on *NIX system 
you can use it on Windows too. To get it working correctly as shared and 
static library on all platforms this is required.

>    Here again, this clashes with much existing practice and convention.  I
>    don't really know anything about how things are typically done on
> Windows, but on *NIX systems, as I've said above, the
> tradition/convention/standard has always been that when you want to change
> to static linking, from dynamic, or vise versa, you should only have to
> add or remove some single flag from LDFLAGS in your Makefile.  And
> certainly you should NEVER really have to recompile anything.  (I mean
> after all, you are really only changing the way stuff is linked, not what
> the compiled code actually does.)

Yes, it is our intention that this is not the default cause we want to make 
clear what you are doing if you link against a LGPL library. I will start to 
document this and the reasons.

>    So anyway, the FreeBSD maintainer of libssh also put in a temporary
> work- around for this small quirk of libssh too... and I have thanked him
> for that, and promised to see if I could entice the maintainer(s) of the
> base sources to make a similar fix in those.

> Obviously, my hope is that the libssh maintainer(s) will fix both of the
> above two minor quirks in the libssh sources so that on *NIX at least, this
> wonderful and useful library can be used in a normal and intutive way that
> is consistant with traditions, standards, and normal practice.

If this is a big problem for more people than we can think about changing the 
static libray name. The define is still required.

Feedback is always welcome. At least it shows that there is a lack of 
documentation how to link libssh against your application.


	-- andreas

Re: Library path, and related stuff"Ronald F. Guilmette" <rfg@xxxxxxxxxxxxxxxxx>
Library path, and related stuff"Ronald F. Guilmette" <rfg@xxxxxxxxxxxxxxxxx>
Archive administrator: postmaster@lists.cynapses.org