[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Lynx-dev] lynx2.8.7dev.12; compiling for mingw and DJGPP [PATCH]

From: Thomas Dickey
Subject: Re: [Lynx-dev] lynx2.8.7dev.12; compiling for mingw and DJGPP [PATCH]
Date: Sun, 04 Jan 2009 20:57:08 -0500
User-agent: Mutt/1.5.18 (2008-05-17)

On Sun, Jan 04, 2009 at 02:54:29AM -0800, Doug Kaufman wrote:
> It has been a while since I have had the time to compile lynx, and I
> see that problems for both mingw and DJGPP platforms have crept in.
> The attached patch shows the changes I made to allow compilation. I
> have also attached the shell scripts I used for configuring, in case
> configuration options affected the results. Note that I did not build
> for mingw with a native MSYS system, but rather compiled under Cygwin
> with -mnocygwin. Some of the patch is to counter inappropriate
> configure results due to picking up Cygwin capabilities not in Mingw.

that can be awkward - I guess the script you included is for that.

> I built both with the latest Openssl 0.9.9 snapshots, but didn't
> upgrade everything on my system. Cygwin compile was with gcc 3.4.4 and
> DJGPP with gcc 3.3.2. Gettext/libintl version 0.15 with Mingw and 0.17
> with DJGPP. Both used PDCurses in the 3.0 series, compiled from cvs
> September 2006. DJGPP uses pkg-config, while mingw does not. I used
> autoconf 2.61 for DJGPP and 2.59 for mingw, both compiled with Tom's
> patch modified for those versions.
> The main changes were in aclocal.m4, to account for the DOS path
> separator and for maintaining the order of includes. Several pieces of
> code, after finding new includes, PREPEND them to the list of includes
> rather than APPENDING them. This breaks compilation where the order

I have the impression that the usual practice is the prepend (and have
made fixes to ensure that's done, off and on).  Perhaps that rule only
applies to libraries (I can revisit that).

> of includes is critical, and overrides the include order specified
> in CPPFLAGS in the command line or environment. Some code also only
> checked for files in specific directories, ignoring the -I and -L
> directives specified on the configuration command line. I added some
> dummy arguments to allow the command line arguments to be used.

I'll pick through that and see what you're referring to (thanks)
> Some of the changes may not be compatible with autoconf 2.13, but I am
> not sure how to keep compatibility as the versions diverge. The 2.61
> version of autoconf does not allow comments on the same line as the
> defines, so I removed the comments. They could be moved to separate
> lines and still be compatible with the different autoconf versions.

my patch for 2.61 is supposed to filter out the comments - did I miss that?

(offhand I forget which version broke the feature of preserving comments -
somewhere around 2.59 or 2.60).

It's supposed to be faster, though each autoconf version is slower so far than
the previous (seems that "faster" only applies to undoing _some_ of the
slowdown between versions ;-).
> I see that one change I made was to remove a "-DHAVE_CONFIG_H"
> from within aclocal.m4. I made the change a while ago and don't
> remember what problem it fixed, but I am not sure I understand what
> HAVE_CONFIG_H does, before lynx_cfg.h has been generated.

that's because the check includes LYCurses.h,
which relies on this #define
> I totally failed in my efforts to modify CF_SSL version 16, so it
> would pick up the openssl libraries in mingw (without pkg-config).
> This worked fine in DJGPP with pkg-config. I had to substitute CF_SSL
> version 12 in aclocal.m4 to get it to work with mingw. Specifying
> --with-pkg-config=no didn't seem to make a difference. The files
> specified by --with-ssl=path were still ignored.

I'd have to see the trace, to guess.  (I did briefly consider testing
with openssl for mingw, but didn't have any libraries at hand - where
do you get yours? - openssl's configuration process is awkward at best)

I see this for instance 
> I also included code to compile the lynx icon into the lynx binary for
> mingw. This requires whoever is compiling to put their lynx.ico file
> in the src directory. No icon is distributed with the standard lynx
> source code. I think I finally got the right screen clearing code for
> mingw also.

> Tom, I hope you can include at least parts of these changes in the
> main code. Let me know if or when there is modified code I can test on
> these platforms.

Thomas E. Dickey <address@hidden>

reply via email to

[Prev in Thread] Current Thread [Next in Thread]