Re: Library path, and related stuff

[Aris Adamantiadis <aris@xxxxxxxxxxxx>]

Hi Ronald,

I'd like to give a little contrast from Andreas' view. He is responsible
for the build process but of course it's a common choice.

>>> 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.
> 
> That's you choice, of course.  I'm just telling you that it flies in the
> face of 30+ years worth of well established conventions.

It seemed to me that the name of the static library was choosen that way
because of technical problems withing cmake to make it named libssh.a ;
at least that was the reason I heard at that moment.
As a LGPL software, we indeed find that giving a way to statically link
libssh is dangerous for software authors who don't read their licenses.
They are far more numerous that you'd think, but you're right it's not
to us to judge if they have or not to use static linking.

> 
>> 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.
This is a misconception. Linking with GPL doesn't make your code GPL ;
it makes the distribution of that mix in a binary-only product illegal.
In analogy, statically linking with a LGPL software and not releasing
source and/or a dynamically linked equivalent is a copyright infringement.
> 
> This is a contractual matter and people who ship products based on copylefted
> code are, I think, sure to read the relevant licenses before they ship their
> products.  That only makes sense.
> 
> In short, I don't believe that there is any good basis for assuming people
> who write code which is supported by one or more LGPL libraries are stupid.
> 
They are not stupid, they are uninformed of the open source world. And I
swear I've seen a lot of libssh code in proprietary softwares.

>> The other is that you shouldn't link statically against libraries for security
>> reasons.
> 
> Come again??
> 
> No offense intended, but where exactly did you get this novel idea?

Statically linking a library in your soft is the best way to be sure it
won't get patched next time a vulnerability has been found and fixed
upstream. It happens every 6 months when a problem is found in zlib, and
it takes 2 years before half of the proprietary softwares update.

Well, once again, good reason not to statically link, but not a good
reason to avoid it.

> 
>>>    ... 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...
> 
>> 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.
> 
> What do yu define as a "switch in the Makefile" exactly?
> 
> Does't this qualify?
> 
>    LDFLAGS = -static
> 
>> It should be clear that you link against the static version...
> 
> Does the above simple Makefile line somehow cause that to be less than
> clear...  I mean to an experienced developer?
> 
Wasn't what pkg-config tool was meant to resolve ? i.e. helping
developers to resolve the madness to compile with stuff largely more
complicated than a ssh library.

>>> 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.
>>
I was not aware of that issue. I noticed libssh got compiled twice, but
figured that was normal because dynamic and static binaries are different.

But clearly, for me here there's something to resolve. It's not normal
to have to do a #define for something that clearly is a linking issue.
If that's needed for windows, let's then make it an exception for it.

> 
> You have suggested three reasons who it might be good to make linking with
> the static version of the library annoyingly non-standard, none of which
> are, in my opinion, valid, if considered carefully and without preconceptions:
> 
>    1)  That forcing developers to learn some new non-standard linking hacks
>        which they are then obliged to introduce into their Makefiles is a
>        Good Thing because it makes them think about software licensing
>        issues (where ostensibly, they would not otherwise do so).

Try to link with something like gtk, gnome, QT or kde and feel the pain.
I think the jar is already broke and we did not do it.

> 
>    2)  That for some unspecified reason, people have to be warned off from
>        EVER linking anything statically for some unspecified ``security 
>        reasons''.  (Whereas in point of fact, that's actually bass-ackwards...
>        the greater security risk quite obviously comes from linking against
>        dynamic libraries whose functionality can change ``out from under''
>        the application code that uses them, thus introducing all manner of
>        subtle bugs, including many unforseen security issues.)
>
Introducing genuine and subtle bugs is for me less of a problem that
leaving in known, fixed, documented and exploited bugs. But that's an
other discussion.

>    3)  That it is not possible to correct the small annoyance in libssh.h
>        that causes people to actually have to RECOMPILE their entire appli-
>        cations, when in fact, all they really wanted to do was to change
>        the LINKING method.  (I believe that I have shown above that this
>        is simply not true, at least for the *NIX case.)
> 
Agreed with this one.

So, to get short :
 1- you want libssh-static.a renamed to libssh.a; We'll see if there are
technical problems that won't let us provide both libssh.a and
libssh-static.a (with a symlink between them for instance).
 2- You want to remove the #define needed to compile libssh statically.
I agree with it and will discuss with Andreas how to resolve it, and
document it correctly for the exceptions.

> you personally, or your experience, I can only surmise are due in whole or
> in part to the well-known debilitating effects of prolonged exposure to
> Windows.
Haha :) The little bits I've done with windows tell me that each time
you've got a conception of how a thing should be done (like on Unix), it
simply doesn't work and have to hack your way.
Yes, getting something as simple as snprintf() work on windows is pain.

> 
>> Feedback is always welcome.
> 
> It would appear not, but that's OK.
> 
Trying to formulate a clumpsy explanation on why we implemented it that
way is not a sign we do not appreciate feedback.

> For whatever it's worth let me assure you that you are by no means the only
> software developer, either now or throughout history, who is or who has been
> completely convinced that everything he's done is perfect and correct despite
> all evidence to the contrary.  (I have known many others myself, and also have
> been such, on many an occasion myself.)
> 
BSD vs (L)GPL ?

> With that I take my leave, thank you again for sharing your code, and wish
> you all the best.  Between myself and the FreeBSD port maintainer we have
> managed to overcome its foibles, and that's enough for us.
> 
Thanks for maintaining our software on FreeBSD, it's very rewarding for
us to have our code part of a bigger thing.

Kr,

Aris