Re: NCurses-5.0

[Earnie Boyd <earnie_boyd at yahoo dot com>]

--- "Charles S. Wilson" <cwilson@ece.gatech.edu> wrote:
-8<-
> 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. 
> 
-8<-

Paul Sokolovsky has this nice a2dll script to create a dll from a static lib. 
I've been playing with it today with readline-4.1 and have found it to be
useful.  I modified his naming scheme so that the static library becomes
libfoo_s.a, libfoo.a is a symbolic link to foo.dll and libfoo.dll.a is the
import library.  I don't know that this is the best idea yet.  With the
symbolic link the linker builds the executable but the executable just exits
without doing anything.  With using the dll directly, ie specifying
readline.dll on the command line as an input file, the linker builds the
executable but some of the examples stackdump, some of the examples complain of
missing routines and some work.  They all work with the static library of
course.

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

As long as it works, makes life easier to have a choice of static versus
dynamic, and is close to what people are used to in unix I don't think anyone
is going to complain.

How about using this naming scheme?  It looks right and comes close to being
"real".

libfoo.a == static library
libfoo.so == sybolic link to foo.dll
libfoo.dll.a == import library

Chuck, I'm willing to test your binutils changes.  Just let me know where I can
find a distro.

Cheers,

=====
---
   Earnie Boyd: <mailto:earnie_boyd@yahoo.com>
            __Cygwin: POSIX on Windows__
Cygwin Newbies: <http://www.freeyellow.com/members5/gw32/index.html>
           __Minimalist GNU for Windows__
  Mingw32 List: <http://www.egroups.com/group/mingw32/>
    Mingw Home: <http://www.mingw.org/>

__________________________________________________
Do You Yahoo!?
Send instant messages & get email alerts with Yahoo! Messenger.
http://im.yahoo.com/