This is the mail archive of the cygwin-announce@sources.redhat.com mailing list for the Cygwin project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

New on sources.redhat.com: ncurses-5.2-2


I've just uploaded ncurses-5.2-2 to sourceware.  ncurses is a package
that provides character and terminal handling libraries, including
'gui-like' panels and menus.  It is often used instead of termcap.

INSTALLATION:

To update your installation, click on the "Install Cygwin now" link on
the http://sources.redhat.com/cygwin web page.  This downloads setup.exe
to your system.

Run setup and answer all of the questions.  PLEASE, PLEASE, PLEASE
choose a mirror site for your download.  The 'sources.redhat.com' site
is badly overloaded.  The mirrors below have the latest version of this
package:

ftp://ftp.sunsite.utk.edu/pub/cygwin/ (US)
ftp://ftp.franken.de/pub/win32/develop/gnuwin32/cygwin/mirrors/cygnus/
(Germany)
ftp://ftp.ntua.gr/pub/pc/cygwin/ (Greece)

The setup.exe program will figure out what needs to be updated on your
system and should install the ncurses package automatically.

If you have previously installed the 5.2-1 test release of ncurses and
clobbered your original termcap.h and clear.exe files, then you need to
FIRST install the new ncurses-5.2-2, and THEN re-install the termcap
package and the clear package.  (e.g. remove the corresponding lines
from /etc/setup/installed.db and run setup again) 

If you have questions or comments, please send them to the Cygwin
mailing list at:  cygwin@sources.redhat.com .  I would appreciate if you
would use this mailing list rather than emailing me directly. This
includes ideas and comments about the setup utility or Cygwin general.

If you want to make a point or ask a question the Cygwin mailing list is
the appropriate place.

              *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO ***

If you want to unsubscribe to the cygwin-announce mailing list, look at
the "List-Unsubscribe: " tag in the email header of this message. Send
email to the address specified there.  It will be in the format:

cygwin-announce-unsubscribe-you=yourdomain.com@sources.redhat.com

NOTES:

o Building the package from source requires gcc-2.95.2-5 and
binutils-200001029-2 or later

o follows new naming scheme for dlls
   /usr/lib/libncurses.dll.a     (import lib)
   /usr/lib/libcurses.dll.a --> libncurses.dll.a
   /usr/lib/libpanel.dll.a       (import lib)
   /usr/lib/libmenu.dll.a        (import lib)
   /usr/lib/libform.dll.a        (import lib)

   /usr/lib/libncurses.a         (static lib)
   /usr/lib/libcurses.a     --> libncurses.a
   /usr/lib/libpanel.a           (static lib)
   /usr/lib/libmenu.a            (static lib)
   /usr/lib/libform.a            (static lib)
   /usr/lib/libncurses++.a       (static lib)

   /usr/bin/cygncurses5.dll      (dll) (**)
   /usr/bin/cygpanel5.dll        (dll) (**)
   /usr/bin/cygmenu5.dll         (dll) (**)
   /usr/bin/cygform5.dll         (dll) (**)

   cygwin-specific docs in /usr/doc/Cygwin/ncurses-5.2.README

  /usr/bin/*
     dynamically linked version of the utility programs
     also, the dll's
  /usr/bin/ncurses-stat/*
     statically linked versions of the utility programs
  /usr/bin/ncurses-test-dll/*
     dynamically linked versions of the test programs
  /usr/bin/ncurses-test-stat/*
     statically linked versions of the test programs

Note that libncurses++ is NOT provided as a dll/import lib.  More info
below.

(**) versioned dlls are the default; only extremely stable libraries
(like zlib) have unversioned dlls.  dll's are stripped.

o A cygwin-specific README and three PATCHES are stored in the source
archive, under <top>/CYGWIN-PATCHES/* (although the first patch,
ncurses-5.2-X.patch, has already been applied to the archive itself).
The cygwin-specific README is also installed by the binary distribution
as described above.

o There are actually three patches: one that is already applied in the
source archive ncurses-5.2-X-src.tar.gz.  It munges all the headers and
C files so that functions and variables are declared using <no special
__declspecs>, __declspec(dllexport), or __declspec(dllimport), as
appropriate, depending on -DNCURSES_STATIC / -DNCURSES_DLL / <no special
#defines>.  That patch is over 400k and has already been applied to the
archive.  The second, much smaller patch ('ncurses-5.2-X-dll.patch'),
contains the Makefile-specific changes necessary ONLY when building the
dll's and dll-dependent executable (this one must be applied only AFTER
doing a ./configure.  The third patch, 'ncurses-5.2-c++-dll.patch' is
not used -- it allows interested parties to build libncurses++ as a dll
(not currently functional).  See /usr/doc/Cygwin/ncurses-5.2.README for
more information.

o Full build instructions for building ncurses yourself are included the
ncurses-5.2.README file; overview only here:  The build procedure for
static libs is very straightforward.  However, building the dlls
requires an odd "./configure" THEN patch, then build sequence. 

o If you are building a package that depends on the ncurses library, and
you wish to link *statically*, define -DNCURSES_STATIC to get the
'correct' #define's in bzlib.h when compiling the .o files in your
package. Also, use 'gcc -static' when linking your package.

o Note that, since libncurses++ is only provided as a static lib, I made
things a bit easier: the c++ headers #define -DNCURSES_STATIC for you,
so you don't have to do so -- but ONLY when using with the c++ library. 
Also, since there is no implib/dll for the c++ library, you can even
omit -static when linking; the linker will only be able to find the
static lib and will link to it. You still have to #define
-DNCURSES_STATIC and use -static when linking statically to the
"regular" C libraries.

o No special -Ddefine options or link options are needed when building a
package that depends on the regular C libraries and you want to link
dynamically (recommended). 

o resolved the known conflicts.  Ncurses provides some files that
conflict with the files included in other packages.  Those conflicts
were resolved as follows:
    termcap package /usr/include/termcap.h
       resolution:  5.2-2 installs its termcap.h as termcapn.h
    clear package   /usr/bin/clear.exe
       resolution:  5.2-2 installs its clear.exe as clearn.exe
If you installed the 5.2-1 test release of ncurses and clobbered your
original termcap.h and clear.exe files, then you need to FIRST install
the new ncurses-5.2-2, and THEN re-install the termcap package and the
clear package.  (e.g. remove the corresponding lines from
/etc/setup/installed.db and run setup again)

o I gave up on building libncurses++ as a dll.  It doesn't work, and
needs serious help.  For those interested, I've put some further notes
below my signature line in this message.  libncurses++ is provided
solely as a static lib.  However, the other libraries (libncurses,
libform, libmenu, libpanel) are provided both as dlls and as static
libs. 

o updated the cygwin terminfo entry -- basically Earnie's "original"
version which appeared in 5.2-1, with some additional suggestions from
Ehud Karni:
  http://www.cygwin.com/ml/cygwin/2000-11/msg01007.html
point (2) only.  point (1) in that message is a cygwin issue (and is
probably a non-issue, according to JJ Farell): 
  http://www.cygwin.com/ml/cygwin/2000-11/msg01097.html
Comments concerning my test results with this terminfo entry appear
below.

o updated the rxvt terminfo entry with some changes from rxvt-2.6.3.

o added rxvt-xpm, rxvt-color aliases for rxvt in the terminfo database

o added rxvt-cygwin and rxvt-cygwin-native terminfo entries
   These entries combine mostly rxvt stuff with the ACSC stuff that
Earnie worked out for Windows/DOS line graphics.  Comments concerning my
test results with these terminfo entries appear below.  If you use
TERM=rxvt-cygwin or TERM=rxvt-cygwin-native you'll also need to edit
your /etc/termcap so that non-curses programs won't get confused (see
below)

--Chuck Wilson



------------------------------------------
***********  TERMINFO ENTRIES  ***********
------------------------------------------

CYGWIN:

Now, I can't get the linedraw characters to work no matter what I try
when running bash in a DOS box on win2k.  "D:\WINNT\system32\mode.com
con codepage select=437" seems to have no effect -- even when the system
reports that I am using cp437, I still get the so-called 'European'
character set (cp1250).  Oh well, I like boxes drawn with Ä, ¿, 3, U,
and A.

See this message:
http://sources.redhat.com/ml/cygwin/2000-11/msg01459.html
for a more thorough discussion of this issue.

RXVT-CYGWIN and RXVT-CYGWIN-NATIVE

I tested these entries under the following configuration:

1) X-Win32 Xserver, rxvt-2.6.2 from cygutils, 'TERM=rxvt-cygwin' using
the '-fn sabvga' font (which is available from
http://cygutils.netpedia.net/unversioned/bashprompt/vgafonts.tar.gz.
sabvga and the other fonts in that package provide the linedraw
characters that most window fonts do not -- 'normal' windows fonts
provide the accented characters used by most European languages)

2) Bubba's native rxvt-2.7.2 port (http://www.io.com/~bub/rxvt.html),
'TERM=rxvt-cygwin-native', using the Lucida ConsoleP font (-fn "Lucida
ConsoleP-12" (which is available from
http://cygutils.netpedia.net/unversioned/bashprompt/luconP.zip). LuconP
is encoded as DOS codepage 437 by default -- this codepage includes the
linedraw characters -- rather than ANSI or a different national font.)

Note that if you intend to use "rxvt-cygwin" or "rxvt-cygwin-native"
often, you should probably edit your /etc/termcap file; otherwise,
non-curses programs (like the existing vim package) will get really
confused.  I appended duplicate copies of the existing 'rxvt' entry in
/etc/termcap, and changed the names to these aliases.

If you're not concerned about the linedraw characters, or use a
non-codepage437 font, then 'TERM=rxvt' will work just fine in both
X-Win32+cygutils-rxvt-2.6.2 and in bubba's native rxvt-2.7.2.

BACK to CYGWIN:

If you use bash in a dos box, none of the preceding applies to you. 
Keep 'TERM=cygwin' and you'll be fine. (Except for those pesky linedraw
characters).

------------------------------------------
*********  TEST RESULTS, DLL's  **********
------------------------------------------

The following tests and comments are regarding ncurses-5.2-1, which had
a dll for the libncurses++ library.  It didn't work, and I removed that
dll from the official 5.2-2 version; libncurses++ is provided as a
static lib only at this time.

- the statically linked programs which depend on the C libraries all
seem to work just as well as the ncurses-5.0 distribution at cygutils. 
There are a *few* imperfections (like testscanw.exe doesn't work) -- but
these failures are not new.  So, I conclude that the static versions of
the C libraries (libncurses.a, libpanel.a, libform.a, libmenu.a) are all
A-OK.

- the one program which links to the C++ library, (demo.exe links to
libncurses++), works fine when statically linked.  I conclude that
libncurses++.a is A-OK.

- the dynamically linked programs which depend on the C libraries all
work identically to their statically linked counterparts.  So, I
conclude that the dll versions of the C libraries (cygncurses5.dll,
cygpanel5.dll, cygform5.dll, and cygmenu5.dll, with their respective
import libraries) are all A-OK.

- Big problems when dynamically linking the one program that exercises
the C++ library.  demo.cc does NOT have a main() function -- it relies
on global static initializers to bootstrap itself.  This works okay when
linking statically, but ld fails to link when trying to link demo.exe
dynamically.  To get around this, I added a kludged main() function to
demo.cc (which is ONLY #defined when (a) __CYGWIN__ and (b) linking
dynamically).  After doing that, I could link demo.exe dynamically. 
However, it coredumps when I run it.  I do not know if the problem is:
  o my stupid main() is wrong
  o the C++ dll, cygncurses++5.dll, is somehow messed up
  o cygwin binutils can't handle static initializes + dlls
  o some other explanation.
  o some or all of the above
This is the problem I need help fixing or understanding -- I don't know
C++ well enough to figure this out.  Some valuable tests:

  o somebody please write your own program which requires libncurses++
but does NOT use global static initializers.  Link it statically and
verify operation.  Link it dynamically and verify (?) operation.  This
will prove (?) that the problem is demo.cc, not cygncurses++5.dll.

  o fix my kludgy main() in demo.cc -- I may have done something stupid;
I really don't know what I'm doing here.  Get it to 'work' with the
existing cygncurses++5.dll if possible.  This will prove (?) that the
problem is my stupid main(), and not cygncurses++5.dll.

  o Explain why global static initializers + dlls + cygwin-binutils
doesn't work, when global static initializes + cygwin-binutils with NO
dlls does work.

FWIW, the 'kludge' main() in demo.cc is this:

#if !defined(__CYGWIN__)
static TestApplication Demo;
#else
#  if defined(NCURSES_STATIC)
static TestApplication Demo;
#  else
int main()
{
    TestApplication * Demo = new TestApplication();
    Demo->run();
    return 0;
}
#  endif
#endif

The original was just:
static TestApplication Demo;

If you want to mess around with libncurses++ dll, you need to build
ncurses from source, using all three patches in ncurses/CYGWIN-PATCHES. 
The first patch ('ncurses-5.2-X.patch') has already been applied.  Then,
run configure, and afterwards apply the other two patches:
'ncurses-5.2-X-dll.patch' and 'ncurses-5.2-c++-dll.patch'.  Then, make. 
See /usr/doc/Cygwin/ncurses-5.2.README for more information.

------------------------------------------------------

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]