Re: Library path, and related stuff

["Ronald F. Guilmette" <rfg@xxxxxxxxxxxxxxxxx>]

In message <201012101025.31369.asn@xxxxxxxxxxxx>, you wrote:

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

I will send you patches, if we can agree on what should be done.  (But I
get the impression from the rest of your message that perhaps that is
not immediately possible.)

>> 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.

>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 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.

>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?

>>    ... 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?

>... and what the problems are if you do that.

Problems such as what, exactly?

>> 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.

I'm sorry, but I have to disagree.  I've looked at the code in libssh.h
and it can be trivially modified so that in the case where the compilation
environment is *NIX, no special -D options would need to be fed to the
compiler for static versus dynamic.

You already have a section of the code there that is set aside for the
non-windows/non-cygwin case:

  #if defined _WIN32 || defined __CYGWIN__
   ...
  #else
    #if __GNUC__ >= 4
      #define LIBSSH_API __attribute__((visibility("default")))
    #else
      #define LIBSSH_API
    #endif
  #endif

OK, so changs may be made just in this part of the code and they will not
have any negative effect upon the stuff in libssh.h that's dedicated to
handling the Windows case.  (And indeed, that is what both the FreeBSD
port maintainer and I have both already done, i.e. in our own copies of
the libssh.h header.)

>>    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.

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).

   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.)

   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.)

All three of the above are provably false, but I do not anticipate that I
will be able to convince you of any of them, because you are clearly operating
under the influence of some rather bizzare preconceptions which, not knowing
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.

>Feedback is always welcome.

It would appear not, but that's OK.

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.)

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.


Regards,
rfg