Hallo All!

After some months in which I was heavily distracted from fidonet, I today
was called back by an e-mail stating that the hard disk of my fido node has
run full ;-). After fixing this, I decided to again set up a fido point on
my notebook, and so I tried to compile current husky from CVS under cygwin
with gcc and huskymak.cfg today. That failed, however.

If I set DYNLIBS=1, huskylib.dll builds fine, but when smapi.dll is going
to be built (gcc -shared ... -o smapi.dll.version ...), I get errors about
unreferenced symbols (these are the symbols that are in huskylib.dll). I
think this is an error in cygwin, not in husky.

But if I set DYNLIBS=0, there are definitely bugs in Husky that make the
build process fail. At first, it builds LIBHUSKYCYG.LIB, which really
should be LIBHUSKY.A (or maybe LIBHUSKY.LIB, but not LIBHUSKYCYG.LIB!),
then it builds LIBSMAPICYG.LIB, but when building fidoconfig, the build
process fails for tparser, because it tries to link smapi as
"../huskylib/libhusky.a", and even if I skip tparser, I then
can't build hpt because hpt (CORRECTLY!) tries to link the libraries with
"-L/usr/local/lib -lhusky -l smapi" and of course does not find
anything because the libs have the "cyg" suffix in their name.

I remember that already more than two years ago we agreed on the following:

1. Library names like "libsmapiXXX.a/lib", where XXX is
"cyg", "emx", "bcc", "unx" or
anything, are for use by the LEGACY MAKEFILES (that don't use huskymak.cfg)
only. I used them for building static binaries of msged and cfroute, and I
suppose noone else ever needs this, so we could just drop it.

2. Static libraries should be named "libsmapi.a" or
"libsmapi.lib" and so on, WITHOUT a operating system specific
subject, and should be installed to /usr/local/lib ( or whereever LIBDIR)
points to.

And likewise:

3. The technique of linking a library by using relative paths in the build
directory (../husky/libhusky.a) is again ONLY for use by the LEGACY
makefiles, because the LEGACY makefiles (only) don't have an install target
that could install the library to a place where they can be found with
"-l".

4. But for the huskymak.cfg build process, we do a "make install"
for each library (even if we have DYNLIBS=0), and so, libraries should be
linked with "-L$(LIBPATH) -lsmapi -lhusky -lfidoconfig". THIS IS
IRRESPECTIVE of whether dynlibs or static libs are used - as long as the
right files are in $LIBDIR, the linker will use them, and you can force
non-dynamic linkage with the "-static" compiler option.

We had a setup like this while I was maintaining the source; by now it has
obviously been broken :-(.

I did not start commiting fixes that re-establish the old scheme because I
have not been following the discussions in this echo recently. Before I
start doing this, I want to ask the current developers: Do you still agree
with the philosophy I pointed out in 1. until 4.? IMO, we can again reach
this state without affecting the DYNLIBS=1 case, it would just be a fix for
DYNLIBS=0. 

Would somebody of you open a "bug" at sourceforge and start
fixing the libraries? (I really have no time to do it - but I might try if
noone else does it, IF you allow me to again establish the philosophy as
outlined above).

Oh, and do the "real" developers read this echo at all, or have
all dicussions move to RU.HUSKY (in that case, please say so, and I'll post
again in Russian) or to the internet?

Regards,
Tobias.

--- Msged/BSD 6.1.1 (NetBSD/1.4 (alpha))