Re: Building ncurses 6.5 on MS-Windows with MinGW

[Eli Zaretskii]

> Date: Sun, 14 Jul 2024 13:09:40 -0400
> From: Thomas Dickey <dickey@his.com>
> Cc: bug-ncurses@gnu.org
> 
> > I've build ncurses 6.5 on MS-Windows using MinGW tools, and needed to
> 
> which patch-date?

It's the original 6.5 release, with none of the following patches.
IOW, this tarball:

  https://invisible-island.net/archives/ncurses/ncurses-6.5.tar.gz

> >      configure: error: expected a pathname, not "d"
> > 
> > This happens because my pkg-config is a native MinGW port, so the
> > command to find search path, viz.:
> 
> I see...
> 
> Is that somewhere that I could get a copy (to better match the environment)?

Yes, you can download it here:

  https://sourceforge.net/projects/ezwinports/files/

(You can also find there the build of ncurses I'm talking about,
uploaded just today.)

> Cross-compiling for MinGW there also are a few places such as mkdir where the
> prototype differs (signed/unsigned/etc) which are a nuisance.

FWIW, I didn't have any problems with this -- but I built ncurses
natively on Windows.

> > Problem #6: this caused me the most of headache.  The problem is that
> > ncurses cannot be installed in a staging directory because saying
> > "make install prefix=FOO" rebuilds the library with FOO hard-coded in
> > a few files.  This is explicitly advised against in INSTALL.  Instead,
> > INSTALL says to use "make install DESTDIR=FOO".  But this cannot be
> > used as-is on Windows, because the Makefile's simply prepend
> > $(DESTDIR) to the directories derives from $(prefix), and that creates
> > file names which are invalid on Windows, like d:/foo/bard:/usr/share
> > (when prefix = d:/usr and DESTDIR = d:/foo/bar).  (To try to avoid
> > this, I originally attempted to use prefix = /d/usr, which MSYS
> > converts to d:/usr when it invokes MinGW problems, but this caused
> > other troubles: the literal "/d/usr" string is hardcoded in the
> > programs, and causes failures because native Windows code doesn't
> > support such file names.)
> 
> yes... for MinGW, I've been using the relative- and forward-slash
> pathnames throughout for scripting.  Mapping the result (to find the
> terminal database) is a nuisance.
> 
> I see what your problem is - needing to access multiple drives.
> When I used OS/2 EMX, that was on F: (a nuisance).

Right.

> > (If you want to know why I install in a staging directory, then it's
> > because that makes it much easier to produce binary archives with only
> > the build artifacts of the package, which I can then both install
> > locally under $(prefix) and upload to the ezwinports site where others
> > can download the prebuilt binaries and use them.)
> > 
> > Eventually, I needed to manually hack all the Makefile's to perform
> > the replacements such as the one below:
> > 
> >      $(DESTDIR)$(bindir)/... => $(DESTDIR)$(bindir:$(prefix)%=%)/...
> 
> I suppose that I could help this by adding a new configure option
> (probably most of the occurrences come from awk scripts).

My suggestion for this would be to split $(prefix) into two separate
variables, both taking the value from --prefix.  One of them will be
used for hard-coding file names into programs and data files, the
other will be used for "make install".  Then people could say
something like

   make install prefix2=d:/foo/bar

(where prefix2 is that second variable), and install in any place
without affecting the hard-coded file names.

> > Problem #7: there's no "install-strip" target in the Makefiles.  I
> > solved this with manually stripping the programs and the libraries
> > after "make install".
> 
> stripping is currently done as a configure option
> 
>     --disable-stripping
>       Do not strip installed executables.
> 
>     --with-strip-program=XXX
>       When stripping executables during install, use the specified program
>       rather than "strip".

IMO, the libraries should also be stripped, except that the debug
versions of the libraries should be left unstripped.