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

[Doug Kaufman]

On Sun, 4 Jan 2009, Thomas Dickey wrote:

> On Sun, Jan 04, 2009 at 02:54:29AM -0800, Doug Kaufman wrote:
> > 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.

Actually, I included it in configure.in. See the sections for
gettimeofday and symbolic links.
  
> > 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).

I would think that for libraries, it depends on what type of dependency
you are looking for. For instance, with libintl and libiconv, if libintl
depends on libiconv, libiconv has to be appended after libintl. Most of
the time it wouldn't matter. For most include files it wouldn't matter,
but for instances where there are more than one file of the same name in
different directories, you could inadvertantly change which file is
included. I would think that the general rule should be that the user
should be assumed to be correct and allowed to override the automated
results. When you prepend to a list of include directories, you are
overriding the user.

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

Thanks. Let me know if what I tried to do isn't clear.

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

I hadn't realized that you had done one for 2.61. When I compiled
my version of 2.61, I modified your patch for 2.57 myself. I'll try
recompiling 2.61 with your latest patch.

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

One of the problems was that there weren't traces that I could find.
Neither config.log nor a log of the stdout and stderr during the
configure showed anything. Where should I be looking?

OpenSSL configures and builds for me without much problem, but I only
build the static libraries. I have never tried to build the shared
libraries, which might be what you want. I am attaching the patch and
configure script that I used to build OpenSSL for mingw under cygwin.
The "-mnocygwin" directive is already built into the perl configure
script.

                               Doug


-- 
Doug Kaufman
Internet: address@hidden

openssl_mingw_conf.sh
Description: Bourne shell script

ssl1227.pch
Description: Text document