[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Building ncurses 6.5 on MS-Windows with MinGW
From: |
Eli Zaretskii |
Subject: |
Re: Building ncurses 6.5 on MS-Windows with MinGW |
Date: |
Sun, 14 Jul 2024 20:55:08 +0300 |
> 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.