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

[Thomas Dickey]

On Sun, Jan 04, 2009 at 06:37:57PM -0800, Doug Kaufman wrote:
> 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.

I see (too bad there's no convenient way to tell the linker not to use
the standard C library).
   
> > > 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

well normally I'd look for the libraries such as libiconv first (there's
for instance a possible dependency of libiconv on libutf8).  So prepending
the individual libraries works for that case.

> 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

It's possible - but supposedly that's the reason for the try-compile
and try-link checks in the configure script (to ensure that the pieces
fit together).  Also, -I options override the system headers in /usr/include

-D/-U options are a different matter - they have to be in order (so I'm
revisiting things to see about that).  But for the other cases, overriding
definitions seems to be the way to refine the configuration.

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

ok - going to 2.61 was more work than some of the other updates,
but the result seemed to work.  (It would be nice if the comments
were preserved, but looking at how the script does it, didn't seem
trivial).
 
> > > 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?

config.log shows the tests that are made - though it takes some study.
What I usually do for debugging those macros is to put a "set -x" just
before, and a "set; exit" right after, to check the shell variables.

When I can do it without interfering with the AC_MSG_CHECKING/AC_MSG_RESULT
flow, I also add messages to show up with --verbose.

Testing now, the script seems to do what I intended (reading the output
from configure with --verbose, for instance):

        "configure" by itself assumes you want to use pkg-config

        "configure --with-ssl" assumes you want pkg-config's notion of
                where openssl is.

        "configure --without-pkg-config" makes it ignore pkg-config

        "configure --without-pkg-config --with-ssl" makes it try the paths
                from CF_FIND_LINKAGE

        "configure --without-pkg-config --with-ssl=SOME_SSL_LIBDIR"
                (where SOME_SSL_LIBDIR is an absolute path) makes it look
                there.

But I didn't test the "SOME_SSL_LIBDIR" with DOS-style drive letters (yet).
 
> 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.

-- 
Thomas E. Dickey <address@hidden>
http://invisible-island.net
ftp://invisible-island.net