commit -- Re: does expat/libtool combo work on Win32?


Subject: commit -- Re: does expat/libtool combo work on Win32?
From: Sam TH (sam@uchicago.edu)
Date: Thu Feb 15 2001 - 00:02:19 CST


On Wed, Feb 14, 2001 at 04:36:22PM -0800, Paul Rohr wrote:
> At 03:06 PM 2/12/01 -0600, Sam TH wrote:
> >Try this with a newer Cygwin, and see what happens. The problem you
> >have described are all really weird, so maybe an upgrade will fix
> >them.
>
> OK. Now that I've upgraded to all the relevant Cygwin 1.1.8 packages, I'm
> making headway, but I'm not quite there yet. At the moment, I'm confronting
> the following 3 obstacles:
>
> 1. tell expat to realclean config.cache
> ----------------------------------------
> Doing a make realclean on expat doesn't remove config.cache like the other
> libraries (wv, psiconv, etc.) do. This one wasted most of my morning.
> Grumble.
>
> I'm doing so manually for now because I can't tell where the change belongs.
Fix committed.

>
> 2. tell expat VC, not GCC
> --------------------------
> What's the automagical switch I need to get expat to build with VC instead
> of GCC? It works for psiconv, and I see that Tom has it working in
> Tinderbox, but I can't tell what the difference is.

Well, the first question is sort of obvious - do you have gcc
installed? I'm sure you don't need it, and using it may be a
mistake.

Other than that, it seems that the configure tests for the c compiler
are the same in both.

<sam uses diff>

Yep, the tests are identical. Can you send the config.log output for
both configure runs (from really clean trees) to me? I'll take a look
at them.

>
> Since these diverge at the "checking for gcc" stage, I tried comparing the
> configure scripts around that point, but it looked like identical gibberish
> to me.

That gibberish is shell code. It can be quite useful. :-) (Sam
pretends he understand autoconf code.)

>
> 3. hush the autoconf makefile
> ------------------------------
> Long ago, Jeff and I conspired to tweak the makefiles so that a
> successful warning-free compile on Win32 generates only one line of output
> per file -- namely, the filename. This makes it really easy to find and
> nuke any warnings, because they stand out like a sore thumb.
>
> By comparison, those autoconf builds are #$^% noisy! This is what I'm
> seeing for each and every file:
>

Sadly, this is standard convention for basically every autoconf
program in existance (and most non-autoconf unix programs too).

> -- snip --
> bash.exe ../libtool --mode=compile cl.exe -DHAVE_CONFIG_H -I. -I. -I..
> -Dvsn
> printf=_vsnprintf -Dsnprintf=_snprintf -DHAVE_STRING_H=1 -c dummy.c
> cl.exe -DHAVE_CONFIG_H -I. -I. -I.. -Dvsnprintf=_vsnprintf
> -Dsnprintf=_snprintf
> -DHAVE_STRING_H=1 -c dummy.c
> Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 11.00.7022 for 80x86
> Copyright (C) Microsoft Corp 1984-1997. All rights reserved.
>
> dummy.c
> echo timestamp > dummy.lo
> -- snip --
>
> Where do I need to go to hush them up? Shutting up the MS tools just
> requires passing a -nologo argument (somehow), but I can't tell how far
> upstream I need to go inm the auto-mumble process to hush up bash, libtool,
> and that echo timestamp thing.

Ok, there are two possible levels that you would have to hush things
on:

If the package uses automake (psiconv, and abi, once I get done with
it)
The Makefile.am is the correct place to fix it. However, since the
Makefile.in (which is generated by Makefile.am and automake) is in our
CVS tree too, fixing it their would also work. To fix it in the
Makefile.am, you have to run automake afterwards. This requires
getting automake (which should be easy). Remember to use the -i
argument to automake (otherwise cl.exe will be very unhappy).

If the package uses just autoconf (wv, expat, zlib, libiconv)
Change the Makefile.in, which is a handwritten file.

However, adding -nologo will require testing $(CC) in the Makefile.

For libtool, try adding --silent to the libtool invocation (this is
line 92 in expat/lib/Makefile.in, for example). If this makes some
difference, commit it. If it doesn't do enough, let me know, and I'll
see about writing a new libtool option that does what we want.

>
> Thanks.
>
> Paul,
> who still misses Makefile.abi

Sam, who didn't have to write Makefile.abi.

        sam th
        sam@uchicago.edu
        http://www.abisource.com/~sam/
        GnuPG Key:
        http://www.abisource.com/~sam/key




This archive was generated by hypermail 2b25 : Thu Feb 15 2001 - 00:00:18 CST