Mailing-List: contact cygwin-apps-help AT sourceware DOT cygnus DOT com; run by ezmlm
Sender: cygwin-apps-owner AT sourceware DOT cygnus DOT com
Message-ID: <39255FEB.7DB06733@ece.gatech.edu>
Date: Fri, 19 May 2000 11:38:19 -0400
From: "Charles S. Wilson" <cwilson AT ece DOT gatech DOT edu>
MIME-Version: 1.0
To: Chris Faylor <cgf AT cygnus DOT com>
CC: earnie_boyd AT yahoo DOT com, cygwin-apps AT sourceware DOT cygnus DOT com
Subject: Re: NCurses-5.0
References: <20000518185546 DOT 12950 DOT qmail AT web106 DOT yahoomail DOT com> <3924624A DOT AD1DCC71 AT ece DOT gatech DOT edu> <20000518185659 DOT D18477 AT cygnus DOT com>
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit


Chris Faylor wrote:
> 
[snip]
> >
> >I have no objections to maintaining it, but there are a few issues to
> >work out first. I think it has external dependencies (gettext? readline?
> >or was it the other way around...) and I'd like those to be dll-based
> >for easy upgradability. Then there's that whole .dll.a versus _s.a
> >issue. And binutils, gcc, ...
> 
> I wouldn't worry too much about external dependencies.  It might be
> better to just get the library released and let people worry about where
> to get the rest of the dependencies.  Unless that would put is in
> violation of the GPL...
> 
> I don't have much of an opinion on the .dll.a versus _s.a stuff other
> than the point that I made earlier that it is possible to have a .a file
> that is both stub library and "static" library.
> 

But in that case, it does have an associated DLL, so in one of the
proposed naming schemes it should be called .dll.a. Now, that would
break LOTS of things (libcygwin.a comes to mind) unless binutils
automagically looked for libfoo.dll.a when -lfoo. (which it will not do
even with my current and my pending[*] binutils changes, if the user
specifies -static/-Bstatic flags).

If there is ONLY a import lib and no static lib, then the link will fail
since ld won't look for .dll.a if the user specifies -static/-Bstatic.
So, the best solution is probably to symlink libfoo.a -> libfoo.dll.a.
This way, the naming makes it clear that it's an import library, and
since there's no static library we insure that linking will just work.
Principle of least surprise: linking happens, but the link IS dynamic
since there's no static library -- but the relationship is made clear in
the filesystem by an explicit symlink, not by funny extra hacks to
binutils.

[*] pending: hack up ld to also look for .dll.a, not just .dll, when
trying to link -Bdynamic, before falling back to .a.

FWIW, my binutils/gcc changes affect three "target" files (ld.exe,
specs, and collect2.exe) and three source files
(binutils/ld/emultempl/pe.em, gcc/collect2.c, and
gcc/config/i386/cygwin.h). In the short term I can distribute those via
a source patchfile + orig source and quickie 'overlay' binary tarball on
CygUtils, until the next 'official' cygwin release of binutils and gcc.
This way, people can experiment immediately with the new scheme --
whatever we decide the new scheme should be. 

> If this can be resolved soon, then we should wait.  Should we put it up
> for a vote?  Or is cygwin-apps too new for this to be useful?
> 

I dunno -- I've seen posts from exactly six people on cygwin-apps. How
many are subscribed? Perhaps at this early stage, we could put something
on the main cygwin list:

-------------
cygwin-apps needs your help and your vote; please read the following
threads on cygwin-apps:
'[general] some ideas & request for comments (LONG)'
'Re: Shared vs Static [WAS: Re: [general] some ideas & request for
comments (LONG)]'
'Vote: library naming scheme'
The archives are here: http://.....
Then, please post a reply to the thread 'Vote: library naming scheme' on
cygwin-apps with your opinion on the following questions:

1. How should static libraries and import libraries be named? One of the
following:
< various schemes + 'other' >
2. If import libraries have a suffix that is different from static
libraries (e.g. .dll.a), should the linker 'know' about that, or should
the user specify '-lfoo.dll' when linking to libfoo.dll.a? 
3. If static libraries have the "special" suffix (e.g. _s.a), should the
linker 'know' about that, or should the user specify '-lfoo_s' when
linking to libfoo_s.a?

Note: your answers to (2) and (3) may be different.

Thanks for your help!
-------------

Of course, we need to start the 'Vote: ' thread before doing this. <g>
I'll compose the appropriate messages if you want.

This would (a) help decide the current issue and (b) maybe get more
interested parties subscribed to cygwin-apps.
 
> >OTOH, I can go ahead and release a basic ncurses (static only) right
> >away using Earnie's patches, and then update & fix later. I just fear
> >that will lead to a bunch of hard-to-upgrade packages being released
> >that depend on ncurses, and are statically linked to this 'old' version.
> 
> Decisions, decisions.  How about waiting at least a week?

Not a problem. I'll be traveling May 27--June 1, so I suspect I won't be
able to do anything until early June anyway.

> 
> >Also, I seem to remember some discussion about 'SIGWINCH' on the list;
> >should --enable-sigwinch be used when configuring ncurses? Also, I
> >assume that --enable-symlinks should be used since otherwise, tic will
> >try to use hardlinks which aren't supported.
> 
> I *think* that SIGWINCH should work.  And, your point about
> --enable-symlinks is correct.  Hard links work on WNT but not on W9x.
> 

Good to know. Thanks,

--Chuck