Library path, and related stuff

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

Hello all,

I got on this mailing list awhile back for one reason and one reason only.
Unfortunately, because I have been repeatedly distracted by other projects,
I have never quite gotten 'round to doing what I came here to do.

Well, I'll give it a try now, since it seems like things very directly
related to my goal in getting on this list are under current discussion.
(And I must apologize that I haven't actually followed the whole discussion.)

I got onto this list to fulfill a promise I made to the guy who maintains
the FreeBSD port of libssh.

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.

OK, so here is the deal... In the first place, on FreeBSD, up until
recently, the FreeBSD port of libssh was not even building or installing
a static version of the library... only a dynamic one.  The FreeBSD
maintainer kindly arranged for me that the FreeBSD port of libssh would
henceforth build & install both, so that made me a happy camper.  (I
like to link static, when debugging, because gdb doesn't always seem to
do the Right Thing when dealing with dynamically linked libraries.)

Anyway, after the FreeBSD maintainer took care of that small detail,
two other minor annoyances... and, I might say, two other minor deviations
from existing norms & conventions... became apparent.  And those are
what I really want to talk about here.  Briefly, the two issues are these:

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

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

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.

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

   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.

My apologies to everyone here if the two points I have belabored above have
already been discussed within the recent threads that seem to relate to this
stuff.  (I'll confess again that I have only been skimming, and haven't really
delved down into the meat of the recent postings... a personal failing for
which I humbly apologize.)


Regards,
rfg