Re: g++ and -nostdlib

2013-11-08 Thread Charles Wilson

On 11/8/2013 1:49 PM, Bob Friesenhahn wrote:

Isn't it because libtool wants to control the order of the linking and
assure that all dependencies (including static) are tracked/known and
applied at the correct times?  It wants to assure that static
dependencies are linked into the dependent program rather than into some
dependent shared library (and thus causing a problem).

It was common (and perhaps still is) for the GNU C++ library to be
delivered as a static library for Windows/MinGW because C++ exceptions
were not handled properly when thrown by DLLs.

Quite a lot of effort went into making this work the way it currently does.

First libtool tries to take away all of the libraries which would be
added automatically and then it applies the libraries that GCC says it
would use at the correct time.


One of my wishlist roundtuit items is to special-case this behavior for 
libtool + GNU toolchains.  For that combo, instead of the procedure Bob 
outlines, and then using $LD to linkjust use the compiler driver 
(e.g. g++, or gfortran, or gcc) to link, WITHOUT -nostdlib [1].  We're 
already passing the ABI-modifying -m and -f flags anyway, and it would 
really REALLY simplify libtool's logic...


[1] unless of course the end user put -nostdlib in $LDFLAGS or something.

--
Chuck





Re: Windows Line Endings [WAS Re: [SCM] GNU Libtool branch, master, updated. v2.4.2-273-ge24f183]

2012-10-05 Thread Charles Wilson

On 10/5/2012 12:03 PM, Gary V. Vaughan wrote:
 And thanks for looking into it.  Is there a legal way to get access
 to Windows and the various flavours of gcc and MSVC that libtool users
 care about, without spending hundreds of dollars on software I would
 never use for anything else?

Yes.

MS routinely provides virtual machine images for their OS's for testers 
to use.  Naturally they are in VHD format for the windows-hosted 
VirtualPC product...


WinXP, WinVista, Win7 (90 days [*])
http://www.microsoft.com/en-us/download/details.aspx?id=11575
[*] XP image has a hard-coded expiration date, and they usually upload a 
new version with a bumped expiry every so often. Current expiry is 13 
Nov 2012. Vista and 7 are rolling expiration: 90 days from first activation.



Windows Server 2012 (180 days)
http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx?ocid=wt.mc_id=MEC_110_1_33

Windows 8 (90 days)
http://msdn.microsoft.com/en-us/evalcenter/jj554510.aspx

...but you can run them on linux using VirtualBox:
http://www.geekpowers.com/?p=121

After that, you can install into the virtual environment the free (as in 
beer) Visual Studio Express of your choice; right now 2010 and 2012beta 
seem to be available.  Requires free as in beer registration to use 
past 30 days.

http://www.microsoft.com/visualstudio/eng/downloads


Note that after installing VSexpress, you have to install separately the 
Windows SDK -- or at least that used to be required with the old 2005 
and 2008 versions. Dunno about 2010/2012.

http://www.microsoft.com/en-us/download/details.aspx?id=8442


The expiration thing causes an annoyance redo factor if you only mess 
with this stuff once every six months and find you have to recreate 
everything each time.  But...it doesn't cost any money.


--
Chuck




Re: Windows Line Endings

2012-10-05 Thread Charles Wilson

On 10/5/2012 2:28 PM, Bob Friesenhahn wrote:

I
wouldn't recommend that anyone start with XP these days since it is 12
years old, patched beyond all repair, and quickly becoming defunct.


Seconded. A virtual machine with stock XP will need several full days 
of running Windows Update to bring it up to SP3 + all latest patches. 
I know because I just re-created one a few weeks ago using an old XP 
install disk.


On the other hand, $dayjob is still using XP. Corporate IT just okayed 
to transition to Win7 last month. g


The virtual machine images, even the one for XP, come fully patched as 
of their date of release. For the XP one I mentioned earlier, that'd be 
July 2012.


--
Chuck




Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Charles Wilson
On 12/8/2011 5:21 AM, Gary V. Vaughan wrote:
 The recently pushed series of patches included the controversial
 introduction of an additional 3 forks per invocation, which might
 add a minute or two of wall-clock time to giant builds on windows.
 By assuming that windows will run shell scripts on some shell with
 all the modern optional features that libtool wants, this patch
 eliminates even those 3 new forks.
 
 Okay to push?

Has anybody done a comparison between:

cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)

cygwin + libtool + bash (e.g. big bloated slow shell -- with XSI)

to see which is better?

--
Chuck





Re: [PATCH] libtool: minimise forks per invocation on cygwin and mingw.

2011-12-08 Thread Charles Wilson
On 12/8/2011 11:22 AM, Eric Blake wrote:
 On 12/08/2011 08:29 AM, Charles Wilson wrote:
 cygwin + libtool + dash/posh (e.g. small, fast shell -- without XSI)
 
 Umm, dash has XSI features (where XSI features covers things like
 ${var##prefix}). ... Meanwhile, libtool is using more than just XSI
 extensions; for example, it is probing for bash's += variable append
 extension.

Oh, I didn't realize.  I was primarily thinking about += -- I thought it
was one of the XSI extensions, not a bash-specific thing, and I knew
dash did not support it.

--
Chuck




Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-29 Thread Charles Wilson

On 11/28/2011 12:12 PM, Charles Wilson wrote:

Attached, see test log for $host=cygwin. I had to use 'make -k check
gl_public_submodule_commit=' -- I'm not sure why, but perhaps your
working tree is using private gnulib mods?

I'll send testsuite.dir privately.


I've attached the test log for $host=mingw32.  I'll send /that/ 
testsuite.dir privately, as well.


--
Chuck

make  check-recursive
make[1]: Entering directory 
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
  GENtests/defs
Making check in .
make[2]: Entering directory 
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
restore=:  backupdir=.am$$  \
am__cwd=`pwd`  CDPATH=${ZSH_VERSION+.}:  cd ../libtool  \
rm -rf $backupdir  mkdir $backupdir  \
if (/bin/sh 
/c/cygwin-1.7/usr/src/packages/libtool/git/libtool/build-aux/missing --run 
makeinfo --version) /dev/null 21; then \
  for f in ../libtool/doc/libtool.info 
../libtool/doc/libtool.info-[0-9] ../libtool/doc/libtool.info-[0-9][0-9] 
../libtool/doc/libtool.i[0-9] ../libtool/doc/libtool.i[0-9][0-9]; do \
if test -f $f; then mv $f $backupdir; restore=mv; else :; fi; \
  done; \
else :; fi  \
cd $am__cwd; \
if /bin/sh 
/c/cygwin-1.7/usr/src/packages/libtool/git/libtool/build-aux/missing --run 
makeinfo   -I doc -I ../libtool/doc \
 -o ../libtool/doc/libtool.info ../libtool/doc/libtool.texi; \
then \
  rc=0; \
  CDPATH=${ZSH_VERSION+.}:  cd ../libtool; \
else \
  rc=$?; \
  CDPATH=${ZSH_VERSION+.}:  cd ../libtool  \
  $restore $backupdir/* `echo ./../libtool/doc/libtool.info | sed 
's|[^/]*$||'`; \
fi; \
rm -rf $backupdir; exit $rc
make  check-TESTS check-local
make[3]: Entering directory 
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
make[4]: Entering directory 
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/suffix.test
PASS: tests/tagtrace.test
==
All 7 tests passed
==
make[4]: Leaving directory 
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-libtool-master-mingw'
  CC libltdl/loaders/libltdl_libltdlc_la-preopen.lo
  CC libltdl/libltdl_libltdlc_la-lt__alloc.lo
  CC libltdl/libltdl_libltdlc_la-lt_dlloader.lo
  CC libltdl/libltdl_libltdlc_la-lt_error.lo
  CC libltdl/libltdl_libltdlc_la-ltdl.lo
  CC libltdl/libltdl_libltdlc_la-slist.lo
  CCLD   libltdl/libltdlc.la
## - ##
## GNU Libtool 2.4.2.133-fe91d-dirty test suite. ##
## - ##

Shell option parser generator.

  1: short option splitting  ok
  2: enhanced shell short option splitting   ok
  3: long option splitting   ok
  4: XSI long option splitting   ok
  5: option appendingok
  6: enhanced shell option appending ok

Libtoolize operation.

  7: libtoolize macro installation   ok
  8: libtoolize macro directory mismatch error   ok
  9: libtoolize macro serial update  FAILED (libtoolize.at:151)
 10: libtoolize config files serial update   FAILED (libtoolize.at:228)
 11: diagnose missing LT_CONFIG_LTDL_DIR ok
 12: copy ltdl.m4 with shared macro directoryok
 13: correctly parse LTDL_INIT from configure.ac ok
 14: diagnose missing LTDL_INIT invocation   ok
 15: upgrading verbatim style aclocal.m4 FAILED (libtoolize.at:594)
 16: verbatim aclocal.m4 w/o AC_CONFIG_MACRO_DIR FAILED (libtoolize.at:685)
 17: nonrecursive ltdl with AC_CONFIG_MACRO_DIR  ok
 18: subproject ltdl with unconventional layout  ok
 19: Subproject ltdl without GNU M4  ok
 20: LIBTOOLIZE_OPTIONS  ok
 21: cleanup old installationok

Linking and loading.

 22: link against a preloaded static library FAILED (demo.at:398)
 23: build and dynamically load a module FAILED (demo.at:415)
 24: preload static and dynamic module   FAILED (demo.at:432)
 25: deplibs_check_methodFAILED (demo.at:478)
 26: disable fast installFAILED (demo.at:494)
 27: force PIC objects   FAILED (demo.at:510)
 28: force non-PIC objects   FAILED (demo.at:548)
 29: hardcoding library path FAILED (demo.at:621)
 30: binary relinking at install timeFAILED (demo.at:730)
 31: uninstalled libraries have priority FAILED (demo.at:791)
 32: linking with long file namesFAILED (demo.at:914)

Convenience

Re: [PATCH 01/10] tests: migrate legacy tests/cdemo tests to Autotest.

2011-11-28 Thread Charles Wilson
On 11/25/2011 11:57 PM, Gary V. Vaughan wrote:
 On 26 Nov 2011, at 11:39, Charles Wilson wrote:
 a) This is a big holiday weekend in the US, so...a bit more than 72
 hours is indicated.  Most of us will still be catching up on
 post-holiday $realjob stuff by the time 72 hours expires.
 
 Ah, didn't think of that.  Sure, I will be busy myself for a week or
 two, so I won't push for at least a week, probably more.

Thanks.

 b) cygwin? mingw? msvc? 
 
 I'm afraid I don't have (or want) access to any Windows machines, so
 I'm afraid that I am relying on you guys to tell me if I screwed up.
 Of course I'm not expecting you to debug or fix my mistakes for me,
 and I'm not anticipating any new problems, since everything is merely
 migrated from legacy testsuite to Autotest testsuite, with minimal
 changes required to keep everything working on my main machines.

Hrm, well, not so much.  See below.

 Although I do normally have access to more machines, the flooding in
 Bangkok has made any use of my Internet connection other than email
 intolerably slow... hence the recent flurry of work on libtool (which
 I can do offline, queueing emails for when my connection is next up)

Ah, well, $realjob's loss, our gain.

 to fill my time while I wait for things to get back to normal.  The
 reason I'll be too busy to do much more of that over the next week or
 two, is that last night I actually had a full-speed connection to the
 US again, so I'm anticipating playing catchup at $realjob myself.
 
 Sorry if I seem a bit short, but I'm rather annoyed to see my queue
 get filled with hours upon hours of work in the middle of a
 holiday.
 
 Please don't feel that it's your responsibility to painstakingly pick
 through every patch I post... I'd be more than happy just to get the
 test logs from anything I put on alpha.gnu.org for the architectures
 I don't use to help me restabilize the code closer to a release.

Full test logs for failed cygwin tests sent privately (1MB).

 Enjoy the rest of your holiday, and sorry for working so much on
 libtool recently: 

Well, I really wasn't complaining about the *work* per se -- it's great
that somebody is finally tackling some of those
gee-wouldn't-it-be-nice issues, like *FINALLY* switching over to
autotest throughout, with all the attendant benefits.  It's just I
didn't want to have to run the testsuite, on three platforms, over the
holidays in order to meet the 72hour deadline.

 although my objective with the recent
 modernisations has been to try to decruft libtool a little, and to
 make the barrier to contribution much lower than it is currently if
 at all possible.

decrufting is good.

 I rarely have the chance to put a lot of time into
 libtool, and things will slow down considerably again now if my
 Internet connection really is back to (something like) normal again.

Yep, when the tool mostly Just Works the motivation to allocate scarce
resources (like personal free time) to it is somewhat lacking.  I think
that's true for all of us.

 I have another 20 or so patches left incubating in my unpublished
 queue, and I will be done for now after those are polished and pushed
 over the next month or two.

Too bad.  If your inet stayed down longer, I was going to suggest
implementing the long-desired if $CC=gcc  $gnuld == yes; then use
compiler driver to link rather than ld, for all languages optimization
-- thus getting rid of the predeps/postdeps/prelibs/postlibs kludginess
for GNU compilers (incl. cygming).  Oh well. :-)


Attached, see test log for $host=cygwin. I had to use 'make -k check
gl_public_submodule_commit=' -- I'm not sure why, but perhaps your
working tree is using private gnulib mods?

I'll send testsuite.dir privately.

--
Chuck


make  check-recursive
make[1]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master'
  GEN../libtool/tests/defs.in
  GENtests/defs
Making check in .
make[2]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master'
make  check-TESTS check-local
make[3]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master'
make[4]: Entering directory `/usr/src/packages/libtool/git/build-libtool-master'
PASS: tests/link.test
PASS: tests/link-2.test
PASS: tests/nomode.test
PASS: tests/objectlist.test
PASS: tests/quote.test
PASS: tests/suffix.test
PASS: tests/tagtrace.test
==
All 7 tests passed
==
make[4]: Leaving directory `/usr/src/packages/libtool/git/build-libtool-master'
  GEN../libtool/tests/package.m4
  GEN../libtool/tests/testsuite
  CC libltdl/loaders/libltdl_libltdlc_la-preopen.lo
  CC libltdl/libltdl_libltdlc_la-lt__alloc.lo
  CC libltdl/libltdl_libltdlc_la-lt_dlloader.lo
  CC libltdl/libltdl_libltdlc_la-lt_error.lo
  CC libltdl/libltdl_libltdlc_la-ltdl.lo
  CC libltdl/libltdl_libltdlc_la-slist.lo
  CCLD   libltdl/libltdlc.la
## - ##
## GNU Libtool 2.4.2.133-fe91d-dirty test suite

Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.

2011-11-15 Thread Charles Wilson
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
 * cfg.mk (local-checks-to-fix): Remove
 sc_cast_of_x_alloc_return_value from list of disabled checks.
 * libltdl/config/ltmain.m4sh (XMALLOC, XFREE): Unroll into their
 xmalloc and free expansions so that this syntax-check can find
 violations, and then fix them.
 * iibltdl/libltdl/lt__alloc.h (MALLOC, REALLOC): Renamed to
 xmalloc and xrealloc so that this syntax-check can find
 violations.  Adjust all callers.
 (FREE, MEMREASSIGN): Removed.  All callers unrolled into their
 former expansions, and violations of this syntax-check fixed.
 * libltdl/loaders/loadlibrary.c (LOCALFREE): Unrolled for
 consistency.

Why do I get the feeling that the next time I try to build any .exe on
cygwin/mingw with -Wall -Werror, I'm going to fail because all these
(now removed) casts in the cwrapper source code were there specifically
to suppress warnings...

--
Chuck




Re: [PATCH 04/25] syntax-check: fix violations and re-enable sc_cast_of_x_alloc_return_value.

2011-11-15 Thread Charles Wilson
On 11/15/2011 11:36 AM, Charles Wilson wrote:
 On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
 * cfg.mk (local-checks-to-fix): Remove
 sc_cast_of_x_alloc_return_value from list of disabled checks.
 * libltdl/config/ltmain.m4sh (XMALLOC, XFREE): Unroll into their
 xmalloc and free expansions so that this syntax-check can find
 violations, and then fix them.
 * iibltdl/libltdl/lt__alloc.h (MALLOC, REALLOC): Renamed to
 xmalloc and xrealloc so that this syntax-check can find
 violations.  Adjust all callers.
 (FREE, MEMREASSIGN): Removed.  All callers unrolled into their
 former expansions, and violations of this syntax-check fixed.
 * libltdl/loaders/loadlibrary.c (LOCALFREE): Unrolled for
 consistency.
 
 Why do I get the feeling that the next time I try to build any .exe on
 cygwin/mingw with -Wall -Werror, I'm going to fail because all these
 (now removed) casts in the cwrapper source code were there specifically
 to suppress warnings...

And speaking of casts and C/C++...suppose you have package foo and you
want to build foo with CC=g++ -- that ought to be legal, right?

pathto/foo-src/configure --prefix=... CC=g++

But that means on cygwin/mingw, if foo uses libtool then the cwrapper
will be built using ${CC} -- that is, g++.  Bang; you're dead -- because
the cast is required with C++, isn't it? (IIRC it's not just a warning,
it's an error, if the cast is missing).

--
Chuck




Re: [PATCH 09/25] syntax-check: fix violations and re-enable sc_makefile_at_at_check.

2011-11-15 Thread Charles Wilson
On 11/15/2011 7:53 AM, Gary V. Vaughan wrote:
tests/mdemo/Makefile.am
 -## use @LIBLTDL@ because some broken makes do not accept macros in targets
 +## use $(LIBLTDL) because some broken makes do not accept macros in targets

This comment now makes zero sense. If you are now forcing the following
rule:

+$(LIBLTDL): $(top_distdir)/libtool \

then (a) remove the comment completely, and (b) document somewhere that
we now require non-broken make which DOES allow $(macros) in targets.

--
Chuck



Re: [PATCH 1/7] bootstrap: split into reusable parts.

2011-11-05 Thread Charles Wilson

On 11/5/2011 12:40 PM, Gary V. Vaughan wrote:

By the end of this particular set, libtoolize will have moved from the kludgy
sed based interrogation of configure.ac to probe the arguments to various
important macros so that it can determine what files to copy and where... to
the much more splendid and reliable M4 based tracing mechanism I originally
wrote for bootstrap last year before adoption into gnulib stalled.


IIUC, in the past libtoolize *itself* has not had any dependency on m4. 
Granted, it wasn't much use without autoconf, which needed m4, so most 
users of libtoolize would have had m4 installed anyway.  But this change 
will add a *direct* dependency on m4, right?


That's ok with me, as it makes no *real* difference, but it should be 
documented somewhere.


--
Chuck



Re: [PATCH 1/3] maint: rename `libltdl/config' directory to standard `build-aux'.

2011-11-01 Thread Charles Wilson
On 11/1/2011 10:57 AM, Stefano Lattarini wrote:

 Is `ln -s' portable to e.g., MinGW?  Or is the bootstrapping process
 not meant to work there anyway, so we can just not care?

No, bootstrapping is supposed to work (and, until quite recently, did
work) under MinGW/MSYS.  Current breakage is related to lack of a 'git'
implementation with stock MinGW/MSYS installations -- and now 'git' is
required to bootstrap thanks to git-format-ChangeLog and other git-isms
IIUC.

In the past I could create a git checkout using cygwin-git, and then
switch to MinGW/MSYS and do a full bootstrap; but (again, IIUC) that is
not possible any longer. (I didn't typically do it this way, BTW; I
usually bootstrapped under cygwin, and later copied the 'make dist'
tarball to MinGW and just built it there.)

(There is the msys-git distribution, used by the mingw64 folks -- but
it is really a sortof mingw32 git with msys bits added, plus a custom
forked version of the msys dll and other tools...)

I'm (slowly) working on adding a true msys git implementation to the
MinGW/MSYS distribution...

--
Chuck





Re: [PATCH] Include _CRTIMP in _putenv() declaration in EXE wrapper sources.

2011-06-23 Thread Charles Wilson
On 6/23/2011 5:34 AM, Vadim Zeitlin wrote:
 Re-declaring _putenv() without _CRTIMP in strict ANSI mode when using MinGW
 resulted in a warning because of a conflict with the previous declaration that
 did use _CRTIMP.
 
 Simply add _CRTIMP to our declaration to avoid it.

 -int _putenv (const char *);
 +_CRTIMP int _putenv (const char *);

Probably should also add __cdecl (for correctness, not warning
suppression) in case the user has done a -mrtd.

_CRTIMP int __cdecl _putenv (const char*);

However, no need for __MINGW_NOTHROW, I think, because gcc does not
appear to give this warning when redeclarations only differ by missing
attributes (in this case, __attribute__ ((__nothrow__)) ).

The larger issue, of course, is that we need to implement
LT_WRAPPER_CFLAGS variable (*), that strips out warning flags and
especially -Werror and its other-compiler analogues from the user's
C[,PP,XX]FLAGS -- otherwise, we will continue to hit this problem over
and over.

This is the third or fourth time we've had to update the c-wrapper code
for similar issues.

(*) Dunno what the correct name should be.  LT_CFLAGS_FOR_BUILD or
similar is /wrong/, because the wrapper is actually built for $host.

--
Chuck



Re: Stop relink searching host directory when installation prefix provided

2011-01-17 Thread Charles Wilson
On 1/17/2011 8:23 AM, Martin Panter wrote:
 On 16 January 2011 17:23, Charles Wilson wrote:
 Actually, Ralf's example (or one very similar to it) is the *primary*
 use of DESTDIR.  It's how many packaging tools -- like rpm, or cygport
 on cygwin -- create installable binary packages.
 
 Agreed, that example already tends to work with unmodified Libtool. I
 want to get cross-compiled installable binary packages working as
 well.

Right, but if you remove the $DESTDIR/$libdir from the relink command,
then you'd break these native builds (because, e.g. /usr/lib is still in
the compiler's default search path).

For instance, suppose you're building gettext: it installs several so's
(with interesting dependencies between them) AND a bunch of executables
that depend on THOSE so's.  If you use $DESTDIR, and need to relink, but
don't include $DESTDIR/$libdir in the -L spec, then you'd relink the
executables (and so's with internal dependencies) against the versions
installed by gettext-$OLDVER in /usr/lib.

If the new apps depend on any added/new interfaces...boom.

--
Chuck




Re: Stop relink searching host directory when installation prefix provided

2011-01-16 Thread Charles Wilson
On 1/16/2011 12:13 PM, Ralf Wildenhues wrote:
 (I for one often do 'make install DESTDIR=/tmp/dest' merely to
 tar up the installation tree to be scp'ed to another machine where
 the NFS share is mounted rw.)

Actually, Ralf's example (or one very similar to it) is the *primary*
use of DESTDIR.  It's how many packaging tools -- like rpm, or cygport
on cygwin -- create installable binary packages.

--
Chuck



Re: func_convert_file_cygwin_to_w32 woes

2011-01-07 Thread Charles Wilson
On 1/7/2011 3:02 AM, Peter Rosin wrote:
 Den 2011-01-06 21:29 skrev Ralf Wildenhues:
 * Peter Rosin wrote on Tue, Jan 04, 2011 at 05:44:58PM CET:
 Before I tie up the lose ends with this patch, I wonder if Ralf (or someone
 else) could tell me if I should also fix the other assignments of
 old_archive_cmds -- such as in the below snippet -- or is that completely
 irrelevant?

 I wouldn't change them without being sure that the changes are
 necessary.
 
 Well, they are necessary, but in cases which are, errhm, convoluted...
 
 Such as: win32-hosted cross-tools (I mean native win32 here, not
 dependent on Cygwin or MSYS) for targeting irix (or whatever) and
 running them from Cygwin (or Wine) instead of MSYS.
 
 I think I'll skip the extra changes, as someone doing the above needs
 a clue-bat anyway.

Err...that's not really uncommon.  Take the following fer-instance:
  1) You use a vendor-provided gcc for your fav embedded target
  1a) naturally, it's a MinGW-$foo cross compiler
  2) But, you like to work from a cygwin shell because it doesn't suck
as bad as dosbox, and provides tools that MSYS does not.

Now, MOST of the time, if you're using a vendor-provided compiler,
you're also going to use the vendor-provided IDE, so...the fact that you
like to play in the cygwin shell doesn't matter; the IDE doesn't use
your shell anyway.

But...if you step outside of the IDE...say, you just want to use the
normal configure/make process with --host=$foo
CC=/path/to/vendor/bin/gcc, since you don't really want to set up an
IDE project for $third-party-package-with-perfectly-good-autoconfigury,
do you really need a cluebat?  Don't do that, download and install the
(limited in functionality compared to cygwin) MSYS environment, even
though you are not using real MinGW gcc, but a vendor toolchain?
Or...a few more, already identified and well-understood changes in libtool?

--
Chuck



Re: func_convert_file_cygwin_to_w32 woes

2011-01-07 Thread Charles Wilson
On 1/7/2011 1:18 PM, Ralf Wildenhues wrote:
 Err...that's not really uncommon.
 [...]
 
 OK, but I still would accept those kinds of changes to code for
 little-used system only when someone has actually *tested* them in that
 particular situation, and found the code to be erroneous prior patch and
 working afterwards.  We've been pestering other users to try out our
 patches for a good reason, I don't see why this should be treated less
 strict.

OK, I'll add it to my list to create a mingw-linux compiler at home,
and use it to build (e.g.) libtool-enabled libpng from a cygwin shell.
(mingw-linux as a stand-in for mingw-$embedded since I can only do
this sort of thing at home, rather than at work where I have access to
mingw-$embedded).  Or maybe I'll look into an Android dev env (which is
mingw-android) instead, and try to use it from cygwin.

But...it probably won't happen soon.

--
Chuck



Re: Fix cwrapper test failure with --disable-static.

2010-11-10 Thread Charles Wilson
On 11/10/2010 1:29 PM, Ralf Wildenhues wrote:
  
 -AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
 - [], [ignore], [ignore])
 +AT_CHECK([$CC $CPPFLAGS $CFLAGS -c m.c], [], [ignore], [ignore])
  
  AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT 
 foo/liba.la],
   [], [ignore], [ignore])

Wouldn't a better fix be to change the link command to reference m.lo
instead of m.$OBJEXT ?

--
Chuck



Re: Fix cwrapper test failure with --disable-static.

2010-11-10 Thread Charles Wilson
On 11/10/2010 4:07 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Wed, Nov 10, 2010 at 09:46:54PM CET:
 Wouldn't a better fix be to change the link command to reference m.lo
 instead of m.$OBJEXT ?
 
 That would be an alternative, but it would mean that we (needlessly) use
 PIC code on systems where non-PIC is turned off by default (or
 --disable-static was used).

I thought that in those cases, the .lo file would redirect to the
regular, non-pic .o but I guess what actually happens is that you get
neither the .lo NOR the .libs/.o pic file, and you see only the non-pic .o.

 automake-generated code also compiles
 program sources without libtool, so the change was, to me, the canonical
 one.

Meh...only if the target is explicitly *.o   If it's .lo, then
$(LTCOMPILE) is used, and then libtool generates either or both of the
.o's itself, as determined by the system defaults and/or
--enable-{shared,static}.

 Is there a portability issue associated with it?

I don't think so. It was simply a stylistic question: we're testing
libtool, so...use libtool. :-)

--
Chuck



Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

2010-10-20 Thread Charles Wilson
On 10/20/2010 2:31 AM, Peter Rosin wrote:
 Den 2010-10-05 13:33 skrev Peter Rosin:
 I have implemented exactly that and just posted this to the MinGW patch
 tracker:
 http://sourceforge.net/tracker/index.php?func=detailaid=3081421group_id=2435atid=302435
 
 The silence is deafening. 
 
 Chuck, have you looked at this?

Yes, I have -- but MSYS patches are Cesar's domain.  I guess I could
ping him...

wait...

Looks like Cesar responded earlier today.  Coincidence?

I understand wanting to keep the current (popup-showing) behavior for
most MSYS process trees, since many users may rely on that information
to indicate real problems.

I wish there was some way to activate your patch other than launching
the top-level shell/window thru a run.exe-like starter app...but since
it has to be done before any other msys apps in the process tree start,
that means it probably should be done inside msys.bat itself (via an
--option?) somehow.

However, msys.bat launches its target (either rxvt or bash) via the
win32 program start.exe.  So, we could launch the target using EITHER
start.exe OR your wrapper, depending on --no-popups.  But then the
wrapper would need to be a lot smarter (e.g. use CreateProcess instead
of execve, so that it can set the CONSOLE hiding flags...but then, THAT
would use a different startup path inside msys.dll, and your patch
wouldn't activate!)

So, I don't think there is a better way than

   error_mode.exe -cgf C:/mingw/msys/1.0/msys.bat [--rxvt]

if we (MSYS) want to preserve existing popup-showing behavior at all --
which I think we do.  MAYBE the following (pseudo-bat-code, where
MSYS_NOPOP is set based on --no-popups arg to .bat file):

   if x%MSYS_NOPOP% == x goto startrp
   start %WD%error_mode -cgf /bin/rxvt {other args}
   exit

   :startrp
   start %WD%rxvt {other args}
   exit

with similar changes for the --no-rxvt case. It's sorta clunky, but it
might work.

But...that's something for the msys-dvlpr list to hash out.
Technically, I think your patch is fine.

--
Chuck



Re: [PATCH] Add test case for 69e77671 (cwrapper PATH manipulation order)

2010-10-07 Thread Charles Wilson
On 10/4/2010 1:14 AM, Ralf Wildenhues wrote:
 OK with nits addressed.  You may want to use a ChangeLog and/or --author
 entry that suitably documents the main author of the patch.

Updated and pushed as attached.

--
Chuck
diff --git a/ChangeLog b/ChangeLog
index c0492fe..9caba84 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-07  Roumen Petrov  ...
+
+   Add test case for 69e77671 (cwrapper PATH manipulation order)
+   * tests/cwrapper.at: Add new test 'cwrapper and installed shared
+   libraries.'
+
 2010-10-04  Peter Rosin  ...
 
cwrapper: split long lines when dumping the wrapper script.
diff --git a/tests/cwrapper.at b/tests/cwrapper.at
index cd618dc..6e8cf3c 100644
--- a/tests/cwrapper.at
+++ b/tests/cwrapper.at
@@ -194,4 +194,71 @@ AT_CHECK([grep ' *fputs' $objdir/lt-usea.c  /dev/null])
 # Check for no overly long fputs.
 AT_CHECK([grep ' *fputs.\{250\}' $objdir/lt-usea.c], [1])
 
+
+AT_CLEANUP
+
+
+AT_SETUP([cwrapper and installed shared libraries])
+AT_KEYWORDS([libtool])
+
+# make sure existing libtool is configured for shared libraries
+AT_CHECK([$LIBTOOL --features | grep 'enable shared libraries' || exit 77],
+[], [ignore])
+
+LDFLAGS=$LDFLAGS -no-undefined
+
+inst=`pwd`/inst
+libdir=$inst/lib
+bindir=$inst/bin
+mkdir $inst $libdir $bindir
+
+# Build the library in a separate directory to avoid the special case
+# of loading from the current directory.
+
+mkdir foo
+cd foo
+# build and install old library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return 1; }
+]])
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o 
liba.la -rpath $libdir a.lo],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=install $lt_INSTALL liba.la $libdir],
+ [], [ignore], [ignore])
+
+# build a new library version
+AT_DATA([a.c], [[
+int liba_ver (void) { return 2; }
+]])
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c a.c],
+ [], [ignore], [ignore])
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -version-info=0.0.0 -o 
liba.la -rpath $libdir a.lo],
+ [], [ignore], [ignore])
+
+cd ..
+
+# build and run test application
+AT_DATA([m.c], [[
+extern int liba_ver (void);
+int main (void)
+{
+  int r = (liba_ver () == 2) ? 0 : 1;
+  return r;
+}
+]])
+
+AT_CHECK([$LIBTOOL --mode=compile --tag=CC $CC $CPPFLAGS $CFLAGS -c m.c],
+ [], [ignore], [ignore])
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m1$EXEEXT m.$OBJEXT 
foo/liba.la],
+ [], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./m1], [0], [ignore], [ignore], [])
+
+AT_CHECK([$LIBTOOL --mode=link $CC $CFLAGS $LDFLAGS -o m2$EXEEXT m.$OBJEXT 
foo/liba.la -L$inst/lib],
+ [], [ignore], [ignore])
+LT_AT_EXEC_CHECK([./m2], [0], [ignore], [ignore], [])
+
+
 AT_CLEANUP


Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

2010-09-29 Thread Charles Wilson
On 9/29/2010 4:06 AM, Peter Rosin wrote:
 Cygwin is always running with this error mode (I think), MSYS is not.

Cygwin no longer supports Win9x, MSYS does.

Will this patch cause any issues if people try to use libtool + MSYS on
a Win9x system?

--
Chuck






Re: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

2010-09-29 Thread Charles Wilson
On 9/29/2010 10:15 AM, Peter Rosin wrote:
 Den 2010-09-29 15:47 skrev Charles Wilson:
 Will this patch cause any issues if people try to use libtool + MSYS on
 a Win9x system?
 
 I don't foresee any problems, because SetErrorMode is really old.  You
 were worrying about the entry point not being there, right?

Right.  Sadly, MSDN no longer even references things that old; from
reading it, you'd think that *nothing* existed prior to w2k, and *every*
current entry point was brand new with that version.

SetErrorMode:
Minimum Supported Client: Windows 2000 Professional

So it's no longer even possible to discover exactly HOW old an API is,
if it predates w2k.  At least, not via MSDN.

--
Chuck





Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
On 9/23/2010 6:25 PM, Peter Rosin wrote:
 I don't know how to set up the defines so that EXTERN becomes
 
 1. extern when you use a static library
 2. extern when you build a static library
 3. extern declspec(dllimport) when you use a shared library
 4. extern declspec(dllexport) when you build a shared library
 
 I could fix 2 and 4, but separating 1 and 3 is not possible. Since
 extern declspec(dllimport) works everywhere with MSVC I'm taking the
 easy option with this patch.
 
 Or should I add -DBUILDING_FOO to Makefile.am and variations of the below
 to the code?

That is the typical approach.  The drawback -- usually an acceptable one
-- is that if you are building a stack of dependent DLLs:

EXE -- C.DLL - B.DLL
-- A.DLL

Then (a) you must link exe using .obj's compiled as pic (e.g. with
-DDLL_EXPORT, even tho the EXE *itself* is not a shared library).
libtool does this by default IIRC.  (b) You MUST link EXE against shared
C.DLL and shared A.DLL; you can't link against static C.lib and B.lib,
but dynamic A.DLL, or vice versa (because DLL_EXPORT, for EXE's objs,
either IS, or IS NOT, defined).

We already enforce the restriction that C.DLL can't depend on B.lib, so
that complication is a non-issue.

 #ifdef _MSC_VER
 # ifdef BUILDING_FOO
 #  ifdef DLL_EXPORT
 #   define EXTERN extern declspec(dllexport)
 #  endif
 # else
 #  define EXTERN extern declspec(dllimport)
 # endif
 #endif
 #ifndef EXTERN
 # define EXTERN extern
 #endif

More indepth review against your revised version.

--
Chuck



Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
On 9/24/2010 8:44 AM, Peter Rosin wrote:
 Yes indeed, I intended __declspec.  I have revised the patch so that it
 handles building correctly (dllexport for dlls, not for static) and
 using the best way possible (still dllimports from from both dlls and
 static libs).

Well, I'm confused.  The linker really ought to fail in this case, since
dllimport mangles the symbol name IIRC -- and the mangled name is not
present in the static lib.

 For Cygwin I removed some dead code in tests/pdemo,
 similar code was deleted from tests/demo back in 2002 (see commit
 45d16ee8bf4559d6b976bfd4d6482767f16eac95).  I have verified that the
 Cygwin related cleanup does not affect the Cygwin testsuite results.

Always good to know.

 With this patch, the old testsuite SKIPs cdemo-undef and tagdemo-undef,
 FAILs demo-deplibs(1) and all the rest PASS (on MSYS/MSVC).  So it is
 looking really nice.

That's great. (Still confused, tho).

 That documentation would be nice, yes, and I plan to write something about
 that eventually.  Is it a prerequisite for pushing this?

IMO, we should probably document it before 2.4.2...

 Of course, if libtool can somehow help with this any more, so much the
 better.  But I'm less optimistic on this than I was those five years
 ago.  :-/
 
 Yes, and with auto-import in place for gnu tools on w32, the itch is gone
 for a whole bunch of people.

Well, Bruno Haible still hates auto-import.  He has wanted a certain
patch in libtool for a long time, but I still don't understand whether
doing so would break existing expectations and force everybody to use
his method, or if it would basically have no effect for most of us yet
enable his method...

http://www.haible.de/bruno/woe32dll.html

 Also, may I remind you that you promised a number of testsuite additions
 before the release.
 
 I have been digging in the archives for quite a bit, but I'm only finding
 http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00266.html
 
 What else have I promised?

I think it was kinda given that the new functionality would need tests
(for anything not also covered by existing ones).  Maybe manifests
('course, IIRC the end user needs to explicitly set MT before running
the testsuite, which is kindof odd).

Some of the promised tests are on my plate, and relate to
non-msvc-specific stuff, which msvc leverages.

Patch (as revised) is fine with me.

--
Chuck



Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
On 9/24/2010 8:13 PM, Roumen Petrov wrote:
 About pre-processor flags - better is C code to start with #define
 BUIILD_FOO instead -DBUIILD_FOO in makefile.

No, actually, it is not better.  The reason is, any given C file *might*
be used in a library, or it *might* be used in an application -- or
both, depending on compile flags.  For instance, suppose you have a
utility library, where each function has a built-in self test:


int some_util_function() {
  
}

#if defined(PACKAGE_FOO_TESTING)
int main(int argc, char *argv[])
{
  
}
#endif


You wouldn't want to unconditionally define BUILDING_LIBUTIL in this
case.  Now, certainly, you could do some magic like

#if !defined(PACKAGE_FOO_TESTING)
# define BUILDING_LIBUTIL
#endif

but...(a) this is a deliberately simple example, and (b) there's a
better way.

There is *one place* in the package where you KNOW which files are being
compiled for inclusion in a library, and which are not: and that's the
Makefile (or Makefile.am, or cmakefiles.list, or whatever) -- NOT the C
code itself.  Why should you duplicate that knowledge in the source code
itself?  What happens when you refactor a big library into multiple,
smaller libraries?  With the Makefile approach, you simply reassign when
.c's go with which libfoo_SOURCES, and each libfoo_la_CFLAGS has a
different -DBUILDING_*  -- and you don't have to modify any of the .c's
at all (you'd have to modify some .h's, but you'd need to do THAT
regardless).

Your way, this refactoring requires coupled changes in each and every .c
file -- because you put knowledge (about which library each .c file
belongs to -- inside each .c file itself, and that's the wrong place for
that knowledge. It *belongs* in the buildsystem (e.g. the Makefile).

--
Chuck



Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
On 9/24/2010 8:06 PM, Roumen Petrov wrote:
 
 I would like to propose different macros for export/import of variables
 in format:
 
 #define XXX(type)decorator_before type decorator_after

Why?  Peter's formula is practically universal in most packages I have
seen (ncurses is the only exception that springs to mind).  What
advantage does using an unusual decorator structure bring?

It's not as if we're going to, in our demo/test code, start using
__stdcall decorator_afters, are we?  (Remember that we're only talking
about how the test code is structured, not how libtool requires client
code to be written.  Clients would still be free if they chose to, to
use XXX(type) macros).

--
Chuck



Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
On 9/24/2010 2:53 PM, Ralf Wildenhues wrote:
 Den 2010-09-24 19:30 skrev Charles Wilson:
 That is the typical approach.  The drawback -- usually an acceptable one
 -- is that if you are building a stack of dependent DLLs:

 EXE -- C.DLL - B.DLL
 -- A.DLL

 Then (a) you must link exe using .obj's compiled as pic (e.g. with
 -DDLL_EXPORT, even tho the EXE *itself* is not a shared library).
 libtool does this by default IIRC.
 
 Huh?  But automake won't go this way usually.  With
 
   bin_PROGRAMS = foo
   foo_SOURCES = foo.c
   foo_LDADD = libc.la
 
 foo will be linked with foo.o (*not* created by libtool), and neither
 foo.lo nor .libs/foo.o will ever be created.

Err...maybe you are right.  I've been so used to auto-import (and now,
even the warnings are suppressed with modern cygwin and mingw
gcc/binutils), that I'm just used to it simply working.

If I understand the process, the above would fail if libc.la had a
shared library, but we linked foo using -disable-auto-import (e.g. or we
were talking about MSVC.)

More in my reply to Peter's message.

--
Chuck





Re: [PATCH] tests: import variables for MSVC.

2010-09-24 Thread Charles Wilson
On 9/24/2010 2:46 PM, Peter Rosin wrote:
 Now I'm also confused.

That's not good.

 /me double checks (see below)
 
 WHAT? It doesn't work as I stated!?!
 
 *ponders that for a bit*
 *scratches head*
 
 Ahh, you said libtool does this by default IIRC. If that's actually the
 case than that is what has have me fooled for years.

Pay close attention to how libtool compiles (the single, only) main.o.
Does it get the picflag (-DDLL_EXPORT) or not?

As I've always understood it, *without* auto-import magic, you MUST have
the following:

1) shared:
  a) a dll, compiled with declspec(dllexport) [or, create the DLL with
an explicit .def file listing the exported symbols]
  b) the client *must* be compiled with declspec(dllimport) decorators
on all symbols the client wants to use from the DLL

2) static
  a) a lib. Nothing should be compiled with declspec(dllexport), and
obviously there is no .def file involved
  b) the client must NOT be compiled with declspec(dllimport) -- because
then you get the missing __imp__foo error.

So, your test case below doesn't surprise me.  What DOES surprise me, is
that it ever worked at all with MSVC (or gcc + -disable-auto-import),
since it appears that Ralf is correct and the *_PROGRAM objects are
built in only one mode.  Whether that is picflag (-DDLL_EXPORT) or
not, one or the other linking modality should fail (static linking if
main.o is compiled with -DDLL_EXPORT; dynamic linking if main.o is NOT
compiled with -DLL_EXPORT).

So, yeah, I'm a little confused as well.  I think you need to do some
archeology on the *_PROGRAM objects (nm -B or whatever the equivalent is
in msvc land), and figure out what symbols are undefined.  I'd take a
hard look at demo/.


NOTE: Bruno Haible's method worked around this by ALWAYS defining
symbols in a library as declspec(dllimport), when building the library
shared, building the library static, OR building a client.

BUT...to make linking the DLL itself work (with internal references to
these dllimported symbols!), he uses some nm and asm magic to (a)
manually define the __imp_* redirection symbol values and set them to
point to the address of the actual symbol, and (b) explicitly export
each exported symbol using an asm .drective, even tho it was marked
dllimport.

It's really rather clever, but I've never really figured out how to
merge it into the typical auto*/libtool process (Bruno's libiconv and
gettext do it, but with a lot of Makefile.am hackery).  Second, I don't
know if it would work with MSVC easily; certainly the asm magic would
need modification.  Third, it almost *requires* to build *everything*
with --disable-auto-import.  Which would NOT go over well with the
larger community.  So, I've never pursued it, and obviously Bruno hasn't
pushed the issue.

 *deep sigh*
 
 Thanks for setting me straight.
 
 What now?  Is the patch still good?  (with a reworded changelog of course)

Well, I think so.  It's possible we might need a follow-on patch for
strict correctness -- but this patch appears to be correct as far as
it goes.

 But now I'm really confused.  What made the original patch work?  It had
 #define EXTERN extern __declspec(dllimport) unconditionally for MSVC.
 And that patch also had two SKIPs and one FAIL (libfoo.a vs. foo.lib).
 I.e. the exact same result, which means I can't be completely wrong.  Or
 is the testsuite not doing any static builds?  But that seems highly
 unlikely indeed.  WTF?

Look really closely at how hell_static.exe is built in demo/.

But, to sum up, I see no problems with THIS patch, as far as it goes.



With regards to Ralf's question re: _MSC_VER.  Well, technically you'd
probably be more correct to do:

#if (defined(_WIN32) || defined(_WIN32_WCE))  !defined(__GNUC__)
...

rather than _MSC_VER; that formula would indicate any win32 or wince
platform, using any compiler EXCEPT gcc -- because only gcc has
auto-import on win32.

But nobody does that; pretty much all source code with pretensions of
both cross-platform use, AND windows support, uses _MSC_VER (*badly*
ported code uses _WIN32 to mean MSVC which causes no end of cygwin and
mingw headaches!).

Because of that, IIUC most users of other compilers for win32 (Intel
C/C++, Watcom, Borland, etc) either (a) routinely
s/_MSC_VER/__WATCOMC__/g, or (b) add -D_MSC_VER anyway.


--
Chuck



Re: [PATCH] msvc: eliminate spaces in the library search path.

2010-09-21 Thread Charles Wilson
On 9/21/2010 1:33 PM, Ralf Wildenhues wrote:
 Hi Peter,
 
 * Peter Rosin wrote on Tue, Sep 21, 2010 at 09:37:16AM CEST:
 I know it's late for the release, but I'd like to squeeze this one in
 too, if at all possible. After all, it doesn't affect anything but MSVC.
 
 I have questions:
 
 What does Charles have to say to this?

Well, in principle -- so long as this code is activated only when $CC is
MSVC -- the patch as revised is fine with me.

 What is $LIB?  Is this an API you just made up?  If not, where is it
 documented?  Hmm, we used it before, so I guess that's not new.

LIB and INCLUDE are MSVC's mechanisms for setting search paths; it's not
something we libtoolers picked.

 +  do
 +IFS=$lt_save_ifs
 +# Let DOS variable expansion print the short 8.3 style file name.
 +lt_path=`cd $lt_path  cmd //C for %i in (.) do @echo %~si`
 
 Can you explain what this command does?  I mean, no need to change the
 patch, but I don't understand the %~si syntax and I can only infer the
 %i and (...) bits, but can't tell whether they are correct, work by
 accident, or something else.  I'm willing to believe you, but it would
 be nice to know for sure.

See http://thread.gmane.org/gmane.comp.gnu.mingw.user/34276

 Can the command fail?

Sure -- if lt_path doesn't exist.  I don't know if that is an issue in
this particular case.  It will also fail on Win9x (where cmd.exe doesn't
exist, and command.com is supposed to be used).  However, we already
have that problem in func_convert_core_msys_to_w32.

One workaround would be to use the %COMSPEC% variable in both cases,
but...I'd rather go with cmd in both places, and then worry about
%COMSPEC% after the release, and only if we get complaints.

 +sys_lib_search_path_spec=$sys_lib_search_path_spec $lt_path
 +  done
 +  IFS=$lt_save_ifs
 +  # Convert to MSYS style.
 +  sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | sed -e 
 's||/|g' -e 's| \\([[a-zA-Z]]\\):| /\\1|g' -e 's|^ ||'`

Yes, sadly msys does not provide a program analogous to cygpath.  So, we
can go msys-win32 by exploiting msys's autoconvert behavior (by running
a native win32 program cmd.exe with the args to be converted).  But
we can't go the other direction -- so, fun with sed scripts.

The downside of this is that only the standard representation of paths
will be used (e.g. C:/foo - /c/foo, etc).  If there are any special
mount points defined in MSYS's /etc/fstab -- for instance

C:\PROGRA~1\MICROS~2/vizstudio

You'll get /c/PROGRA~1/MICROS~2/whatever instead of /vizstudio/whatever.
 In practice, this should make no difference -- and there really isn't
any way around it, without improvements/additions to MSYS.

 +  ;;
 +cygwin*)
 +  # Convert to unix form, then to dos form, then back to unix form
 +  # but this time dos style (no spaces!) so that the unix form looks
 +  # like /cygdrive/c/PROGRA~1:/cygdr...
 +  sys_lib_search_path_spec=`cygpath --path --unix $LIB`
 +  sys_lib_search_path_spec=`cygpath --path --dos 
 $sys_lib_search_path_spec`
 +  sys_lib_search_path_spec=`cygpath --path --unix 
 $sys_lib_search_path_spec | $SED -e s/$PATH_SEPARATOR/ /g`
 
 Can any of the cygpath commands fail?
 What about LT_CYGPATH?

If $build_os is cygwin, then cygpath.exe IS in the $PATH (or there is
something *extremely* broken about your cygwin installation).  So, for
$build=cygwin, we can invoke cygpath directly.  LT_CYGPATH is used when
$build != cygwin, but there is a cygwin somewhere that is accessible.

We can't use the func_conv functions here, because we're (a) going
backwards in two cases, and (b) using the --dos flag instead of
--windows or --mixed even when we're going in the right direction.

 +  ;;
 +*)
 +  sys_lib_search_path_spec=$LIB
 +  if $ECHO $sys_lib_search_path_spec | [$GREP ';[c-zC-Z]:/' 
 /dev/null]; then

What if there is only a single directory in the path spec?  Then there
won't be a ';', and we'll use the else clause -- is that the right thing
to do?

 +# It is most probably a Windows format PATH.
 +sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED 
 -e 's/;/ /g'`
 +  else
 +sys_lib_search_path_spec=`$ECHO $sys_lib_search_path_spec | $SED 
 -e s/$PATH_SEPARATOR/ /g`
 +  fi


--
Chuck



[PATCH] Fix order of PATH manipulation in cwrapper and shwrapper

2010-09-17 Thread Charles Wilson
* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the
temporary rpath values (which include the OBJDIRs of uninstalled
libtool libraries) precede installation and final -rpath directories.
(func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending
$temp_rpath to $shlibpath_var; similar rationale as above.
Reported by Jon Turney jon.tur...@dronecode.org.uk
---
As promised here:
http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00191.html

Tested on cygwin; no regressions:
old: All 122 tests passed (2 tests were not run)
new: 111 tests behaved as expected. 9 tests were skipped.

OK to push?

 libltdl/config/ltmain.m4sh |   31 ++-
 1 files changed, 22 insertions(+), 9 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 7bbca85..2371a14 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3293,6 +3293,22 @@ func_exec_program ()
 
   if test -f \\$progdir/\$program\; then
 
+   # fixup the dll searchpath if we need to.
+   #
+   # For Windows, this must occur prior to any manipulation of
+   # $shlibpath (which, ON Windows, is PATH).  That way, we ensure
+   # that the $dllsearchpath value is prepended to $PATH first, and
+   # that the temporary rpath values (which contain the actual
+   # location of uninstalled DLLs, in their respective OBJDIR
+   # directories) are prepended second.  This ensures that just-built
+   # uninstalled libraries supersede installed ones.
+   if test -n $dllsearchpath; then
+ $ECHO \
+# Add the dll search path components to the executable PATH
+PATH=$dllsearchpath:\$PATH
+
+   fi
+
# Export our shlibpath_var if we have one.
if test $shlibpath_overrides_runpath = yes  test -n 
$shlibpath_var  test -n $temp_rpath; then
  $ECHO \
@@ -3307,14 +3323,6 @@ func_exec_program ()
 
fi
 
-   # fixup the dll searchpath if we need to.
-   if test -n $dllsearchpath; then
- $ECHO \
-# Add the dll search path components to the executable PATH
-PATH=$dllsearchpath:\$PATH
-
-   fi
-
$ECHO \
 if test \\$libtool_execute_magic\ != \$magic\; then
   # Run the actual program with our arguments.
@@ -3703,8 +3711,13 @@ EOF
 
   lt_setenv (BIN_SH, xpg4); /* for Tru64 */
   lt_setenv (DUALCASE, 1);  /* for MSK sh */
-  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
+  /* For Windows, this order is important: it ensures that the $dllsearchpath
+ value is prepended first, and that the temporary rpath values (which
+ contain the actual location of uninstalled DLLs, in their respective
+ OBJDIR directories) are prepended second.  This ensures that just-built
+ uninstalled libraries supersede installed ones. */
   lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
+  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
 
   lt_debugprintf (__FILE__, __LINE__, (main) lt_argv_zero: %s\n,
  nonnull (lt_argv_zero));
-- 
1.7.1




Re: [PATCH] Copy over DLL_EXPORT handling from C to C++ for non-GCC on w32.

2010-09-17 Thread Charles Wilson
On 9/17/2010 12:53 PM, Ralf Wildenhues wrote:
 let the review sprint begin ...

Meh -- no more patches from me in the near term.  I promised two small
patches yesterday, delivered today.  Whether they are reviewed and
pushed before the release or not doesn't matter that much.

--
Chuck



Re: [PATCH 2/2] Move portable shell tests from the old to the new testsuite.

2010-09-17 Thread Charles Wilson
On 9/17/2010 1:23 PM, Ralf Wildenhues wrote:
 And since IIRC
 Gary wanted to do the release this weekend, I wonder whether this isn't
 more safely pushed to after the relase.  WDYT?

FWIW, I agree that this patch should be postponed until after the
release.  I'm agnostic on whether tests -- such as this one -- should be
moved from the old test suite to the new one.  It's not as if the old
test suite will EVER go away, is it, since it serves as a collection of
demos.  OTOH, the new test suite is a nicer framework all around...

--
Chuck



Re: [PATCH] Document libtool variable to_host_file_cmd.

2010-09-17 Thread Charles Wilson
On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
 OK to push?
 
 OK.  Why the  s/system/platform/ changes though?  I see that
 libtool.texi uses platform a lot, and also uses system quite a bit but
 not quite as often.  Other GNU documentation I think prefers system
 however.  Or are you trying to make a distinction between both terms?

Yes, the GNU Build System is already mentioned (with an xref to the
definition in another manual).  It refers to the whole
autoconf/automake/libtool process flow, as distinct from imake or scons
or whatever.

IMO, using 'build system' to refer to the $build platform could be
confused with that term.

If other GNU documentation uses the same phrase to mean two different
things, that doesn't mean we should do so as well.

 In that case, they should probably be defined somewhere (and I'd venture
 to say that they are not good terms to try to differentiate, because
 most users will not think there could be a difference).

We don't have a choice; the GNU Build System has already been given that
name by others, and we can't change that.  Our only choice is whether to
use a term that could be confused with it: 'build system' or not.  I say
not, whenever possible -- but I'm not doctrinaire about it. I'm not
about to go thru all of libtool.texi with a red pen, changing 'build
system' everywhere I see it...but to_host_file_cmd and to_tool_file_cmd
are so similar -- and defvar'ed so close together, that I thought they
should use similar terminology.

--
Chuck



Re: [PATCH] Document libtool variable to_host_file_cmd.

2010-09-17 Thread Charles Wilson
On 9/17/2010 1:30 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:28:46PM CEST:
 OK to push?
 
 OK.

Pushed.

--
Chuck



Re: [PATCH] Fix order of PATH manipulation in cwrapper and shwrapper

2010-09-17 Thread Charles Wilson
On 9/17/2010 2:12 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Fri, Sep 17, 2010 at 06:23:28PM CEST:
 * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
 lt_update_exe_path before lt_update_lib_path, to ensure that the
 temporary rpath values (which include the OBJDIRs of uninstalled
 libtool libraries) precede installation and final -rpath directories.
 (func_emit_wrapper): Prepend $dllsearchpath to PATH before prepending
 $temp_rpath to $shlibpath_var; similar rationale as above.
 Reported by Jon Turney jon.tur...@dronecode.org.uk
 
 This is OK.  I mention a nit below.

Pushed:

with this
# Fix the DLL searchpath if we need to.  Do this before prepending
# to shlibpath, because on Windows, both are PATH and uninstalled
# libraries must come first.

and this
/* Update the DLL searchpath.  EXE_PATH_VALUE ($dllsearchpath) must
   be prepended before (that is, appear after) LIB_PATH_VALUE ($temp_rpath)
   because on Windows, both *_VARNAMEs are PATH but uninstalled
   libraries must come first. */
which isn't really shorter than the previous version, but is probably a
little more clear, and models the new shwrapper commentary more closely.


I won't be able to do the test case before the release, especially not
today...

--
Chuck



Re: w32 pending?

2010-09-16 Thread Charles Wilson
On 9/16/2010 1:28 PM, Ralf Wildenhues wrote:
 do I see it right that there are no pending w32 patches for before
 the next Libtool release any more (after the one I just acked)?

My most recent cygwin-special libtool release has the following four
patches:

0001-cygwin-mingw-Create-UAC-manifest-files.patch
0002-Pass-various-runtime-library-flags-to-GCC.patch
0003-Fix-linking-with-fstack-protector.patch
0004-cygwin-mingw-Fix-order-of-PATH-manipulation-in-cwrap.patch

Of these, 0001 and 0002 have already been posted on this list, but there
was quite a bit of discussion and no resolution was reached.

For 0002, personally I think TRTTD is to stop using ld and instead use
the compiler driver to link, when using the GNU tools -- but that's
definitely a think-about-it-after-this-release item. This also applies
with regards to 0003.

For 0001, I had hoped that we could piggyback on Peter's manifest tool
support instead of a hack like this, but it doesn't appear to be the
case.  I don't think it is worth holding up the release in order to
figure out this issue.

0004...is very simple, and fixes a specific problem:
http://cygwin.com/ml/cygwin/2010-07/msg00608.html

I've pasted the current version of this patch inline, but I'll to
rebase, retest, and post officially later.  I also need to document
the '$to_host_file_cmd' variable, as Peter has documented the similar
'$to_tool_file_cmd' variable.

Other than that, there are a number of items on our TODO list
(additional test cases, always room for better/more documentation, etc),
but nothing that needs to block the release.

I'll post the two promised patches tonight (0004-rebased, plus simple
libtool.texi patch).

[cygwin|mingw] Fix order of PATH manipulation in cwrapper

* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src:main): Call
lt_update_exe_path before lt_update_lib_path, to ensure that the local
OBJDIR(s) supersedes any -rpath directories.
Reported by Jon Turney ...


--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3677,8 +3677,12 @@ EOF

   lt_setenv (BIN_SH, xpg4); /* for Tru64 */
   lt_setenv (DUALCASE, 1);  /* for MSK sh */
-  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);
+  /* For Windows, this order is important: it ensures that any -rpath
+ values are prepended first, and then the local OBJDIR directory(ies)
+ is prepended second -- ensuring that just-built libraries supersede
+ installed ones. */
   lt_update_exe_path (EXE_PATH_VARNAME, EXE_PATH_VALUE);
+  lt_update_lib_path (LIB_PATH_VARNAME, LIB_PATH_VALUE);

   lt_debugprintf (__FILE__, __LINE__, (main) lt_argv_zero: %s\n,
  nonnull (lt_argv_zero));


--
Chuck



Re: w32 pending?

2010-09-16 Thread Charles Wilson
On 9/16/2010 2:55 PM, Ralf Wildenhues wrote:
 This looks ok, but wouldn't the shell wrapper need this as well,
 seeing that it could be run on w32 too (IIRC)?

You're right.  I had looked at this before, and erroneously concluded
that the shell wrapper was DTRT.  But...it isn't.  Also, my changelog is
wrong, as is the /*comment*/ (but the guts of the patch is right)

It's actually $dllsearchpath that's causing problems; $temp_rpath needs
to win because it is manipulated by libtool to include the directory
of linked .la files (including the ones linked from $OBJDIR). The
issue with user-specified -rpath's is a red herring; those aren't used
by the wrapper system at all; $temp_rpath is for *temporary*
rpaths...like $OBJDIR.  (Oddly, I got this right in my description of
the problem at http://cygwin.com/ml/cygwin/2010-07/msg00608.html).

Just as a reminder, here's how these two _VALUEs are assigned:

func_to_host_path $dllsearchpath:
const char * EXE_PATH_VALUE   = $func_to_host_path_result;

func_to_host_path $temp_rpath
const char * LIB_PATH_VALUE   = $func_to_host_path_result;

So, what happens WITH this patch, is $dllsearchpath is prepended first,
then $temp_rpath (so $temp_rpath wins) -- which is what we want
(contrary to my earlier /*comments*/.)


Here are the variable values for the mdemo wrapper:

const char * LIB_PATH_VARNAME = PATH;
const char * LIB_PATH_VALUE   =
/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/tests/mdemo/.libs:;
 // e.g. $temp_rpath

const char * EXE_PATH_VARNAME = PATH;
const char * EXE_PATH_VALUE   =
/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/tests/mdemo/.libs:/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/_inst-mdemo/lib:/usr/src/packages/libtool/22/libtool-2.2.11a-1/build/_inst-mdemo/bin:;
 // e.g. $dllsearchpath

Now, in THIS instance, $OBJDIR appears in both (and is first in the
latter var), so it wouldn't matter whether EXE_PATH_VALUE or
LIB_PATH_VALUE ends up first in the $PATH (e.g. is prepended last).

Per John's original report, we actual had (reconstructed from the debug
output):

const char * LIB_PATH_VALUE = /opt/jhbuild/build/pixman/pixman/.libs:;
// e.g. $temp_rpath

const char * EXE_PATH_VALUE =
/opt/jhbuild/install/lib:/opt/jhbuild/install/bin:/opt/jhbuild/build/pixman/pixman/.libs:;
// e.g. $dllsearchpath

It looks like $OBJDIR *also* shows up in both vars, but the order within
$dllsearchpath varies.  However, I haven't seen a case where $temp_rpath
doesn't start with $OBJDIR, even when linking against various .la's from
various installed/non-installed locations, or when using various -L
arguments.  This isn't to say there IS no such case, just that *I* don't
recall seeing one.



*Currently*, in the shell wrapper, here's what is going on:
$shlibpath_var=\$temp_rpath\$$shlibpath_var\
PATH=$dllsearchpath:\$PATH


That's not right; we want $temp_rpath to win here, too.

 Also, of course, testsuite exposure should follow eventually.

Obviously.  If I can get myself so confused while doing the right thing,
we really need a testsuite addition to keep it fixed. :-)

--
Chuck



Re: w32 pending?

2010-09-16 Thread Charles Wilson
On 9/16/2010 3:52 PM, Vincent Torri wrote:
 do I see it right that there are no pending w32 patches for before
 the next Libtool release any more (after the one I just acked)?
 
 there is a mingw-w64 issue i have mentioned 2 times, with a debug log of
 libtool.

This is the Warning: linker path does not have real file for library
-lole32. problem, right?

libole32.a and friends are all part of the Win32 API, and are installed
by a proper mingw64 native non-multilib toolchain in ${prefix}/lib IIRC
-- and that dir is included in the compiler/linker's search path
automatically.

What would really help is if you could look at your (failing) libtool
script, and see what 'sys_lib_search_path_spec' is set to -- AND (a)
where libole32.a actually lives in your setup, plus (b) what 'gcc
-print-search-dirs' reports (where, 'gcc' is the actual compiler,
whatever it is called, that you are using).

Anyway, then we could try and figure out what libtool can't find
libole32.a...

(*) I assume you're using a native non-multilib toolchain (you didn't
specify).

--
Chuck



[PATCH] Fix sh.test failure introduced in 72064249

2010-09-16 Thread Charles Wilson
* libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor syntax.
---
Without this, sh.test fails.  Committed as obvious (no, really, this time).

--
Chuck

 libltdl/config/ltmain.m4sh |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 18f0f39..7bbca85 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -7362,7 +7362,7 @@ EOF
  try_normal_branch=no
  ;;
  esac
- if test $try_normal_branch = yes \
+ if test $try_normal_branch = yes \
  { test $len -lt $max_cmd_len \
  || test $max_cmd_len -le -1; }
  then
-- 
1.7.1




Re: [PATCH] maint: ship .xz, not .lzma

2010-09-14 Thread Charles Wilson
On 9/14/2010 2:04 AM, Gary V. Vaughan wrote:
 I'm curious to know what the history of lzma and xz is that makes this
 desirable though.

Here's some documentation I put together for the cygwin xz package:

xz

This package provides a data compression library and utilities
supporting the .xz and .lzma file formats, which use the LZMA
compression algorithm.  LZMA provides high compression ratios and very
fast decompression, with minimal memory requirements for decompression.
XZ Utils is the latest generation of this software, supplanting the
older LZMA Utils.

The cygwin xz package replaces and obsoletes the cygwin lzma package.

LZMA Utils (and its own antecedent, the LZMA SDK) provided the 'lzma'
tool, which supported the 'LZMA-Alone' file format usually indicated by
the extension '.lzma'.  Internally, this file format used what is now
called the LZMA1 compression algorithm.

XZ Utils provides the xz tool, which supports the new .xz file format
usually indicated by the extension '.xz'. Internally, it uses a
variation of the original LZMA compression algorithm, called LZMA2.
However, the new xz tool also seamlessly supports the older .lzma files
and LZMA1 compression.

History:


1. LZMA SDK
First there was the LZMA SDK. Upstream, it shipped no libraries; only a
few executables such as 'lzma'. The source code was provided for public
use (under a variety of licenses), but it was expected that developers
would incorporate the source code directly into their own projects.
This is not The Unix Way.

The LZMA SDK was tightly coupled with the 7zip compression program, and
both were developed on and solely for the Windows platform.  7zip -- but
not the LZMA SDK -- was ported to Unix under the auspices of the p7zip
(Portable 7zip) project. (As an aside, p7zip was then ported to
cygwin...to come full circle). However, it should be clear that the file
format used by 7zip (and p7zip) was completely different from the one
supported by the LZMA SDK's 'lzma' tool.  The latter used what was
called the 'LZMA-Alone' format, which consisted of 13 bytes of header
information followed by a raw lzma-compressed byte-stream.  7zip, on the
other hand, used a much more complicated file format capable of hosting
multiple files, spanned archives, and other features. The only
similarity is that the core data compression algorithm used by both is
LZMA.

2. LZMA Utils
Eventually, a unix port of the LZMA SDK appeared, in the form of the
LZMA Utils distribution, which reorganized the original source code, and
provided the decompression code in library form (liblzmadec). It also
provided a version of the 'lzma' program, but with a completely
different command-line interface. The LZMA Utils version consciously
mimicked the command-line options of the familiar gzip and bzip2 tools,
while the original LZMA SDK version was...different. Very different.
This is because the LZMA SDK's tool was originally intended just as a
test and development utility, to help refine the algorithm. So, it has
a number of 'compression guru' options that no sane user cares to use,
and very few of the 'normal user' options that they would.

   LZMA Utils: (Lasse Collin)
  lzma -d foo.tar.lzma
 uncompress to (implied) foo.tar, and remove
 original compressed file.
  lzma foo.tar
 compress to (implied) foo.tar.lzma, and remove
 original uncompressed file.
  Supports familiar tuning options like -0 .. -9
  Sends output data to stdout using -c
  Could be invoked under alternate names (symlinks)
  for different behavior:
  unlzma == lzma -d  (uncompress)
  lzcat  == lzma -dc (uncompress to stdout)

   LZMA SDK: (Igor Pavlov)
  lzma d foo.tar.lzma foo.tar
  lzma e foo.tar  foo.tar.lzma
 mode d/e is the required first non-option argument
 both input and output files must be specified
  stdout? what's that?

Finally, LZMA Utils also shipped a number of helpful scripts similar to
the familiar ones from gzip and bzip2:
  lzdiff/lzcmp, lzgrep/lzegrep/lzfgrep, lzless/lzmore

So, the LZMA SDK version was hardly suitable for replacing or augmenting
the existing bzip2 and gzip compression programs on unix systems,
expecially as the most common use was in conjuction with tar.  But tar
expects compression programs to satisfy a common command-line argument
format, and to be able to manipulate data on standard streams. Most
linux distributions have standardized on LZMA Utils.

The lzma tool from both LZMA SDK and LZMA Utils each support the
LZMA-Alone (.lzma) file format, as does the liblzmadec library from
LZMA Utils.

However, the .lzma file format (e.g. LZMA-Alone) is not sufficient for
modern needs, as it (1) had no 'signature bytes' so compressed files
were difficult to automatically detect and verify, (2) it had no
provision for 

Re: [PATCH] maint: ship .xz, not .lzma

2010-09-14 Thread Charles Wilson
On 9/14/2010 11:02 AM, Bob Friesenhahn wrote:
 On Tue, 14 Sep 2010, Gary V. Vaughan wrote:

 No objections.

 I'm curious to know what the history of lzma and xz is that makes this
 desirable though.
 
 I am curious to know if XZ Utils has now achieved a proper stable
 release or if it will be perpetually in a prototype like state.

Well, the 4.999.9beta is supposedly the final beta.  However, it was
released 2009-08-27 (e.g. a year ago) -- so, in order to keep that
promise (!) the webpage now says:

 A snapshot from the git repository is available too, and is generally
 recommended over 4.999.9beta.

 xz-4.999.9beta-180-ge23e.tar.gz (1114 KiB)

How that differs from a new RC/beta I don't know, but there you go.
Anyway, if you check the git logs, you'll see that most of the recent
changes have been stabilization and documentation, so I think it is
asymptotically converging on an actual release. Of course you know the
problem with asymptotes...

 Its
 code is quite large and quite obtuse.

Meh.  Most of that is for the alternate compression schemes (e.g. there
are schemes tuned specifically for compressing mips binary code, and x86
binary code, etc).  The core LZMA compression and XZ file format
handling is maybe only 1.5x-2x bzip2.

Take a look at the xz-embedded repo; it includes only the XZ and core
LZMA stuff:
git clone http://git.tukaani.org/xz-embedded.git

 Also, I remain curious to know why 'lzip' has never been considered as a
 suitable replacement.  Lzip accomplishes the same thing with 10 times
 less code, and better fits the traditions previously established by gzip
 and bzip2. 

I'm not sure that last clause (...better fits...) is true. Surely, the
LZMA SDK code and utilities were...different.  But the LZMA Utils and
its successor XZ Utils were *specifically* written to follow the
gzip/bzip2 traditions.

When I added xz support to cygwin's setup.exe via liblzma, the glue code
to do so was VERY similar to the corresponding .gz and .bz2 glue code...
Ditto when similar glue was added to BSD's libarchive.

 Its only limitation is that it requires a C++ compiler.  The
 claim is made that it is not portable because it does not come with a
 megabyte-sized configure script, but it does not need such a huge
 configure script because it only uses portable ANSI interfaces, similar
 to the way gzip only requires ANSI C.  This sort of decision-making
 results in people feeling that GNU software is excessively complex
 bloatware.  Personal politics and status has become more important than
 proper technical analysis.

Err...I don't think I want to get into a religious war. (I will say
this, tho: requiring a 1MB C++ runtime library like libstdc++.so at
*runtime* is not _my_ usual approach when trying to create non-bloated
software, and hardly makes up for the savings of not having a 1MB
configure script at *build* time.  Sure, on real unix you'll already
have that runtime lib installed, but lzma/xz was pitched on unix as
usable on embedded systems and in-kernel too...the same can't be said
for lzip)

The fact is, whether we @ libtool like it or not, .lzma compression had
been adopted by most other GNU projects as the next great compression
scheme (whether it really WAS or not, is debatable as all such
assertions are).  When the two primary forces behind lzma-on-unix (Igor
Pavlov and Lasse Collin) got together to formulate the xz extension, the
early .lzma adopters -- e.g. many GNU projects -- followed along.

As one of those GNU projects, automake added support for dist-lzma --
and later dist-xz, not dist-lzip.

That's where we are.

If you want to start an xz-vs-lzip fight, propose the appropriate
support for dist-lzip on automake-patches and fight it there. :-)

--
Chuck



[PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
ensure old_library name is used as linklib when possible.
---
This patch corrects the (long-standing?) failure of mdemo-exec.test on
mingw, but also some non-fatal anomalies in cygwin on the same tests.
Basically, when dlopen'ing static libraries, but when both shared and
static libs exist, the extracted symbol names put into the
lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from
the import library instead of the static one.  For PE/COFF, this makes
a difference; and on mingw that difference caused the mdemo_static test
to fail.

Test results:

cygwin
--
old test suite: All 122 tests passed (2 tests were not run)
new test suite: 111 tests behaved as expected. 9 tests were skipped.

mingw
-
old test suite: All 122 tests passed (2 tests were not run)
new test suite: 108 tests behaved as expected. 12 tests were skipped.

OK to push?

--
Chuck


 libltdl/config/ltmain.m4sh |   12 +---
 1 files changed, 9 insertions(+), 3 deletions(-)

diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index d8e0fe1..6ae2e43 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5650,9 +5650,15 @@ func_mode_link ()
 
# Get the name of the library we link against.
linklib=
-   for l in $old_library $library_names; do
- linklib=$l
-   done
+   if test -n $old_library 
+  { test $prefer_static_libs = yes ||
+test $prefer_static_libs,$installed = built,no; }; then
+ linklib=$old_library
+   else
+ for l in $old_library $library_names; do
+   linklib=$l
+ done
+   fi
if test -z $linklib; then
  func_fatal_error cannot find name of link library for \`$lib'
fi
-- 
1.7.1




Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
On 9/12/2010 10:20 AM, Ralf Wildenhues wrote:
 Hi Charles,
 
 * Charles Wilson wrote on Sun, Sep 12, 2010 at 03:19:51PM CEST:
 * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs,
 ensure old_library name is used as linklib when possible.
 ---
 This patch corrects the (long-standing?) failure of mdemo-exec.test on
 mingw, but also some non-fatal anomalies in cygwin on the same tests.
 Basically, when dlopen'ing static libraries, but when both shared and
 static libs exist, the extracted symbol names put into the
 lt__PROGRAM__LTX_preloaded_symbols array were mistakenly extracted from
 the import library instead of the static one.  For PE/COFF, this makes
 a difference; and on mingw that difference caused the mdemo_static test
 to fail.
 
 Why does the patch have [cygwin|mingw] in the summary?  It changes a
 code path that is shared by most systems out there, no?  I'd rather see
 a 'Fixes foo on Cygwin and MinGW' in the details, so that when searching
 the summary log later, this patch isn't mistaken for a w32-only one.

OK, I'll change the summary before committing.

 I think the patch is right, but this is one that *really* needs wide
 range testing on several hosts.  Since I'm about to tick off another
 round of testing, I suggest you commit it so that it can be included
 in the testing.

OK.

--
Chuck



Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
On 9/12/2010 10:25 AM, Ralf Wildenhues wrote:
 Also, $linklib is used for several other things.  It would seem prudent
 to make sure it is clear that this is a very intrusive patch, or use
 another helper variable to make it less intrusive.

Oh, I think linklib was *wrong* no matter what.  If you requested static
(either via -static, -all-static, or -static-libtool-libs), AND you have
an $old_library name...then by golly you ARE going to link against that
$old_library.

So, when assigning $linklib, you really should take into consideration
all those factors.  Prior to this patch, $linklib was always set to the
last element of $library_names -- and was only set to $old_library if
there WERE no dynamic libs, and all you HAD was the static lib.  It
didn't care about the various -static options AT ALL.

--
Chuck



Re: [PATCH] [cygwin|mingw] Correct static lib symbol extraction failure.

2010-09-12 Thread Charles Wilson
On 9/12/2010 10:20 AM, Ralf Wildenhues wrote:
 I suggest you commit it so that it can be included
 in the testing.

Pushed as:

When assigning $linklib value, honor [-all]-static[-libtool-libs]

* libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
and static library exists, ensure old_library name is used as $linklib.
Fixes failure on mingw when both static and shared libraries are
present.

---
 ChangeLog  |9 +
 libltdl/config/ltmain.m4sh |   12 +---
 2 files changed, 18 insertions(+), 3 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index b9abe8a..6b76340 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,12 @@
+2010-09-12  Charles Wilson  ...
+
+   When assigning $linklib value, honor [-all]-static[-libtool-libs]
+
+   * libltdl/config/ltmain.m4sh (func_mode_link): When prefer_static_libs
+   and static library exists, ensure old_library name is used as $linklib.
+   Fixes failure on mingw when both static and shared libraries are
+   present.
+
 2010-09-12  Ralf Wildenhues  ...

tests: work around zsh use of $options variable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 509a421..6036f4f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -5652,9 +5652,15 @@ func_mode_link ()

# Get the name of the library we link against.
linklib=
-   for l in $old_library $library_names; do
- linklib=$l
-   done
+   if test -n $old_library 
+  { test $prefer_static_libs = yes ||
+test $prefer_static_libs,$installed = built,no; }; then
+ linklib=$old_library
+   else
+ for l in $old_library $library_names; do
+   linklib=$l
+ done
+   fi
if test -z $linklib; then
  func_fatal_error cannot find name of link library for \`$lib'
fi
-- 
1.7.1




Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'

2010-09-11 Thread Charles Wilson
On 9/11/2010 2:47 AM, Peter Rosin wrote:
 Den 2010-09-11 07:02 skrev Charles Wilson:
 OK to push as obvious?
 
 To me, pushing as obvious is the same as pushing without
 asking (and when I do, I make damn sure I don't push anything
 bad). This makes me curious, what does it mean to you?

It means other than ensuring that I didn't do something stupid like
breaking 'make', I didn't try to do any before/after testing to prove
that this fixed whatever the typo apparently broke.  But the change
is obviously correct, and should't really need that kind of justification.

However...I don't have the authority to push *anything* without
approval, so I *can't* simply say pushed as obvious.

--
Chuck



Re: [PATCH] Correct typo: $sharedlib_from_linklib_cmd missing '_cmd'

2010-09-11 Thread Charles Wilson
On 9/11/2010 4:16 AM, Ralf Wildenhues wrote:
 OK to push.

Pushed.

--
Chuck




Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-10 Thread Charles Wilson
On 9/10/2010 9:11 AM, Peter Rosin wrote:
 func_cygming_gnu_implib_p
 -
 
 6. Dead code. Needs the sharedlib_from_linklib - sharedlib_from_linklib_cmd
 typo fix. So, a previous testsuite deficiency that should not hold back this
 patch.
 
 func_cygming_gnu_implib_p and func_cygming_ms_implib_p
 --
 
 7. Dead code. Needs the sharedlib_from_linklib - sharedlib_from_linklib_cmd
 typo fix. So, a previous testsuite deficiency that should not hold back this
 patch.

As I explained, this is not dead code.  dead code is code that can
never be executed under any circumstances.  These code paths can be
executed, if (1) you are on cygming and have an old binutils whose
dlltool doesn't support --identify, and (2) you link using -dlopen
foo.dll.a.

(2) isn't that uncommon, even if we don't do it in the test suite. (1)
is unlikely...and getting more so every day -- but not impossible.

It's...mostly dead.  Mostly dead is slightly alive.  With all dead,
well, with all dead there's usually only one thing you can do...Go
through his clothes and look for loose change.

--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-10 Thread Charles Wilson
On 9/10/2010 10:07 AM, Peter Rosin wrote:
 It's dead, you need the below patch to animate it. There is no sane
 way you can influence the sharedlib_from_linklib variable.

Well, that's just a bug with a known but uncommitted patch.  So he's
stopped breathing, but it's nothing a little CPR won't fix.

--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
On 9/9/2010 5:47 AM, Peter Rosin wrote:
 Anyway, both fail in pretty much the same way for me:
 
 can't open the module tests/mdemo/foo1.la!
 error was: The specified module could not be found.
 can't open the module tests/mdemo/foo1!
 error was: The specified module could not be found.
 can't open the module tests/mdemo/libfoo2.la!
 error was: The specified module could not be found.
 can't open the module tests/mdemo/libfoo2!
 error was: The specified module could not be found.

Yes.

The problem is in how mdemo_static.exeS.c is constructed;
lt__PROGRAM__LTX_preloaded_symbols contains header entries for each
-dlpreopen'ed library, but they are:

  {cygsub-0.dll, (void *) 0},

when they should be

  {libsub.a, (void *) 0},

Manually making that change and re-linking fixes the error.  I just need
to track down *why* the wrong library name is being used and fix it,
without breaking mdemo.exeS.c (the one that dlpreopens the DLLs, and
SHOULD be specifying 'cygsub-0.dll' etc).

--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
On 9/9/2010 3:19 AM, Peter Rosin wrote:
 Den 2010-09-09 06:18 skrev Charles Wilson:
 Peter, a question about your current patch series: with it only
 partially committed, do you expect errors?  Are we waiting for some
 other change upon which the current series depends, before it all just
 works again...or are things fubared now?
 
 I wouldn't knowingly have committed anything half-assed like that. I
 expected things to be better now that they were before.

Sorry, I just lost track of the thread of the various conversations.
When you presented a chain of 7 patches, and then they weren't all
committed simultaneously, I started to wonder (1-4, then later 5, then
even later 6, and 7 still hasn't been).

 Right now, I'm seeing a regression just building libltdl. It builds
 correctly the first time -- but when I try to run the old test suite,
 a rule gets triggered to rebuild libltdl.al:

 I suspect that there is a mismatch between the targets (and deps) in the
 Makefile (and the .deps/*.P files), and the new pre-converted filenames
 being generated by $to_tool_file_cmd.
 
 That might very well be the cause, as I didn't think of that case at all.

 Well, it was broke, you just didn't notice that low max_cmd_len failed
 in more ways than you assumed. That part is fixed.

You're right.  I didn't mean to sound so accusatory...
 
 I'm wondering if, when $build=MSYS, we could turn off all of the libtool
 to_tool_file_cmd stuff, EXCEPT when generating the contents of an @file.
 
 I agree, we should implement some kind of lazy strategy for MSYS, so
 that we don't do any needless conversions.

(I like lazy. Lazy is good.)

  You know, just fix the broken stuffwithout breaking other,
 previously working, stuff?  

...like this.  At first, I thought *every* -exec test was broken, and I
was quite flummoxed.  But that was PIBKAC.  After a clean rebuild, I saw
that it was only the ever-painful mdemo-*-exec tests that were failing
(along with new mdemo-*-make test failures).  So, it wasn't nearly as
bad as I originally thought...but I didn't revise my entire partially
composed message to suit the new facts.  Sorry about that.

 (I mean, you're basically removing the whole
 point of msys; why not just use cygwin instead, if you're not going to
 let msys do for you what it was designed to do?)
 
 You know, I did think that was what I was doing, fixing broken stuff
 without breaking other previously working stuff. I have been running
 the testsuite to death lately and can't understand how this failure
 has gone undetected. But it's clearly there. My bad, and sorry for the
 inconvenience.

No, I should have done more testing and validation of your patch series
in its new incarnation.  I just didn't have time with all the sysroot
testing in 57 varieties (plus building and rebuilding multiple cross
compiler and sys-root contents...for multiple $host/$build
combinations...), then my latest gigantopatch, ...

And besides, I *had* tested an earlier incarnation, hadn't I? Surely
that was good enough.  I mean, nothing could possibly have changed in
libtool over two years that would cause a working patch series to
regress after a simple rebase -- or, as in your case, a 95% rewrite --
correct?

Not.

Sigh.

It's my own fault; I should have done more testing earlier.
 
--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
On 9/9/2010 11:33 AM, Peter Rosin wrote:
 Ok, I bisected the failure to e83da49a1faf9df1c7e351df9e9b175
 [cygwin|mingw] fix dlpreopen with --disable-static
 
 You know, just fix the broken stuff...without[couldn't resist]

Oh, I know.  This was *precisely* what that patch was supposed to fix,
and DID fix back in the depths of time when it was first created, and --
I thought -- continued to fix in modern libtool.  Only now, I *guess*
because of some additional intervening changes in other parts of
libtool, it no longer actually fixed it!  However, because it DID fix
the issue on cygwin -- or, rather, did not re-break it  -- AND the mingw
(re)failure was hidden behind a separate fault, I didn't realize the
patch no longer actually FIXED the problem it was intended to fix, on mingw.

So...the patch didn't break any new tests that weren't already failing
(for other reasons) on mingw -- but neither did it actually fix what it
claimed to.  At least on mingw.  aarrggh.

Now, it confuses me that you state that your bisection hit that commit;
I'm VERY surprised that mdemo actually worked on mingw, PRIOR to that
commit.

After all, the point of that patch was to correct the FAILURE of that
particular test!

So, somewhere between 2009-01 and e83da49a, some OTHER change to libtool
fixed (?) the mdemo test on mingw/msys.

Sigh.

I think this whole issue arose because of the delay in reviewing that
patch.  Something changed underneath it, and instead of fixing the
problem, the patch (re)broke it.  And I didn't notice because (a) stuff
continued to work on cygwin, and (b) there was another failure, in the
same test, on mingw, which hid the fact that the updated patch (re)broke
another aspect of that test.

 Maybe you knew that this patch was the cause of the regression, but
 I didn't understand that until I bisected the regression. Your comment
 a few message back:
 
 Den 2010-09-09 00:14 skrev Charles Wilson:
 (However, there is an unfixed bug here; apparently something has changed
 in libtool between when this patch was created, and when it was
 committed, such that the static lib part no longer works properly; this
 is why on cygwin and mingw the mdemo-exec tests STILL fail.  Very
 frustrating.  I plan to track this down in the next day or so).
 
 came into new light. I mean, this patch probably refers to the
 above mentioned commit, right?

Yes, it does.

I'm no expert on git bisect; if it's not to much trouble, could you
attempt to determine when, after 2009-01, mdemo started to work on
mingw/msys?  (Actually, localizing that on cygwin might be good enough,
if you don't have msysgit installed)

P.S. In my defense, the patch in question fixed *multiple* issues with
the whole symbol extraction behavior when both static and shared libs
exist; some of which were just bad practice but wouldn't actually cause
mdemo to fail.  See the description here:
http://lists.gnu.org/archive/html/libtool-patches/2010-06/msg00163.html


--
Chuck



Re: [PATCH] Fix dependency tracking for MSYS/MinGW.

2010-09-09 Thread Charles Wilson
On 9/9/2010 4:59 AM, Peter Rosin wrote:
 As discussed in that other thread, namely
 http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00105.html
 I accidentally broke MSYS/MinGW. Here's an improved version of the patch
 shown in that message to fix the build issue. Sorry again.
 
 Ok to push?

I can't approve, but it does appear to fix the mdemo-make failure on
MinGW/MSYS.  Running full test suite (MinGW/MSYS) now.  Should be
finished in four or five hours.  Then on to the mdemo-exec/MinGW/MSYS
problem as discussed in the other thread.

--
Chuck



Re: [PATCH] Fix dependency tracking for MSYS/MinGW.

2010-09-09 Thread Charles Wilson
On 9/9/2010 12:57 PM, Charles Wilson wrote:
 On 9/9/2010 4:59 AM, Peter Rosin wrote:
 As discussed in that other thread, namely
 http://lists.gnu.org/archive/html/libtool-patches/2010-09/msg00105.html
 I accidentally broke MSYS/MinGW. Here's an improved version of the patch
 shown in that message to fix the build issue. Sorry again.

 Ok to push?
 
 I can't approve, but it does appear to fix the mdemo-make failure on
 MinGW/MSYS.  Running full test suite (MinGW/MSYS) now.  Should be
 finished in four or five hours.

Mmm...much faster PC...

Full test results (of the second version of this patch; the one that was
the first one posted with this subject line):

MinGW/MSYS:
===
old: 2 of 104 tests failed (2 tests were not run)
As expected, the two failures are the mdemo exec tests:
FAIL: tests/mdemo-exec.test
FAIL: tests/mdemo2-exec.test

new: 102 tests behaved as expected. 18 tests were skipped.

I know a slightly different version of this patch has already been
pushed, but I figure test results are never a bad thing.

--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-09 Thread Charles Wilson
On 9/9/2010 3:56 PM, Ralf Wildenhues wrote:
 I understand that you're doing a difficult bug hunt here, and 6/7 is the
 only unapplied patch of this series (right?).  I've looked at 6/7 again,
 and conclude that it has a low chance of regressing.

I agree.

 If it makes things easier for you, then I'm fine with you going ahead
 and applying the patch.

I don't think the uncommitted portions of Peter's series affect this
particular bug hunt (now that the one regression has been corrected).
This one is all me. :-(

OTOH, I'm sure Peter would be very happy to push his remaining patches...

 Secondly, I can help with unsupervised git bisect if you need.  In
 http://lists.gnu.org/archive/html/bug-libtool/2010-09/msg6.html,
 I posted a bisect script for a slightly different bug; for your case,
 you should adjust reconfdirs (for efficiency) and TESTS and the failure
 grep.  In the 'git bisect start' command line, you need to specify one
 known-bad and one known-good revision.

I'll take a look, but it may actually be faster to do it old-school:
just trace thru the failing case in git master-NOW, figure out what's
going wrong, and fix it.
 
 Last but not least, IIUC then you've complained about possibly multiple
 failures masking.  Is this specifically about the stresstest?  To
 alleviate this in the future, we can modify stresstest to fan it out
 into several test groups (so separate issues have a higher chance of
 producing separate failures), or modify it so it runs all tests (even if
 some failed earier) and summarizes the failing instances at the end.

Naw, it's not stresstest.  It's just mdemo (and mdemo-2) really push all
the various bits of libtool and libltdl very hard.  It's a very good
test that way.

The problem is we've/I've been too complacent about known failures in
that test on MinGW/MSYS.  Sure...it had known failures -- but by
ignoring them, more unknown failures crept in and were hidden by the
known ones.  Now that we're trying to fix it...we discover that the
leftover mashed potatoes in the fridge grew their own mold ecosystem...

--
Chuck



Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.

2010-09-08 Thread Charles Wilson
On 9/8/2010 4:54 PM, Peter Rosin wrote:
 Hmmm, but @file makes it harder than necessary to debug on MSYS, since
 the automatic command line conversion make the n...@file branch work
 there. And the @file branch is probably bad for performance on MSYS too,

FYI, the patch that adds @/looks/like/a/unix/path to the list of stuff
that MSYS automatically converts to C:/msys-inst-root/dos/format/ was
accepted and committed a yesterday. So it looks like MSYS-1.0.16 will
include this feature...but we don't really have a schedule for when that
will be released.

 since the manual forking conversion is so much slower than the
 automatic command line conversion. I think some kind of lazy conversion
 strategy -- like the one in 'compile' -- would be a worthwhile
 optimization.

So, right now on MSYS you still manually convert @unix-path to
@dos-format, right?   If so, once MSYS-1.0.16 is released should libtool
just assume that support is present and require msys-latest, or would an
additional feature test be required?

--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-08 Thread Charles Wilson
On 9/8/2010 6:14 PM, Charles Wilson wrote:
 On 9/8/2010 5:52 PM, Peter Rosin wrote:

 sharedlib_from_linklib_cmd, which is not used anywhere according
 
 # no lafile. user explicitly requested -dlpreopen import library.
 $sharedlib_from_linklib $dlprefile
 ^
Looks like something got dropped somewhere.

 (However, there is an unfixed bug here; apparently something has changed
 in libtool between when this patch was created, and when it was
 committed, such that the static lib part no longer works properly; this
 is why on cygwin and mingw the mdemo-exec tests STILL fail.  Very
 frustrating.  I plan to track this down in the next day or so).

Hmm...I wonder...is this the cause of the mdemo-exec regression?  I
don't THINK so, because that testcase uses the .la files and not the
.dll.a ones IIRC, but it should probably be fixed regardless.  I'll find
out...

--
Chuck



Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-08 Thread Charles Wilson
On 9/8/2010 5:52 PM, Peter Rosin wrote:
 Den 2010-09-05 23:29 skrev Ralf Wildenhues:
 * Peter Rosin wrote on Sun, Sep 05, 2010 at 10:02:11PM CEST:
 Subject: [PATCH 6/7] Convert file name to toolchain format when invoking 
 $NM.

 * libltdl/config/ltmain.m4sh (func_generate_dlsyms)
 (func_win32_libid, func_cygming_gnu_implib_p)
 (func_cygming_ms_implib_p): When using the name lister to find
 symbols in files, convert the file names to a format appropriate
 for the tool.

 You're gonna hate me for this, I already know, but: does this patch fix
 testsuite failures, are all code paths covered?  If not, we need to
 improve the test suite.  If yes, please mention them in the log, thanks.
 
 Those in func_cygming_gnu_implib_p and func_cygming_ms_implib_p
 appear to be dead code. Both functions are only called from
 func_cygming_dll_for_implib_fallback which only use is that it
 is assigned to the cache variable lt_cv_sharedlib_from_linklib_cmd
 whose value is in turn only assigned to the LT_DECL variable
 sharedlib_from_linklib_cmd, which is not used anywhere according
 to my searching.

Err...yes it is, around line 2546 in ltmain.m4sh:

  for dlprefile in $dlprefiles; do
func_verbose extracting global C symbols from \`$dlprefile'
func_basename $dlprefile
name=$func_basename_result
case $host in
  *cygwin* | *mingw* | *cegcc* )
# if an import library, we need to obtain dlname
if func_win32_import_lib_p $dlprefile; then
func_tr_sh $dlprefile
eval curr_lafile=\$libfile_$func_tr_sh_result
dlprefile_dlbasename=
if test -n $curr_lafile  func_lalib_p $curr_lafile; then
  # Use subshell, to avoid clobbering current variable values
  dlprefile_dlname=`source $curr_lafile  echo $dlname`
  if test -n $dlprefile_dlname ; then
func_basename $dlprefile_dlname
dlprefile_dlbasename=$func_basename_result
  else
# no lafile. user explicitly requested -dlpreopen import library.
$sharedlib_from_linklib $dlprefile
dlprefile_dlbasename=$sharedlib_from_linklib_result
  fi

Now, this happens only when -dlprepen foo.dll.a (as opposed to
foo.la). AND sharedlib_from_linklib is only assigned to
func_cygming_dll_for_implib_fallback when dlltool does not support the
--identify and --identify-strict options.  All *current* binutils
packages shipped by MinGW, MinGW64, and cygwin support that option.

So to trigger this, you have to

a) configure with
lt_cv_sharedlib_from_linklib_cmd=func_cygming_dll_for_implib_fallback

b) link using -dlpreopen /path/to/foo.dll.a

I've actually done that manually sometime in the last six months or so,
but I don't remember exactly when.  It worked then...




My initial plan was to remove _fallback and its supporting functions
about a year after the first official release of libtool containing this
stuff (gak, that giant sed script is AWFUL...)

We haven't even HAD that official release yet, so it's still a bit
premature to remove it, IMO. :-)

(However, there is an unfixed bug here; apparently something has changed
in libtool between when this patch was created, and when it was
committed, such that the static lib part no longer works properly; this
is why on cygwin and mingw the mdemo-exec tests STILL fail.  Very
frustrating.  I plan to track this down in the next day or so).

--
Chuck



Re: [PATCH] [cygwin|mingw|cross-compile]: Path conversion support.

2010-09-08 Thread Charles Wilson
On 7/18/2010 9:07 PM, Charles Wilson wrote:
 linux-cygwin cross:
 
 old: 2 of 112 tests failed (12 tests were not run)
   FAIL: tests/demo-hardcode.test
   FAIL: tests/depdemo-relink.test
 new: AWFUL again -- but there's an explanation
  88 tests were run, 28 failed (3 expected failures).
  29 tests were skipped.
 I was using my new, sysroot-less linux-cygwin cross compiler, so
 I expected good results just like the last time I used this compiler.
 However, UNLIKE last time, I went ahead an set LT_CYGPATH to point to
 my wine/cygwin cygpath.exe.  Well, as has been demonstrated, it coredumps
 a lot -- and prints lots of gobbledygook.  The new testsuite doesn't like
 gobbledygook.  LAST time, I left LT_CYGPATH unset, so libtool simply
 skipped that part of the test.
 
 I'll re-run again, without LT_CYGPATH set, just to be sure...

FWIW, ensuring LT_CYGPATH is not set doesn't actually make the testsuite
performance any better.  You have to actually turn off binfmt.  Here's why:

m4_define([LT_AT_EXEC_CHECK],
[lt_exe=$1; if test -f $1$EXEEXT; then lt_exe=$lt_exe$EXEEXT; fi
AT_CHECK([if $lt_exe $5; then :; else lt_status=$?; ]dnl
 [  m4_ifval([$2], [test $lt_status != $2  ])]dnl
 [  test X$host != X$build  test -x $lt_exe  exit 77; ]dnl
 [  exit $lt_status; fi],[$2],[$3],[$4])
])


The way LT_AT_EXEC_CHECK works is:
   * ALWAYS try to run the executable
   if it passes, great
   *   otherwise, compare the exit status with a provided value
  if it matches the expected value, great
   *  otherwise, if crossbuilding and the exe exists and is
 marked executable, then
   * at least building the app succeeded: SKIP
   * otherwise, return with the exit status of the app

The problem occurs because with cygwin-1.7 + Wine, running apps (almost)
always fails, but Wine itself returns a successful error code. But...the
stdout/stderr values are definitely NOT what the test which CALLED
LT_AT_EXEC_CHECK expects.

The only way I've found to make this work is to turn off binfmt, so
that Wine is NOT used to launch the cygwin exe -- linux tries to run the
.exe itself.  This, of course, fails...and that allows the 'if
crossbuilding' clause to kick in, and the test is marked SKIP.

Note that this is already documented in the recent changes to
libtool.texi -- I just hadn't spelled it out in a message to this list,
and I'd promised to post the best-case linux-cygwin test results, so...

However, LT_AT_EXEC_CHECK *is* doing the right thing here.  We *want* to
first try to run the (possibly foreign) $host executable.  What if
$build=x86_64-pc-linux-gnu and $host=i686-pc-linux-gnu?  That should
work, and we shouldn't just assume it won't and automatically SKIP.  Or
better yet, $build=i686- vs. $host=i386-?

I think this is a Wine bug; I'll report it upstream.  But for now...on
the linux-cygwin case, I'll always be reporting testsuite results with
binfmt disabled.

And linux-mingw results with binfmt enabled...


linux-cygwin:
==
old testsuite: 2 of 114 tests failed (10 tests were not run)
FAIL: tests/demo-hardcode.test
FAIL: tests/demo-relink.test
demo-relink should be marked SKIP if cross compiling
I don't really know why demo-hardcode failed; I don't think hardcoding
is supported in PE/COFF executables, so what gives?

demo-hardcode.test: ===  Finding libtool.m4's guesses at hardcoding values
= Searching for hardcoded library directories in each program
.libs was not hardcoded in `hc-direct', as libtool expected
.libs was not hardcoded in `hc-libflag', which fooled libtool
`hc-libpath' was not linked properly, as libtool expected
.libs was not hardcoded in `hc-minusL', as libtool expected


I think this is wrong, for both cygwin and mingw:
hardcode_libdir_flag_spec=-L\$libdir
-L just sets the search path during linking, and has nothing to do with
a runtime-hardcoded path. For reference, native linux (ELF) has this:
hardcode_libdir_flag_spec=\${wl}-rpath \${wl}\$libdir



new testsuite:
ERROR: 63 tests were run,
4 failed (2 expected failures).
57 tests were skipped.
The two unexpected failures were:
 38: Link order test  FAILED (link-order.at:121)
112: Run tests with low max_cmd_len   FAILED (cmdline_wrap.at:43)


38 seems to be an oversight in the sysroot support, but I haven't
thought about it too much:

libtool: link: warning: library
`/home/me/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/liba.la'
was moved.
libtool: link: cannot find the library
`/opt/devel/cygwin/i686-pc-cygwin/sys-root/home/me/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/libb.la'
or unhandled argument
`=/home/cwilson/tmp/libtool/_build-linux-cygwin-cross-sysroot/tests/testsuite.dir/038/old/lib/libb.la'

Note that it's expecting my entire build area to have been relocated
underneath my compiler's sysroot

Re: [PATCH 6/7] Convert file name to toolchain format when invoking $NM.

2010-09-08 Thread Charles Wilson
Peter, a question about your current patch series: with it only
partially committed, do you expect errors?  Are we waiting for some
other change upon which the current series depends, before it all just
works again...or are things fubared now?

Right now, I'm seeing a regression just building libltdl. It builds
correctly the first time -- but when I try to run the old test suite,
a rule gets triggered to rebuild libltdl.al:

(cd ../..; make `echo ../../libltdl/libltdlc.la | sed
's,.*\.\./libltdl/,libltdl/,g'`)
make[1]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw'
make[1]: *** No rule to make target
`..\\libtool\\libltdl\\loaders\\preopen.c', needed by
`libltdl/loaders/libltdl_libltdlc_la-preopen.lo'.  Stop.


Going to the top level and simply typing 'make' also triggers the error:

$ make
make  all-recursive
make[1]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw'
make[2]: Entering directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw'
make[2]: *** No rule to make target
`..\\libtool\\libltdl\\loaders\\preopen.c', needed by
`libltdl/loaders/libltdl_libltdl_la-preopen.lo'.  Stop.
make[2]: Leaving directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw'
make[1]: *** [all-recursive] Error 1
make[1]: Leaving directory
`/c/cygwin-1.7/usr/src/packages/libtool/git/build-mingw'
make: *** [all] Error 2

This is with MSYS/MinGW (but the git tree is over on my cygwin
installation, since I only have cygwin-git installed).

I suspect that there is a mismatch between the targets (and deps) in the
Makefile (and the .deps/*.P files), and the new pre-converted filenames
being generated by $to_tool_file_cmd.


Basically, it appears that this is case where
if-it-ain't-broke-don't-fix-it should have applied, and MSYS/MinGW was
*not* broke.  At least, not anywhere except inside @file contents, and
maybe the actual name OF that @file (this latter case is the reason
behind the recent msys-1.0.16 change).

I'm wondering if, when $build=MSYS, we could turn off all of the libtool
to_tool_file_cmd stuff, EXCEPT when generating the contents of an @file.
 You know, just fix the broken stuffwithout breaking other,
previously working, stuff?  (I mean, you're basically removing the whole
point of msys; why not just use cygwin instead, if you're not going to
let msys do for you what it was designed to do?)

I've put off trying to track down the error wrt mdemo until after this
is resolved; I can't really compare the behavior of the (previously
working) mdemo-static-make/mdemo-static-exec and the broken static
subcase of mdemo-make/mdemo-exec, when neither one will actually build
any longer...

--
Chuck



Re: [PATCH 1/7] Add file name conversion from $build to toolchain.

2010-09-05 Thread Charles Wilson
[meta-request: in the future, could you not use whatever option it is
that causes the entire patch message to be stored at attachment to the
actual message...this is a little awkward to reply-to:]

On 9/5/2010 3:58 PM, Peter Rosin wrote:
nothing

...which means all replies have to manually cut-n-paste-as-quotation
which is painful.  Unless somebody knows what option to set in TBird to
DTRT?

On 9/5/2010 3:58 PM, Peter Rosin wrote:
 +...@defvar to_tool_file_cmd

Urk.  I guess I ought to go ahead and define to_host_file_cmd...

You might also want to add a line or two to the new section concerning
the lying cygwin-mingw case:

 ...To force the
 correct file name conversion in this situation, you should do the
 following _before_ running configure:

  export lt_cv_to_host_file_cmd=func_convert_file_cygwin_to_w32

...Unless you plan to do all of that as part of some other pure-doc patch.

--
Chuck




Re: [PATCH 1/7] Add file name conversion from $build to toolchain.

2010-09-05 Thread Charles Wilson
On 9/5/2010 5:20 PM, Ralf Wildenhues wrote:
 Hi Peter,
 
 * Peter Rosin wrote on Sun, Sep 05, 2010 at 09:58:58PM CEST:
 Subject: [PATCH 1/7] Add file name conversion from $build to toolchain.

 * configure.ac: Ensure to_tool_file_cmd is available to Makefile.
 * libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): Add
 cache variable lt_cv_to_tool_file_cmd that describes how to
 convert file names from $build to toolchain format.
 * libltdl/config/ltmain.m4sh (func_to_tool_file): New function
 that utilizes the above.
 * Makefile.am: Ensure to_tool_file_cmd is included in
 TEST_ENVIRONMENT so that it is passed to (old testsuite) tests.
 * testsuite.at: Ensure to_tool_file_cmd is passed as a variable
 setting on the configure line for (new testsuite) tests.
 * doc/libtool.texi (libtool script content): Update with
 to_tool_file_cmd description.
 
 OK pending the issues that Charles had with the patch, plus nits below.

Actaully, if you read my recent reply closely, I don't have any issues
with *the patch* that Peter sent.  Only (1) the way the patch was sent
to the mailing list, (2) a note to myself that *I* need to document
to_host_file_cmd, and (3) the single comment about adding to the docu --
which could be part of this patch series or a later patch, as far as I
am concerned.

--
Chuck



Re: [PATCH] Adjust naming of MSVC import libraries.

2010-09-04 Thread Charles Wilson
On 9/4/2010 4:52 AM, Peter Rosin wrote:
 
 If you are using -lfoo, then you *must* use 'compile' as well as cl
 does not know about the -l option. So, I was thinking that 'compile'
 instead of just transforming -lfoo into foo.lib would walk the library
 search path (in the same order as cl would) and replace -lfoo with
 either of foo.lib or foo.dll.lib depending on which was found first
 and possibly also modified by any -static or -shared flags (also not
 supported by cl, so -static and -shared would have to be completely
 handled by 'compile' and would only affect -lfoo handling, at least
 in my current thinking).

Remember that -static and -shared, the gcc options, are not antonyms:

`-static'
 On systems that support dynamic linking, this prevents linking
 with the shared libraries.

`-shared'
 Produce a shared object which can then be linked with other
 objects to form an executable.

The former deals with what entities you will link to; the latter deals
with what type of output entity you will create.

For our current discussion, you would really only need to implement
-static handling; by default the search would prefer foo.dll.lib (but
would accept kernel32.lib).  With -static, the search would accept
only foo.lib.

As with cygming, the link phase for -static would never try to verify
that foo.lib was actually a static library and not an import lib; it
would have to be a name-based search only (for the reasons you describe
below).

-shared, obviously, would need to be translated into the appropriate
option to tell cl.exe to create a .dll (as opposed to an .exe).

 Note that -shared can't trigger 'compile' to always replace -lfoo with
 foo.dll.lib since a bunch of system libraries are shared but still
 named according as foo.lib (as Microsoft is obviously not following
 my naming convention). I think other system libraries are static
 and also named according to foo.lib, so it would do no good to prefer
 the import lib by naming it foo.lib and name the static lib something
 like foo.s.lib.

Right. That's the same conclusion we reached wrt .dll.a vs. .a

 Agreed.
 
 And the testsuite runs have finished and results are the same. I still
 want to push this.

I have no objections anymore, but I can't approve it.

--
Chuck



Re: [PATCH 7/7] Prefer $NM @file over calculating the cmd line length.

2010-09-04 Thread Charles Wilson
FYI, I just proposed the following for MSYS (when launching native
apps, like the MinGW binutils/gcc, or MSVC tools):

http://thread.gmane.org/gmane.comp.gnu.mingw.msys/4820
2010.09.04  Charles Wilson  ...

   * path.cc (msys_p2w): Support conversion of @file
   arguments.

If we're lucky, it'll be in MSYS-1.0.16.

--
Chuck



Re: [PATCH] Adjust naming of MSVC import libraries.

2010-09-03 Thread Charles Wilson
On 9/3/2010 7:59 AM, Peter Rosin wrote:
 So, I'm now proposing this naming scheme instead:
 
 static lib:  foo.lib
 shared lib:  foo-2.dll
 import lib:  foo.dll.lib
 
 which is a lot more consistent with the MinGW naming, i.e.:
 
 static lib:  libfoo.a
 shared lib:  libfoo-2.dll
 import lib:  libfoo.dll.a

The only reason MinGW could do this, is that when we developed the
cygmingw naming scheme, we simultaneously updated both gcc and ld to
understand the new names, and imposed a search order:


 For instance, when ld is called with the argument `-lxxx' it will
 attempt to find, in the first directory of its search path,

  libxxx.dll.a
  xxx.dll.a
  libxxx.a
  xxx.lib
  cygxxx.dll (*)
  libxxx.dll
  xxx.dll

 before moving on to the next directory in the search path.

 (*) Actually, this is not `cygxxx.dll' but in fact is
 `prefi.dll', where `prefix' is set by the `ld' option
 `--dll-search-prefix=prefix'.

This way, non-libtool unixish makefiles could always use -lfoo,
regardless of whether they were linking to a static lib or dynamic lib.
 We can't similarly change the behavior of cl.exe -- unless you want to
build THAT logic into the `compile' script (or is there a `linker' script)?

 On the negative side we have:
 
 * Inconsistent naming of import libs when comparing with other MSVC
 libraries. They are typically named as the static lib, but so are
 static libs, when that's what's shipped. Pick your poison.

Right. So anybody who uses libtool to build a core library, but then
wants to build an application (which doesn't use libtool) that links
against that DLL, will have to modify their makefile rules to say -lfoo.dll.

Really, what this means is that non-libtool clients of libfoo will have
to put detection machinery (in autoconf?) to determine whether libfoo.a
or libfoo.dll.a exists; Makefile.in will have to use a subst variable so
that either -lfoo or -lfoo.dll is specified in the Makefile...

This would include most of libtool's own built-in tests, I would think.

Unless `compile'/`linker' becomes a lot smarter, and abstracts all that.
(Actually, now that I think about this some more, modifying these
scripts to implement search rules is probably a bad idea; they need to
implement the SAME search rules as the underlying tool (cl.exe in this
case), otherwise you'd get inconsistent results.  So, scratch that idea).

 Besides, it's better to do this now, before the
 first release of libtool with MSVC support, than after.

Well, that's true.  I have some misgivings about this plan, but you know
best.

--
Chuck



Re: [PATCH] Adjust naming of MSVC import libraries.

2010-09-03 Thread Charles Wilson
On 9/3/2010 1:42 PM, Peter Rosin wrote:
 Den 2010-09-03 18:05 skrev Charles Wilson:
 This way, non-libtool unixish makefiles could always use -lfoo,
 regardless of whether they were linking to a static lib or dynamic lib.
 
 Well, -lfoo didn't work for both static and shared libs in non-libtooled
 use cases before this patch either, so status quo...

For MSVC.

Your assertion is not true for cygwin/gcc, mingw/gcc, or msys/gcc.

 We can't similarly change the behavior of cl.exe -- unless you want to
 build THAT logic into the `compile' script (or is there a `linker' script)?
 
 The thought did cross my mind. But not right now. (There is no 'linker'
 script, so I would put it in the 'compile' script.)
 
 On the negative side we have:

 * Inconsistent naming of import libs when comparing with other MSVC
 libraries. They are typically named as the static lib, but so are
 static libs, when that's what's shipped. Pick your poison.

 Right. So anybody who uses libtool to build a core library, but then
 wants to build an application (which doesn't use libtool) that links
 against that DLL, will have to modify their makefile rules to say -lfoo.dll.
 
 Or rename the import library files. But that's no fun either.

Right.  I think VizStudio handles this by putting treating the static
and shared libraries as different configurations; separate configs have
separate build dirs...even if the static library and the import library
have the same name (and it's usually up to the end user to set up
client's -L paths to point to the correct location of those libs based
on the desired configuration; e.g. by including ${CONFIGURATION_NAME} in
the -L path, I believe).

I've seen VizStudio-built projects use several different arrangements
for delivering these SDK-style items to end users; separate dirs, or --
as you suggest -- separate names (usually something like
'foo_shared.lib')  FFTW punts completely, and ships .def files
(instructing users to create their own import libs using the toolchain
mechanism of their choice; obviously then, the choice of import library
NAME is up to the end user).

 Really, what this means is that non-libtool clients of libfoo will have
 to put detection machinery (in autoconf?) to determine whether libfoo.a
 or libfoo.dll.a exists; Makefile.in will have to use a subst variable so
 that either -lfoo or -lfoo.dll is specified in the Makefile...
 
 But this was true before this patch too, but with s/-lfoo\.dll/-lfoo-2/
 (which is worse since you have to keep track of the version as well).

Ah, yes, now I see.  Surely, your mechanism is a strict improvement over
that.

 This would include most of libtool's own built-in tests, I would think.

 Unless `compile'/`linker' becomes a lot smarter, and abstracts all that.
 (Actually, now that I think about this some more, modifying these
 scripts to implement search rules is probably a bad idea; they need to
 implement the SAME search rules as the underlying tool (cl.exe in this
 case), otherwise you'd get inconsistent results.  So, scratch that idea).
 
 It's probably hard to get right, yes. But I'm not scratching it without
 at least looking at it a bit more.

Well, my point is, unless EVERYTHING *always* uses the compile script --
including all autoconf (or Cmake, scons, etc etc) tests to determine
system characteristics like what library is installed where under which
name -- you will get very hard to find/fix inconsistencies in behavior.

Unless...

it doesn't matter, because the compile script and the underlying tool
(cl.exe in this case) use the same search rules.  But if they both use
the same search rules, then why bother implementing those rules in the
compile script at all?  Just pass the args on verbatim to cl.exe!)

 Besides, it's better to do this now, before the
 first release of libtool with MSVC support, than after.

 Well, that's true.  I have some misgivings about this plan, but you know
 best.
 
 I don't really like it either. Not this way and not the way it was before
 the patch, but there is no good way to do it when you have to feed the
 exact library file name to MSVC.

right.

 Hmmm, unless you put shared libs in one
 set of directories and static libs in one set and play games with the
 library search path.

As I mentioned above, that's the way VizStudio does it.

 But that seems very hard too, and on top of that it
 would be a MSVC-only solution and therefore a hard sell.

Yes, IMO this would be a large architectural change to the way libtool
operates.

 I think adding a
 matching library search to 'compile' is the best way forward (but again,
 not now).

Matching what?  If it matches cl.exe (e.g. cl -lfoo does the same thing
as compile -lfoo), in terms of locating foo.lib -- then compile won't
be able to behave differently by saying oooh, he's linking shared,
let me look for foo.dll.lib first...okay, there it is...

Suddenly, `compile's behavior doesn't match cl.exe's.

 Doing the library search with this new naming is simpler too

Re: [PATCH 0/7] Support for toolchains that are not $host-native.

2010-09-02 Thread Charles Wilson
On 9/2/2010 9:06 AM, Peter Rosin wrote:
 However, my previous suggestion with a naive_slashify instead of
 naive_backslashify doesn't work either since MSYS turns @c:/foobar into
 @c;c:\msys\1.0\foobar (or something similar, that was from memory) which
 we must avoid at all cost. cygpath -m (instead of -w) is fine on Cygwin
 though since Cygwin doesn't clobber @c:/foobar for us.
 
 Maybe we can work around this by sanitizing the input files in ar-lib,
 but that seems a bit horrible to me... I'll see if I can fix this
 somehow. Suggestions welcome.

Actually, I think MSYS's heuristic for determining whether an argument
contains a path -- and whether that path is already a dos-style one --
should be improved so that args which match the regex
'^...@[[:alpha:]]:[/\]' are understood as dos-style abspaths.

I'll look into that.

Oh, wait.

We'd also need to add exceptions for all of MSVC's command switches,
which prohibit spaces between the switch and that path: -FoC:/bob/,
-FeD:/fred, etc.  Ick.

I dunno if that's worth the effort -- or if it would even be accepted.
After all, MSYS's reason for existence is to support MinGW, not MSVC...
I could justify adding the '@' heuristic, because MinGW ar can use it,
but the rest...

What do you think, Peter?

--
Chuck



Re: [PATCH] Path conversion documentation

2010-09-02 Thread Charles Wilson
On 9/2/2010 3:05 AM, Gary V. Vaughan wrote:
 On 2 Sep 2010, at 12:40, Charles Wilson wrote:
 'Course, I notice that I screwed up the date in the ChangeLog.  Could
 the next person to commit a change to that file, please fix it?

 -2010-09-31 ...
 +2010-09-01 ...
 
 Might be unnecessary...

Well, we aren't yet using your use-gnulib branch, and right now the
ChangeLog contains an inaccurate date.  So, since I'm *sure* somebody is
going to commit something to master between now and the release...

 
 In my use-gnulib branch, I'm wondering whether to incorporate 
 gitlog-to-changelog, and have it generate the current year's ChangeLog at 
 distribution time.  However the first few months of the year don't have 
 suitable gitlog's to convert nicely.  I can think of a few options:
 
 i) wait until next year
ii) post process the output of gitlog-to-changelog for now

IF we want to use gitlog to create the ChangeLog, then either of these
is fine with me.  However, see below.

   iii) fix the gitlog entries -- if that's even viable?

I don't think (iii) will work. You can play all sorts of games with
filter-branch, but...I managed to screw up three different git clones
before I gave that up as a bad idea (I was trying to fix the author of a
commit that was not the final entry).

 Comments?

It does seem like gitlog and ChangeLog duplicate the same info, so it
would definitely be nice to reduce dvlpr workload.  However, I have
noticed that you /just can't/ do the following -- which is actually
required by the GCS:

Two people worked on a single patch, or someone submitted it, and then
one of the people with commit access modified the patch slightly.  The
GCS says you should do this, in the ChangeLog:

===
2010-09-02  John Original Submitter  ...
Steve Committer Rewrite  ...   === can't do this

* file (func): comment

Signed-off-by: Steve Committer Rewrite  ...
===

Also, for trivial commits without a copyright assignment, the GCS says
you should do this:

===
2010-09-02  Sally No Assignment  ... (tiny change)

* file (func): comment

Signed-off-by: Mark Committer ...
===

Now, MAYBE the committer can do that by munging the --author='...'; I've
never tried and I'm not sure how thoroughly git checks the --author
argument.

--
Chuck



Re: git log - changelog

2010-09-02 Thread Charles Wilson
On 9/2/2010 5:08 PM, Eric Blake wrote:
 On 09/02/2010 03:00 PM, Charles Wilson wrote:
 Two people worked on a single patch, or someone submitted it, and then
 one of the people with commit access modified the patch slightly.  The
 GCS says you should do this, in the ChangeLog:

 ===
 2010-09-02  John Original Submitter...
  Steve Committer Rewrite...=== can't do this
 
 Well, if you go by git's Signed-off-by tags as a way of generating those
 lines, it would be possible.

Ah, but then how do you distinguish between a chain of Signed-off-by
labels -- as in the Linux kernel, where various subsystem maintainers
also have to sign off on patches, in the sense of I certify that this
is OK, and it has proper approvals, and has been reviewed, (FSF: and the
author has a copyright assignment).

vs.

and I modified the actual contents of the patch a little bit

--
Chuck



Re: [PATCH 4/7] Use func_to_tool_file instead of fix_srcfile_path.

2010-09-01 Thread Charles Wilson
On 9/1/2010 5:30 PM, Ralf Wildenhues wrote:
 * Peter Rosin wrote on Wed, Sep 01, 2010 at 10:33:59PM CEST:
 * libltdl/config/ltmain.m4sh (func_mode_compile): Replace the
 fix_srcfile_path hook with a call to func_to_tool_file.
 * libltdl/m4/libtool.m4 (_LT_LINKER_SHLIBS) [cygwin,mingw,pw32]
 [cegcc]: Drop fix_srcfile_path.

 The patch series is lacking libtool.texi updates.

Well, I assume Peter will get the same leniency I did, to provide
documentation at a later date, provided later is pretty soon?

I imagine he'd want to wait until after my new docu is committed first,
so he can extend some of the new sections as appropriate.  That should
happen later today.

--
Chuck




Re: [PATCH 1/7] Add file name conversion from $build to toolchain.

2010-09-01 Thread Charles Wilson
On 9/1/2010 4:32 PM, Peter Rosin wrote:
 +AC_MSG_CHECKING([how to convert $build file names to toolchain format])
 +AC_CACHE_VAL(lt_cv_to_tool_file_cmd,
 +[#assume ordinary cross tools, or native build.
 +lt_cv_to_tool_file_cmd=func_convert_file_noop
 +case $host in
 +  *mingw* )
 +case $build in
 +  *mingw* ) # actually msys
 +lt_cv_to_tool_file_cmd=func_convert_file_msys_to_w32
 +;;
 +esac
 +;;
 +esac

Repeating Ralf's commentary to me, if you're using $host then you
should use *-*-mingw*; if you want to use mingw* in the various match
patterns then you should use $host_os.

--
Chuck





Re: [PATCH] Path conversion documentation

2010-09-01 Thread Charles Wilson
On 8/30/2010 4:20 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Mon, Aug 30, 2010 at 09:45:00PM CEST:
 Thanks for the review.
 
 My pleasure.

Pushed as attached.

'Course, I notice that I screwed up the date in the ChangeLog.  Could
the next person to commit a change to that file, please fix it?

-2010-09-31 ...
+2010-09-01 ...

--
Chuck
diff --git a/ChangeLog b/ChangeLog
index 63d4b74..44d0f47 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-31  Charles Wilson  ...
+
+	Path conversion documentation
+	* doc/libtool.texi (Platform quirks): Add new subsections
+	'Cross compiling' and 'File name conversion'.
+
 2010-09-01  Ralf Wildenhues  Ralf.Wildenhues@gmx.de
 
 	tests: avoid spurious pic_flag test failure on HP-UX 10.20.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index a3f1c59..573536e 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -223,6 +223,8 @@ Platform quirks
 * Reloadable objects::  Binding object files together.
 * Multiple dependencies::   Removing duplicate dependent libraries.
 * Archivers::   Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name conversion::Converting file names between platforms.
 
 @end detailmenu
 @end menu
@@ -5750,6 +5752,8 @@ write your own.
 * Reloadable objects::  Binding object files together.
 * Multiple dependencies::   Removing duplicate dependent libraries.
 * Archivers::   Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name conversion::Converting file names between platforms.
 @end menu
 
 @node References
@@ -5875,6 +5879,420 @@ must be used to ``bless'' the created library before linking against it,
 with the @kbd{ranlib lib@var{name}.a} command.  Some systems, like Irix,
 use the @code{ar ts} command, instead.
 
+@node Cross compiling
+@subsection Cross compiling
+@cindex cross compile
+
+Most build systems support the ability to compile libraries and applications
+on one platform for use on a different platform, provided a compiler capable
+of generating the appropriate output is available.  In such cross compiling
+scenarios, the platform on which the libraries or applications are compiled
+is called the @dfn{build platform}, while the platform on which the libraries
+or applications are intended to be used or executed is called the
+@dfn{host platform}.
+@ref{GNU Build System,, The GNU Build System, automake, The Automake Manual},
+of which libtool is a part, supports cross compiling via arguments passed to
+the configure script: @option{--build=...} and @option{--host=...}. However,
+when the build platform and host platform are very different, libtool is
+required to make certain accommodations to support these scenarios.
+
+In most cases, because the build platform and host platform differ, the
+cross-compiled libraries and executables can't be executed or tested on the
+build platform where they were compiled.  The testsuites of most build systems
+will often skip any tests that involve executing such foreign executables when
+cross-compiling.  However, if the build platform and host platform are
+sufficiently similar, it is often possible to run cross-compiled applications.
+Libtool's own testsuite often attempts to execute cross-compiled tests, but
+will mark any failures as @emph{skipped} since the failure might simply be due
+to the differences between the two platforms.
+
+In addition to cases where the host platform and build platform are extremely
+similar (e.g. @samp{i586-pc-linux-gnu} and @samp{i686-pc-linux-gnu}), there is
+another case in which cross-compiled host applications may be executed on the
+build platform.  This is possible when the build platform supports an emulation
+or API-enhanced environment for the host platform.  One example of this
+situation would be if the build platform were MinGW, and the host platform were
+Cygwin (or vice versa).  Both of these platforms can actually operate within a
+single Windows instance, so Cygwin applications can be launched from a MinGW
+context, and vice versa---provided certain care is taken.  Another example
+would be if the build platform were GNU/Linux on an x86 32bit processor, and
+the host platform were MinGW.  In this situation, the
+@uref{http://www.winehq.org/, Wine} environment can be used to launch Windows
+applications from the GNU/Linux operating system; again, provided certain care
+is taken.
+
+One particular issue occurs when a Windows platform such as MinGW, Cygwin, or
+MSYS is the host or build platform, while the other platform is a Unix-style
+system.  In these cases, there are often conflicts between the format of the
+file names and paths expected within host platform libraries and executables,
+and those employed on the build platform.
+
+This situation is best described using a concrete example: suppose the build

Re: [PATCH] Remove clcommit.m4sh.

2010-08-31 Thread Charles Wilson
On 8/31/2010 10:53 PM, Gary V. Vaughan wrote:
 Does anyone else use the commit script?
 
 * clcommit.m4sh: Removed. This script was written to help keep
 ChangeLog and commit messages in sync when committing to CVS,
 and is an anachronism now that Libtool uses git.
 
 Okay to push?
 
 ---
  ChangeLog |7 +
  clcommit.m4sh |  375 
 -
  2 files changed, 7 insertions(+), 375 deletions(-)
  delete mode 100644 clcommit.m4sh

Don't you also need to patch Makefile.maint to remove references to this
file?  (There's a comment referring to it in mailnotify.m4sh too, but
that's not important).

--
Chuck



Re: [PATCH] Path conversion documentation

2010-08-30 Thread Charles Wilson

On 8/30/2010 2:48 PM, Ralf Wildenhues wrote:

* Charles Wilson wrote on Mon, Aug 30, 2010 at 01:50:12AM CEST:

OK to push?


Looks fine to me too, only one or two issues are not markup or typo
nits (but I have been very nitpicky below).


I expected that.  This is really only a first draft with little in the 
way of editing. I'm surprised at how few nits, or even major criticisms, 
there are.



Thanks for writing this,


Sure.  Hopefully it also provides an appropriate spot (subsubsection 
under Platform quirks:Cross compiling) for a discussion of sysroot.



--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -223,6 +223,8 @@ Platform quirks
  * Reloadable objects::  Binding object files together.
  * Multiple dependencies::   Removing duplicate dependent libraries.
  * Archivers::   Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name/path conversion::   Converting filenames between platforms.


FWIW, I would  s/\/path//  but only because I find the result more
readable and as informative.


Ack. Should filenames be 'file names', as well?


@@ -5875,6 +5879,383 @@ must be used to ``bless'' the created library before 
linking against it,
  with the @kbd{ranlib l...@var{name}.a} command.  Some systems, like Irix,
  use the @code{ar ts} command, instead.

+...@node Cross compiling
+...@subsection Cross compiling
+...@cindex cross compile
+
+Most build systems support the ability to compile libraries and applications
+on one platform (the @code{$build} system) for use on a different platform (the


I don't much like variable references that include the $, because that
ties you to a particular language, whereas here, you are talking about
concepts rather than languages.  standards.texi just use 'the build
system'.  Here, since you're defining the term, you could use
@dfn{build system} or maybe @emph, and later on just use it without
markup.


Yeah, I really didn't know how to indicate that I'm talking both of a 
concept, and some variable that libtool itself is sensitive to. I tried 
@var, but that just looked wrong.  This is a good place to introduce 
terms; I'll use @dfn and reword as recommended in the texinfo docu:



Use the command only in passages whose purpose is to
introduce a term which will be used again or which the reader ought to
know.  Mere passing mention of a term for the first time does not
deserve `...@dfn'.



+...@code{$host} system) -- provided a compiler capable of generating the


Likewise for `host system', and instances below.


Ack.




+appropriate output is available.  The GNU Build System
+...@url{http://www.gnu.org/software/hello/manual/automake/GNU-Build-System.html},


@uref please, and how about putting `GNU Build System' in the second
argument of @uref, and in the first argument, replacing all single
slashes with /@/ so they are line-wrapped nicely in the PDF.

Actually, why not make this a normal inter-manual reference like
@ref{GNU Build System,, The GNU Build System, automake, The Automake
Manual}

that way it will render well in all outputs?


OK. The problem with @ref is that it *must* be followed by a . or , 
This is not a problem in this instance, but it is a problem in others.



+foriegn executables when cross-compiling.  However, if the @code{$build} and


foreign


Ack.


+operate within a single Win32 instance, so Cygwin applications can be launched


Either s/Win32/w32/  globally in your patch, or use Windows, as
recommended by the GCS.


I'll use Windows (even though it will drive RMS crazy) -- except when 
referring to the libtool function names.



+from a MinGW context, and vice versa -- provided certain care is taken. Another
+example would be if @code{$build} were linux on an @samp{x86} 32bit processor,


Either GNU/Linux, or you write out a full triple like above.


Ack.


+and @code{$host} were MinGW.  In this situation, the WINE
+...@url{http://www.winehq.org/} environment can be used to launch Win32


@uref{http://www.winehq.org/, Wine}, and s/WINE/Wine/ globally


WINE is an acronym, in classic recursive style: WINE Is Not an Emulator. 
 But, it does appear the upstream folks have stopped capitalizing it, so...


I noticed one other thing at the winehq site:


Myth 9: Wine is for Linux only
OK, as of now Wine does not run on many platforms: just Linux, MacOS
X, FreeBSD and Solaris. Still, this is not 'Linux only'.


I guess I'll need to reword a few things.


No need to double-quote Win32 here, and if there were, literal
double-quotes are almost always wrong in texinfo; that's what ``these''
are for.


Ack.


+applications from the linux operating system; again, provided certain care is


GNU/Linux


Ack.




+taken.
+
+One particular issue occurs when a Win32 platform such as MinGW, Cygwin, MSYS,
+or MSVC is the @code{$host} or @code{$build}, while the other platform is a 
unix


Unix should be capitalized here and below, and I think you mean
`Unix

[PATCH] Path conversion documentation

2010-08-29 Thread Charles Wilson
* doc/libtool.texi (Platform quirks): Add new subsections
'Cross compiling' and 'File name/path conversion'.
* libltdl/config/ltmain.m4sh (func_convert_file_check): Update
comments and warning message.
func_convert_path_check): Update warning message.
---
Documentation updates for path conversion. Plus a missed
path-file-name terminology correction.

OK to push?

--
Chuck


 doc/libtool.texi   |  381 
 libltdl/config/ltmain.m4sh |8 +-
 2 files changed, 385 insertions(+), 4 deletions(-)

diff --git a/doc/libtool.texi b/doc/libtool.texi
index a3f1c59..7c67cca 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -223,6 +223,8 @@ Platform quirks
 * Reloadable objects::  Binding object files together.
 * Multiple dependencies::   Removing duplicate dependent libraries.
 * Archivers::   Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name/path conversion::   Converting filenames between platforms.
 
 @end detailmenu
 @end menu
@@ -5750,6 +5752,8 @@ write your own.
 * Reloadable objects::  Binding object files together.
 * Multiple dependencies::   Removing duplicate dependent libraries.
 * Archivers::   Programs that create static archives.
+* Cross compiling:: Issues that arise when cross compiling.
+* File name/path conversion::   Converting filenames between platforms.
 @end menu
 
 @node References
@@ -5875,6 +5879,383 @@ must be used to ``bless'' the created library before 
linking against it,
 with the @kbd{ranlib l...@var{name}.a} command.  Some systems, like Irix,
 use the @code{ar ts} command, instead.
 
+...@node Cross compiling
+...@subsection Cross compiling
+...@cindex cross compile
+
+Most build systems support the ability to compile libraries and applications
+on one platform (the @code{$build} system) for use on a different platform (the
+...@code{$host} system) -- provided a compiler capable of generating the
+appropriate output is available.  The GNU Build System
+...@url{http://www.gnu.org/software/hello/manual/automake/GNU-Build-System.html},
+of which libtool is a part, supports cross compiling via arguments passed to
+the configure script: @option{--build=...} and @option{--host=...}. However,
+when the @code{$build} and @code{$host} systems are very different, libtool is
+required to make certain accommodations to support these scenarios.
+
+In most cases, because the @code{$build} platform and @code{$host} platform
+differ, the cross-compiled libraries and executables can't be executed or
+tested on the @code{$build} platform where they were compiled.  The testsuites
+of most build systems will often skip any tests that involve executing such
+foriegn executables when cross-compiling.  However, if the @code{$build} and
+...@code{$host} platforms are sufficiently similar, it is often possible to
+run cross-compiled applications.  Libtool's own testsuite often attempts to
+execute cross-compiled tests, but will mark any failures as @emph{skipped}
+since the failure might simply be due to the differences between the two
+platforms.
+
+In addition to cases where the @code{$host} and @code{$build} system are
+extremely similar (e.g. @samp{i586-pc-linux-gnu} and @samp{i686-pc-linux-gnu}),
+there is another case in which cross-compiled @code{$host} applications may
+be executed on the @code{$build} system.  This occurs when the @code{$build}
+platform supports an emulation or API-enhanced environment for @code{$host}.
+One example of this situation would be if @code{$build} were MinGW, and
+...@code{$host} were Cygwin (or vice versa).  Both of these platforms can 
actually
+operate within a single Win32 instance, so Cygwin applications can be launched
+from a MinGW context, and vice versa -- provided certain care is taken. Another
+example would be if @code{$build} were linux on an @samp{x86} 32bit processor,
+and @code{$host} were MinGW.  In this situation, the WINE
+...@url{http://www.winehq.org/} environment can be used to launch Win32
+applications from the linux operating system; again, provided certain care is
+taken.
+
+One particular issue occurs when a Win32 platform such as MinGW, Cygwin, MSYS,
+or MSVC is the @code{$host} or @code{$build}, while the other platform is a 
unix
+system.  In these cases, there are often conflicts between the format of the
+file names and paths expected within @code{$host} libraries and executables,
+and those employed on the @code{$build} platform.
+
+This situation is best described using a concrete example: suppose the
+...@code{$build} is linux -- (specifically, @code{i686-pc-linux-gnu}), and the
+...@code{$host} is MinGW (specifically, @code{i586-pc-mingw32}).  On the linux
+system, there exists a cross compiler, following the usual naming conventions
+of such compilers, where the compiler name is prefixed by the @code{$host}
+triple.  In this case, the C 

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-29 Thread Charles Wilson
On 8/29/2010 12:21 PM, Peter Rosin wrote:
 Den 2010-08-28 08:57 skrev Charles Wilson:
 Rename file/path conversion functions
 
 You missed one instance here. Pushed the attached as obvious...

Thanks.

--
Chuck



Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.

2010-08-28 Thread Charles Wilson
On 8/28/2010 11:31 AM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Sat, Aug 28, 2010 at 05:13:38PM CEST:
 On 8/28/2010 9:21 AM, Ralf Wildenhues wrote:
 [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
 I don't think __WINDOWS__ is the correct symbol; that is only defined by
 Watcom C/C++. I think this should be changed to _WIN32 throughout.
 
 Oops.  Like, this?

Yes, that looks fine.

 Would it be sufficient if I tested this on a GNU/Linux - MinGW cross?

Yes; the mingw (gcc) compiler defines this symbol.

--
Chuck



Re: [PATCH 3/4] Uniform const'ness of symlist variable lt_preloaded_symbols.

2010-08-28 Thread Charles Wilson
On 8/28/2010 11:43 AM, Vincent Torri wrote:
 On Sat, 28 Aug 2010, Charles Wilson wrote:
 On 8/28/2010 9:21 AM, Ralf Wildenhues wrote:
 [__WINDOWS__, __CYGWIN__, _WIN32_WCE]: Define LT_DLSYM_CONST
 I don't think __WINDOWS__ is the correct symbol; that is only defined by
 Watcom C/C++. I think this should be changed to _WIN32 throughout.
 
 _WIN32 is what is defined everywhere, indeed.

Wait, Vincent...what are you saying?  Do you mean that we don't need to
use _WIN32_WCE since (maybe?) _WIN32 is defined also on WINCE?

--
Chuck




[PATCH] [cygwin|mingw|cross-compile]: Path conversion support.

2010-08-28 Thread Charles Wilson
* configure.ac: Ensure to_host_file_cmd is available to Makefile.
* TODO: Document QoI issue with file name conversion functions.
* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New function
sets libtool variable $to_host_file_cmd, and employs cache.
(_LT_SETUP): Require it.
* tests/testsuite.at: Ensure to_host_file_cmd is passed as a
variable setting on the configure line for (new testsuite) tests.
* Makefile.am (TESTS_ENVIRONMENT): Ensure to_host_file_cmd is
included so that it is passed to (old testsuite) tests.
* libltdl/config/general.m4sh: Define $lt_sed_naive_backslashify here.
* libltdl/config/ltmain.m4sh ($to_host_file_cmd, $to_host_path_cmd):
New variables.
(func_cygpath): New function.
(func_init_to_host_path_cmd): New function.
(func_to_host_path): Renamed to...
(func_to_host_file): Refactored to... (now uses $to_host_file_cmd).
(func_convert_core_file_wine_to_w32): Here. New function.
(func_convert_core_msys_to_w32): Here. New function.
(func_convert_file_check): Here. New function.
(func_convert_file_noop): Here. New function.
(func_convert_file_msys_to_w32): Here. New function.
(func_convert_file_cygwin_to_w32): Here. New function.
(func_convert_file_nix_to_w32): Here. New function.
(func_convert_file_msys_to_cygwin): New function.
(func_convert_file_nix_to_cygwin): New function.
(func_to_host_pathlist): Renamed to...
(func_to_host_path): Refactored to... (now uses $to_host_path_cmd
and func_init_to_host_path_cmd).
(func_convert_path_check): Here. New function.
(func_convert_path_front_back_pathsep): Here. New function.
(func_convert_core_path_wine_to_w32): Here. New function.
(func_convert_path_noop): Here. New function.
(func_convert_path_msys_to_w32): Here. New function.
(func_convert_path_cygwin_to_w32): Here. New function.
(func_convert_path_nix_to_w32): Here. New function.
(func_convert_path_msys_to_cygwin): New function.
(func_convert_path_nix_to_cygwin): New function.
---
Was [cygwin|mingw] Add cross compile support to cwrapper.  This version
reflects the results of the review process, and various accommodations
to anticipate the queued MSVC patches. Renamed the commit to better
reflect its actual contents.

Validated on private master just after commit
Merge branch 'parallel-tests'
d1b98fd5399457b8d83daedb3eb4174d42480240

Results: no regressions (There was an issue with linux-cygwin, but (a)
it was my own fault for actually setting LT_CYGPATH knowing that wine +
cygwin-1.7 == boom, and (b) we'd already said we have to ignore test
results from that environment until wine+cygwin-1.7 is fixed.)
Pushed.

cygwin-native:
==
old: All 122 tests passed (2 tests were not run)
new: 111 tests behaved as expected. 6 tests were skipped.

mingw-native:
==
old: 2 of 122 tests failed (2 tests were not run)
FAIL: tests/mdemo-exec.test
FAIL: tests/mdemo2-exec.test
new: 109 tests were run, 4 failed (3 expected failures).
 8 tests were skipped.
112: Run tests with low max_cmd_len   FAILED (cmdline_wrap.at:43)

linux-native:
==
old: All 106 tests passed
new: 102 tests behaved as expected. 15 tests were skipped.

linux-mingw cross:
===
old: 2 of 100 tests failed (6 tests were not run)
FAIL: tests/demo-hardcode.test
FAIL: tests/depdemo-relink.test
new: 89 tests behaved as expected. 28 tests were skipped.

linux-cygwin cross:

old: 2 of 112 tests failed (12 tests were not run)
FAIL: tests/demo-hardcode.test
FAIL: tests/depdemo-relink.test
new: AWFUL again -- but there's an explanation
 88 tests were run, 28 failed (3 expected failures).
 29 tests were skipped.
I was using my new, sysroot-less linux-cygwin cross compiler, so
I expected good results just like the last time I used this compiler.
However, UNLIKE last time, I went ahead an set LT_CYGPATH to point to
my wine/cygwin cygpath.exe.  Well, as has been demonstrated, it coredumps
a lot -- and prints lots of gobbledygook.  The new testsuite doesn't like
gobbledygook.  LAST time, I left LT_CYGPATH unset, so libtool simply
skipped that part of the test.

I'll re-run again, without LT_CYGPATH set, just to be sure...

--
Chuck


 Makefile.am |3 +-
 TODO|   49 
 configure.ac|3 +
 libltdl/config/general.m4sh |5 +
 libltdl/config/ltmain.m4sh  |  628 ---
 libltdl/m4/libtool.m4   |   50 
 tests/testsuite.at  |5 +-
 7 files changed, 577 insertions(+), 166 deletions(-)

diff --git a/Makefile.am b/Makefile.am
index 2c4a3db..3e424be 100644
--- a/Makefile.am
+++ b/Makefile.am
@@ -528,7 +528,8 @@ TESTS_ENVIRONMENT = MAKE=$(MAKE) CC=$(CC) 
CFLAGS=$(CFLAGS) \
CXX=$(CXX) CXXFLAGS=$(CXXFLAGS) CXXCPP=$(CXXCPP) \
F77=$(F77) FFLAGS=$(FFLAGS) \
FC=$(FC) FCFLAGS=$(FCFLAGS) \
-   GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS)
+   GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS) \
+ 

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-28 Thread Charles Wilson
On 8/28/2010 2:57 AM, Charles Wilson wrote:
 Ok, I've addressed all of the review comments, including the results of
 the four ***QQQ***estions.  Quick-N-Dirty spot testing on native cygwin,
 native mingw, cygwin-mingw, linux-mingw, linux-cygwin all look good,
 so I'm about to rebase on my private branch. 

rebased, tested, merged, and pushed.  I renamed the commit to better
reflect the actual content (after 7 revisions, it shifted a bit). See

[PATCH] [cygwin|mingw|cross-compile]: Path conversion support
http://article.gmane.org/gmane.comp.gnu.libtool.patches/10408

--
Chuck



[PATCH] [cygwin] Minor sysroot fixups.

2010-08-28 Thread Charles Wilson
libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
---
Somehow this patch got dropped when the sysroot branch
was merged.  Rebased against master...

OK to push?

--
Chuck

 libltdl/m4/libtool.m4 |2 +-
 tests/sysroot.at  |2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/libltdl/m4/libtool.m4 b/libltdl/m4/libtool.m4
index a7141c5..e03543b 100644
--- a/libltdl/m4/libtool.m4
+++ b/libltdl/m4/libtool.m4
@@ -1183,7 +1183,7 @@ lt_sysroot=
 case ${with_sysroot} in #(
  yes)
if test $GCC = yes; then
- lt_sysroot=`$GCC --print-sysroot 2/dev/null`
+ lt_sysroot=`$CC --print-sysroot 2/dev/null`
fi
;; #(
  /*)
diff --git a/tests/sysroot.at b/tests/sysroot.at
index c0ac6d1..2a27134 100644
--- a/tests/sysroot.at
+++ b/tests/sysroot.at
@@ -34,7 +34,7 @@ AT_CHECK([test -n $gcc_sysroot || exit 77])
 
 # Detect installation prefix for the compiler
 prefix=
-for i in crt1.o crt2.o crti.o; do
+for i in crt0.o crt1.o crt2.o crti.o; do
   j=`$CC --print-file-name $i 2 /dev/null`
   test $? = 0 || continue
   case $j in
-- 
1.7.1




Re: [PATCH] [cygwin] Minor sysroot fixups.

2010-08-28 Thread Charles Wilson
On 8/28/2010 6:38 PM, Vincent Torri wrote:

 case ${with_sysroot} in #(
  yes)
if test $GCC = yes; then
 - lt_sysroot=`$GCC --print-sysroot 2/dev/null`
 + lt_sysroot=`$CC --print-sysroot 2/dev/null`
 
 what is the interest of testing $GCC if you use $CC ?

$GCC != gcc.  It is yes if $CC contains some variant of gcc (like
i686-pc-cygwin-gcc); no otherwise.

So, IF the user specified --with-sysroot, but did not explicitly
indicate where that sysroot is located (e.g. --with-sysroot=/some/path),
THEN

IF $CC is some variant of gcc (e.g. $GCC = yes), THEN

invoke gcc (via $CC) and ask it where the compiled-in sysroot is located.

You don't want to ask the executable yes where its sysroot is.

--
Chuck



Re: [PATCH] [cygwin] Minor sysroot fixups.

2010-08-28 Thread Charles Wilson
On 8/28/2010 8:10 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST:
 libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
 tests/sysroot.at: Search also for crt0.o to accommodate cygwin.
 ---
 Somehow this patch got dropped when the sysroot branch
 was merged.  Rebased against master...

 OK to push?
 
 Sure.  I thought this was approved before anyway.  Ideally, you'd
 commit this to the sysroot branch and merge to master (if you already
 have it on the latter then: checkout sysroot; cherry-pick master;
 checkout master; reset --hard HEAD^; merge --log sysroot).
 
 You seem to have lost a couple of leading '*' and a ChangeLog entry
 on the way though.

Yep, I know.  I always did it this way:
http://thread.gmane.org/gmane.comp.lib.gnulib.bugs/11266/focus=11268
in the past.  For me, branches were always temporary workspaces, not
something you actually *merged* somewhere...

--
Chuck



Re: [PATCH] [cygwin] Minor sysroot fixups.

2010-08-28 Thread Charles Wilson
On 8/28/2010 8:10 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Sun, Aug 29, 2010 at 12:27:15AM CEST:
 libltdl/m4/libtool.m4 (_LT_WITH_SYSROOT): Fix typo.
 tests/sysroot.at: Search also for crt0.o to accommodate cygwin.

 OK to push?
 
 Sure.

Done.

--
Chuck




Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-27 Thread Charles Wilson
On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
 --- a/Makefile.am
 +++ b/Makefile.am
 @@ -528,7 +528,8 @@ TESTS_ENVIRONMENT = MAKE=$(MAKE) CC=$(CC) 
 CFLAGS=$(CFLAGS) \
  CXX=$(CXX) CXXFLAGS=$(CXXFLAGS) CXXCPP=$(CXXCPP) \
  F77=$(F77) FFLAGS=$(FFLAGS) \
  FC=$(FC) FCFLAGS=$(FCFLAGS) \
 -GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS)
 +GCJ=$(GCJ) GCJFLAGS=$(GCJFLAGS) \
 +lt_cv_to_host_path_cmd=$(to_host_path_cmd)
 
 I don't understand why this change should be necessary.  In your
 testing, you describe that most setups set a correct to_host_path_cmd
 themselves.  For the other(s), you already describe
   export lt_cv_to_host_path_cmd=override
   ./configure ...
   make all check
 
 That should be sufficient without the above patch, no?

Well, IF you *export* that value before running configure, AND run the
tests from the same shell in which that value is exported, then sure,
that is all you need. (I think. It's been over two years since I wrote
this patch...)

However, we need to ensure that the tests work even if you run them from
a different shell that the one you configured with.  I realize we don't
tend to do this for *all* possible cache values that the end-user might
override, but this one (and the one Peter added) are special, because
the documentation is going to talk about them explicitly.  We're
actually going to *recommend* that certain classes of users override
these particular cache values.  That makes them different from all the
other lt_cv_* variables someone might override.

It's best to avoid surprises, in that case.

Anyway, I reviewed all of the past discussion, and I found where this
was introduced: it was the addendum to version 3:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html

Now, while I admitted uncertainty back then about the Makefile.am
change, I recorded no other notes about the testsuite.at changes or why
I thought they were necessary.  I do remember originally implementing it
without those two changes, and then having to add first the
Makefile.am change, and then the testsuite.at change, before I could get
things to work.  But, sadly, I no longer remember exactly WHAT the
failure mode was (maybe it had to do with the tests that re-run other
tests, like max_cmd_length?)

I'll try it without both changes (but with lt_cv_* exported in the
current shell) and see what happens.

***QQQ***
(above discussion)

 --- a/libltdl/config/ltmain.m4sh
 +++ b/libltdl/config/ltmain.m4sh
 @@ -2775,166 +2775,595 @@ fi\
  
  }
  
 +
 +# PATH CONVERSION HELPER FUNCTIONS #
 +
 
 Believe it or not, the GNU Coding Standards ask us to name things file
 name that which are files, and path those which are colon-separated
 (or $PATH_SEPARATOR-separated).  I'll close my eyes now on this issue,
 because I see hundreds of instances of it in this patch, so that'd be a
 TODO item.

It's not a difficult thing to do, and would be purely mechanical.  I can
put that on the queue for right after (or even before) the promised docu
patch.

It needs to happen before the release, because the docu will recommend
that certain users set lt_cv_to_host_path_cmd (ok,
lt_cv_to_host_file_name_cmd) to the name of one of these functions.  If
we're going to change the name of the functions, we better do it before
we document them.

 +  lt_sed_naive_backslashify='s|*|\\|g;s|/|\\|g;s|\\||g'
 
 Might want to move this variable outside to just initialize it once?
 It's global anyway.  Maybe even general.m4sh.

It would make sense in general.m4sh.  OK.

 +func_wine_to_win32_path_tmp=`winepath -w $1 2/dev/null`
 +if test $? -eq 0  test -n ${func_wine_to_win32_path_tmp}; then
 
 I'll just note that some shells ((d?)ash 0.2) fail to propagate the exit
 status of an assignment.  No need to change the code, but users should
 have a decent shell for this.

OK.  I remember one of the earlier iterations actually invoked the
winepath command twice...I don't remember why, but maybe it was related.
Most shells -- especially on x86 linux where wine would actually be
available -- are decent, tho.

 +  func_wine_to_win32_path_result=`$ECHO $func_wine_to_win32_path_tmp |
 +$SED -e $lt_sed_naive_backslashify`
 +else
 +  func_wine_to_win32_path_result=
 
 The way this is coded, correctness relies on the fact that all code
 paths that invoke this function do eventually check for non-emptiness
 of the result.

Yes. That is documented:
# ARG is the $build path to be converted to win32 format.
# result is available in $func_wine_to_win32_path_result
# result is empty on error (or when arg is empty)

 +func_wine_to_win32_pathlist_oldIFS=$IFS
 
 IFS is saved and restored always to the same value in libtool, AFAIK,
 so a short variable name should suffice completely.

Ack.

 +IFS=:
 +for func_wine_to_win32_pathlist_f in $1; do
 +  IFS=$func_wine_to_win32_pathlist_oldIFS
 +  if test -n 

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-27 Thread Charles Wilson
On 8/26/2010 5:20 PM, Charles Wilson wrote:
 On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:
 Then, please just move the new functions where Peter needs them,
 if they really need moving, that is.
 
 I deliberately placed them after func_compile and before func_link, for
 speed-of-parsing reasons. Obviously libtool is used to compile object
 code much more often than it is used to link (since every linked result
 requires one or more, sometimes many more, objects) -- so moving these
 functions ahead of func_compile will impact speed.  How much? Don't
 know; I'll try to generate some numbers.
 
 OTOH, it is absolutely *required* to move them where Peter wants them,
 since he /must/ use translate some paths if func_compile is to work,
 with MSVC.  So...we have to pay the price regardless.

I tested using 'ncurses' -- which conveniently is built using the system
installed libtool script, rather than including ltmain.sh etc in its own
configury.  The times below are for a complete 'make' (after configure
has already run) -- so it includes a lot more than just how fast does
libtool --mode=compile go.  But, the ONLY difference between the two is
the relative position of the conversion functions within the libtool
script, so any time differences should be attributable solely to that
change.

Original:
real25m3.886s
user6m24.620s
sys 11m13.787s

With the functions moved ahead of func_mode_compile:
real24m34.235s
user6m30.590s
sys 11m23.878s


Statistics:
69 executables linked
6  libraries (dlls) linked
654 objects (325 pic, 329 non-pic)

So, when compiling about 325 source code files, the new function order
cost 5 seconds of user time and 10 seconds of system time, total. That's
1/20th of a second slower per file, under:
  cygwin-1.7.6-1
  bash-3.2.51-24
On a 1.67GHz Core 2 Duo machine running Vista.

--
Chuck



Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-27 Thread Charles Wilson
On 8/27/2010 12:54 AM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Thu, Aug 26, 2010 at 11:20:48PM CEST:
 Also: I've said this before, but we can't use the m4
 function_replace magic because we need to retain the ability for
 users to override the choice of $func_to_host_path_cmd.  This is
 critical for the 'cygwin-mingw (lie)' use case, which is VERY
 common for the gcc developers.
 
 Do you need an override at 'make' time or does one at configure time
 suffice?

I'm not sure.  I thought we needed the override at make time, but this
facility is here specifically to support a use case that *I don't
use*.  I just really really really don't want to break the scheme used
by Danny and others when building gcc (even if Danny has now hung up his
gcc mingw maintainer hat).

It's possible that a configure-time-only override is sufficient.

 Because if the latter (which I'm assuming), then from my POV the above
 is just a statement that function_replace is not good enough for your
 needs, not one it cannot be done. 

Well, sure: if I thought, at the time, that configure-time-only was
sufficient, I wouldn't have said we can't.  I was assuming that we
needed make-time-override capability; IF that is true, then you really
don't want to get into the situation where, at make-time, the user sets
lt_cv_to_host_path_cmd=a_func_we_did_not_emit.

OTOH, if configure-time-only is sufficient, then you really don't need
lt_cv_to_host_path_cmd at all.  You just replace the guts of
func_to_host_path() itself.  But that's rather a big change, and I
really don't want to go there right now -- especially as I'm not sure of
the answer to the at-configure-time-only or at-make-time question.

I think that question will have to be deferred until all this stuff is
merged, with the make-time-override capability, and then we let folks
(like Danny) get used to it.  THEN we ask hey, would it be ok if you
could only modify the file/path conversion schema at configure time,
rather than at make time?

 OTOH, as a follow-on patch after 2.2.next, we could implement an
 explicit N+M scheme just so that any future extensions -- which I
 can't actually foresee -- could hook in scalably.
 
 Oh no, please not code which already sets out as dead code. 

No, it wouldn't be dead code.  Basically, you'd have

from_$build (actually, we would NOT really implement
 any of these; see below)
to_$host== what they are now

There were be TWO variables lt_cv_from_build_cmd and lt_cv_to_host_cmd,
but only one function would ever eval them:

generic_build_to_host() {
  $from_build_cmd $1
  $to_host_cmd $from_build_cmd_result
  generic_build_to_host_result=$to_host_cmd_result
}

But, at present, $from_build_cmd would *always* be assigned to
func_convert_noop.

Everywhere we currently do $to_host_cmd ..., you do
generic_build_to_host ... instead.

It's not dead code -- but it's *useless* code, right now, since with
the weird w32 platforms, you'd be calling $from_build_cmd
(func_convert_noop) uselessly.

 If there is
 a need for more translations, then maybe, but then I'd suggest there'd
 be an effort to get as many of the w32 translators under the same hood
 as possible.

I've reworded this discussion and put it into TODO, but don't plan to
address it any more than that.  Status quo for now.

--
Chuck




Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-27 Thread Charles Wilson
On 8/27/2010 2:01 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Fri, Aug 27, 2010 at 06:35:31PM CEST:
 Now, this is a little disturbing, since my -dlpreopen was supposed to
 have fixed this;
 
 Would be good to fix, yes.  On *nix, I'd be suggesting git bisect now,
 no idea if you can stand the wait on w32 though.  At least you should be
 able to speed it up significantly with something like
   make check TESTSUITEFLAGS=-V TESTS=all the mdemo ones
 
 in the bisection script, and with some luck, such a script can run
 unsupervised ...
 
 The real bug here is that the relink tests (both of them, actually)
 should be skipped when cross-compiling, because you have no business
 trying to execute the $host executable.
 
 I kind of agree.  Can we make it so that it is tested, but when the test
 programs don't behave as expected, and we cross-compile, we SKIP instead
 of FAIL?  Or is even trying to execute the broken programs a sin, in
 which case we should SKIP outright?  Thanks.

I think they should be SKIPPED always.

The test actually tries to arrange things so that the executable fails,
by hiding its dependent DLLs.  Well, on cross, we fail automatically
'cause we can't run the $host exe, so we PASS that part of the test --
but for the wrong reason.  And, because the output from the failure is
not what we expect...sometimes our failure results in a SKIP or a
FAIL.  And sometimes we ARE able to run the $host executable
(cygwin-mingw, linux-w32 with binfmt) and things just get really hairy.

It's just not reliable.  SKIP 'em.

--
Chuck



Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-27 Thread Charles Wilson
On 8/27/2010 5:48 PM, Ralf Wildenhues wrote:
 * Charles Wilson wrote on Fri, Aug 27, 2010 at 10:23:31PM CEST:
 Original:
 real25m3.886s
 user6m24.620s
 sys 11m13.787s

 With the functions moved ahead of func_mode_compile:
 real24m34.235s
 user6m30.590s
 sys 11m23.878s

 Yes, but there is a significant speedup in real time!?  That makes
 little sense, unless the system was busy doing other things also,
 for the first run.

Well, yeah -- it's windows. Who KNOWS what it is doing behind the
scenes.  Also, I was taking the time to compose all those other emails
on the same machine; I've got two cores and was only running make -j1,
but I'm not surprised there was some impact on the 'real' numbers.

But that should not have affected the user and sys numbers.

 5% sucks a bit, fixing that should be a TODO item.

It's closer to 3%:

user: 6:24 = 384; 6 seconds = 1.5%
sys:  11:13 = 673; 10 seconds = 1.5%

Not great, and it would be nice to fix -- but not terrible.  Also, I
expect the impact on REAL operating systems would be less; I seem to
recall that along with fork() performance, cygwin is really bad (slow)
at parsing shell scripts.

If we can do the magic m4 func_to_host guts-replacement, instead of
using the indirection variables, that should help.  But that is a longer
term project.

--
Chuck




Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-26 Thread Charles Wilson

On 8/26/2010 4:18 PM, Ralf Wildenhues wrote:

Then, please just move the new functions where Peter needs them,
if they really need moving, that is.


I deliberately placed them after func_compile and before func_link, for 
speed-of-parsing reasons. Obviously libtool is used to compile object 
code much more often than it is used to link (since every linked result 
requires one or more, sometimes many more, objects) -- so moving these 
functions ahead of func_compile will impact speed.  How much? Don't 
know; I'll try to generate some numbers.


OTOH, it is absolutely *required* to move them where Peter wants them, 
since he /must/ use translate some paths if func_compile is to work, 
with MSVC.  So...we have to pay the price regardless.


Also: I've said this before, but we can't use the m4 function_replace 
magic because we need to retain the ability for users to override the 
choice of $func_to_host_path_cmd.  This is critical for the 
'cygwin-mingw (lie)' use case, which is VERY common for the gcc developers.



Then, since the next few days might see a number of commits: in case
your redone patch does not apply or rebase cleanly against master any
more, you can easily leave that rebasing work to me, or better, just
apply it to the tree you tested against and let's merge that from
master (again, I can do that for you).


No worries. I have no issues with rebasing...but I don't plan on redoing 
a week's worth of test suite runs afterward.  Maybe a day's worth... :-)



* Charles Wilson wrote on Mon, Jul 19, 2010 at 03:07:01AM CEST:

* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New
function sets libtool variable $to_host_path_cmd, and employs
cache. AC_SUBSTs $to_host_path_cmd, as well.
(_LT_SETUP): Require it.
* tests/testsuite.at: Ensure to_host_path_cmd is passed as a
variable setting on the configure line for (new testsuite) tests.
* Makefile.am: Ensure to_host_path_cmd is included in
TEST_ENVIRONMENT so that it is passed to (old testsuite) tests.


Typo TESTS_ENVIRONMENT.


Ack.


* libltdl/config/ltmain.m4sh (func_cygpath): New function.
(func_init_to_host_pathlist_cmd): New function.
(func_to_host_path): Refactored to... (now uses eval
$to_host_path_cmd).
(func_wine_to_win32_path): Here. New function.
(func_msys_to_win32): Here. New function.
(func_path_convert_check): Here. New function.
(func_noop_path_convert): Here. New function.
(func_msys_to_mingw_path_convert): Here. New function.
(func_cygwin_to_mingw_path_convert): Here. New function.
(func_nix_to_mingw_path_convert): Here. New function.
(func_msys_to_cygwin_path_convert): New function.
(func_nix_to_cygwin_path_convert): New function.
(func_to_host_pathlist): Refactored to... (now uses eval
$to_host_pathlist_cmd and func_init_to_host_pathlist_cmd).
(func_pathlist_convert_check): Here. New function.
(func_pathlist_front_back_pathsep): Here. New function.
(func_wine_to_win32_pathlist): Here. New function.
(func_noop_pathlist_convert): Here. New function.
(func_msys_to_mingw_pathlist_convert): Here. New function.
(func_cygwin_to_mingw_pathlist_convert): Here. New function.
(func_nix_to_mingw_pathlist_convert): Here. New function.
(func_msys_to_cygwin_pathlist_convert): New function.
(func_nix_to_cygwin_pathlist_convert): New function.


I'm not sure I've asked before, but will state again: coding up X-to-Y
for N choices of X and M choices of Y has complexity N*M, while coding
it up as from-X and to-Y has complexity N+M.  Quadratic algorithms don't
scale.  Why is the latter not done?


I don't think it has come up explicitly, but it also occurred 
independently to me.  The main issue is you don't know what the native 
(e.g. central) path-type is; e.g. from-X (to what?) and (from 
what?) to-Y.


Right now there are only four platforms involved: *nix, mingw, msys, 
and cgywin.  That's actually the break-even point, given the vagaries 
and optimizations involved in these particular four platforms.


We have exactly five basic _convert functions (not counting the 
_pathlist_convert extensions).


For a from-X|to-Y solution, we'd need, I think, the same number of 
_convert functions: brute force suggests nine (four to_*, four from_*, 
plus the noop), but then many of the from_* and to_* would actually BE noop.


I'm assuming here that the central path-type is implicitly some sort 
of unixish -- maybe cyg, maybe msys, maybe unix -- path-type.  The issue 
is that each of the five conversion functions use a different TOOL to 
perform the conversion, with different syntax.  So, trying to combine, e.g.

   msys_to_mingw
   cygwin_to_mingw
   unix_to_mingw
into an all-encompassing central_unixish_to_mingw would require 
additional m4 magic to basically replace the guts depending on whether 
$build was msys, cygwin, or unix.  (And you can't really do a set of 
{msys|cygwin|unix}_to_central_unixish that isn't simply a no-op -- 
because (A) they already are all unixish, and (B) what tool would you 
use? How would the later to_mingw function

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-26 Thread Charles Wilson
On 8/26/2010 6:27 PM, Roumen Petrov wrote:
 Starting from wine 1.3.1 wine path always output paths:
 Lets wine is correctly configured (Z: drive is linked to the file system
 root):
 $ cd $WINEPREFIX/dosdevices
 $ winepath -w `pwd`
 Z:\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices
 
 Now lets remove link:
 $ rm z:
 $ winepath -w `pwd`
 \\?\unix\%WINEPREFIX_CONVERTED_TO_BACKSLASHES%\dosdevices
 
 So sed should remove leading //?/unix

I can't test this.  The wine-1.3.x series is the development series, and
none of the linux distributors include it in their offerings (you're
lucky to get 1.2).

For the initial submission, I'm not willing to make changes I can't
test.  After the first round is merged, feel free to propose a change
that you've tested on both wine-1.2 and wine-1.3.x.

Thanks,
Chuck



Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-24 Thread Charles Wilson

On 7/18/2010 9:07 PM, Charles Wilson wrote:
 stuff

Sorry about the date. Blame 'git format-patch'.

--
Chuck




[PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-24 Thread Charles Wilson
* libltdl/m4/libtool.m4 (_LT_PATH_CONVERSION_FUNCTIONS): New
function sets libtool variable $to_host_path_cmd, and employs
cache. AC_SUBSTs $to_host_path_cmd, as well.
(_LT_SETUP): Require it.
* tests/testsuite.at: Ensure to_host_path_cmd is passed as a
variable setting on the configure line for (new testsuite) tests.
* Makefile.am: Ensure to_host_path_cmd is included in
TEST_ENVIRONMENT so that it is passed to (old testsuite) tests.
* libltdl/config/ltmain.m4sh (func_cygpath): New function.
(func_init_to_host_pathlist_cmd): New function.
(func_to_host_path): Refactored to... (now uses eval
$to_host_path_cmd).
(func_wine_to_win32_path): Here. New function.
(func_msys_to_win32): Here. New function.
(func_path_convert_check): Here. New function.
(func_noop_path_convert): Here. New function.
(func_msys_to_mingw_path_convert): Here. New function.
(func_cygwin_to_mingw_path_convert): Here. New function.
(func_nix_to_mingw_path_convert): Here. New function.
(func_msys_to_cygwin_path_convert): New function.
(func_nix_to_cygwin_path_convert): New function.
(func_to_host_pathlist): Refactored to... (now uses eval
$to_host_pathlist_cmd and func_init_to_host_pathlist_cmd).
(func_pathlist_convert_check): Here. New function.
(func_pathlist_front_back_pathsep): Here. New function.
(func_wine_to_win32_pathlist): Here. New function.
(func_noop_pathlist_convert): Here. New function.
(func_msys_to_mingw_pathlist_convert): Here. New function.
(func_cygwin_to_mingw_pathlist_convert): Here. New function.
(func_nix_to_mingw_pathlist_convert): Here. New function.
(func_msys_to_cygwin_pathlist_convert): New function.
(func_nix_to_cygwin_pathlist_convert): New function.
---
Originally posted here:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg6.html
but much changed since then. This version actually resembles closely
version 5, below -- and the link there includes a good summary
discussion particularly intended for those who had forgotten all the
context and previous discussion concerning this patch, over the
intervening 6 months. Since it's now been 14 months later...it's still
a good review. So go read it.

See also http://www.cygwin.com/ml/cygwin/2009-02/msg00555.html
but ignore the rest of the thread; there was not a single on-topic
reply and nobody responded to my call for test. :-(


version 2:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00163.html

version 3:
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00233.html

version 3a (an overlay on version 3)
http://lists.gnu.org/archive/html/libtool-patches/2009-01/msg00238.html

More disucssion here:
http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00010.html

version 4 (squashed 3 and 3a):
http://lists.gnu.org/archive/html/libtool-patches/2009-02/msg00012.html

version 5 (ignore the bogus changelog and the first URL in this message):
http://lists.gnu.org/archive/html/libtool-patches/2009-06/msg00030.html
but the other two URLs in that message are relevant and accurate).

Interesting background discussion here:
http://cygwin.com/ml/cygwin/2009-01/msg00808.html


The original motivation was to enable correct cwrapper *execution*
when cross-compiling to a cygwin target (from linux, primarily) --
where the $build machine was (a) x86 (b) and had wine (c) and had
a cygwin installation that could be executed under wine.

However, the framework is, I think, useful for other situations --
and it is a strict improvement for unix-mingw and cygwin-mingw
cross compilation, IMO, because it (a) cleans up and refactors
the existing hodgepodge of case statements for path translation, by
(b) moving a lot of that over to libtool.m4, and (c) uses cacheable --
and thus overridable -- indirection vars to invoke the correct
refactored path translation function (this override capability is
needed for the lie to me use case; see cygwin-mingw (lie) below).

That's good, because in the interim between Jan 2009 and now, things
outside of libtool's control have changed: Running cygwin under wine
has always been...complicated, but at least in the relatively recent
past simple .exe's and especially cygpath.exe could be executed without
issue.

As of cygwin-1.7, that no longer appears to be true; I can only
occassionally get any cygwin application to execute under wine without
coredumping -- including cygpath. This might be PIBKAC, since I have
updated/reinstalled my linux OS two or three times since then; OTOH
others have reported difficulties with cygwin-1.7 on wine, too.

Fortunately, the default behavior implemented by this patch (for
*nix-cygwin cross) relies on the value of the user-set variable
LT_CYGPATH (whose value is, obviously, by default empty).  In that
case, the path-conversion logic for unix-cygwin halts after the
interim unix-dos conversion, complains about the empty LT_CYGPATH
value, and continues without error.  The result of this is simply
the status quo: the wrapper exe won't work correctly, and you won't
be able to launch 

Re: [PATCH] [cygwin|mingw]: Add cross-compile support to cwrapper (take 6)

2010-08-24 Thread Charles Wilson
On 7/18/2010 9:07 PM, Charles Wilson wrote:
 cygwin-mingw cross (faked)
 cygwin-mingw cross (lie)

to follow in a later message.

 linux-mingw cross
 ==
 linux-mingw (old tests): 2 of 100 FAIL, 6 SKIP
   FAIL: tests/demo-hardcode.test
   FAIL: tests/depdemo-relink.test
   Don't know if these are regressions or not; will recheck without
   this patch.

Not regressions; I get the same results without this patch.

 linux-cygwin cross (LT_CYGPATH not set)
 ===
 linux-cygwin (old tests): 1 of 114 FAIL, 10 SKIP
   FAIL: tests/demo-hardcode.test
   Ditto: don't know if this is a regression or not; will recheck
   without this patch.

Not a regression; same results without this patch.

 linux-cygwin (new tests): AWFUL.
  23 unexpected failures
  32 skip
 I don't expect any difference WITH LT_CYGPATH set, because
 cygpath-1.7 (and, indeed, all cygwin-1.7 programs) seems to crash under
 wine anyway. I need to investigate this and re-run in this configuration
 without this patch, to verify that these failures are not regressions.
 I don't *think* the changes in this patch could have caused them...

Also not regressions. In fact, the unmodified version is actually even
worse; it fails the following tests which the patched version does not
(the patched version skips all three):

 39: Link order of deplibs   FAILED (link-order2.at:125)
100: template test with subdirs  FAILED (template.at:243)
101: C++ static constructors FAILED (ctor.at:65)

I'm not sure what's going on here, but it obviously is not a problem
with this patch. I suspect my cygwin cross compiler may actually be
broken; it's a brand new build, and I've never done a linux-cygwin
compiler before...it's possible I messed something up:

i686-pc-cygwin-gcc can compile hello_world.c and the result works ok
when copied back to the windows machine.  However, i686-pc-cygwin-g++ is
not so lucky; hello_world.cpp's exe coredumps on win32 if used with the
cygwin-provided cygstdc++-6.dll.  When used with the cygstdc++-6.dll
built as part of the cross toolchain, it doesn't coredump -- but doesn't
print anything to stdout either.  So...I'm thinking my cygwin cross
compiler is borked.

I'll look in to the issue...but I don't think it should hold up this patch.

You might think it odd that I created this patch, originally, to assist
the linux-cygwin scenario, when I didn't actually have or use a
toolchain of that type.  Well, that's true: I tested everything involved
in the nix-cygwin path of this patch (path conversion sh functions,
etc) as much as I could in vitro, but never could test that part in
vivo. I kept hoping SOMEBODY on the cygwin list would respond to my Call
For Testing, but no such luck.  Therefore, I finally attempted to create
my own linux-cygwin toolchain, but...it's early days yet for that.

--
Chuck



Re: [PATCH v2 0/3] sysroot followup patches

2010-08-22 Thread Charles Wilson
On 8/22/2010 11:26 AM, Ralf Wildenhues wrote:
 Hello Paolo, Charles,
 
 I think these are the leftover items, right?
 
 * Paolo Bonzini wrote on Fri, Aug 13, 2010 at 03:23:02AM CEST:
 4) patch for old libtool, to not barf on '='
 6) support in libltdl for '=' in .la files
 7) doc updates.

Yes, that is the entire remaining list IIRC.

 I think the sysroot branch is in pretty good shape and all remaining
 items can be argued to not be regressions.  Thus, it might be a good
 idea to merge the branch to master now so that we can easily test it all
 together.  So, barring disagreement from any of the other maintainers
 within the next 72 hours, let's merge the current sysroot branch.

I agree.

 Of course, we should still aim to complete as much as possible before
 the release.

Of course (especially docs).

 I would like some help for 6 mostly due to lack of time on my part.
 The main design point here is how to pass the sysroot to libltdl.
 
 For me, that will definitely have to wait 'till next weekend, sorry.

Ack.

Given the tentative plan to roll out a libtool-2.2.next by the end of
this month (august) with some msvc support -- and Peter's statement
that some of his remaining msvc patches require my cross-path support
patch, I'm going to roll that out (against master, not sysroot) later
today, in preference to working on the libltdl patches.

I've tested the cross-path patch (in the past) in the following
configurations:

cygwin (native)
mingw (native; e.g. msys in its normal pretend I
   am mingw32 personality)
linux (native)
linux-mingw cross (*)

I plan to repeat ALL of those tests, plus

cygwin-mingw cross
linux-cygwin cross (*) (**)
msys-msys (native; e.g. msys in its okay, I'm actually
a cygwin-like unix environment personality)

(*) as with all cross configurations, the -exec tests are skipped as
part of the official test run. However, I'll spot check by manually
checking the contents of the c wrapper source code, and manually running
the executable from the builddir.

(**) I need to actually compile and install these tools on my linux box;
so far there are no public linux-cygwin cross tool chains available
out there for immediate use.


Anyway, this test series will take DAYS to complete...so I'd appreciate
it if the review (or, the reviewER's refresh/reread of the OLD reviews,
whose links I will post) could commence concurrent with my generation of
the test results.  I don't expect any surprise in those test results, tho...

--
Chuck



[PATCH] Fix syntax for cygwin-cross

2010-08-22 Thread Charles Wilson
libltdl/m4/argz.m4: Add quotes around variable, which
may contain the multiword value 'guessing no'.
---
argz.m4 has this interesting behavior on cygwin-cross:
[[case $host_os in #(
 *cygwin*)
   lt_cv_sys_argz_works=no
   if test $cross_compiling != no; then
 lt_cv_sys_argz_works=guessing no
   else

So, on cygwin cross the variable lt_cv_sys_argz_works has a
value that contains spaces.  Thus, without quotes around its
value, 'test' complains that there are too many arguments.

This should probably also go upstream to gnulib.

 libltdl/m4/argz.m4 |2 +-
 1 files changed, 1 insertions(+), 1 deletions(-)

diff --git a/libltdl/m4/argz.m4 b/libltdl/m4/argz.m4
index 37c1b11..d1f4ec5 100644
--- a/libltdl/m4/argz.m4
+++ b/libltdl/m4/argz.m4
@@ -66,7 +66,7 @@ AS_IF([test -z $ARGZ_H],
   ;; #(
 *) lt_cv_sys_argz_works=yes ;;
 esac]])
- AS_IF([test $lt_cv_sys_argz_works = yes],
+ AS_IF([test $lt_cv_sys_argz_works = yes],
 [AC_DEFINE([HAVE_WORKING_ARGZ], 1,
[This value is set to 1 to indicate that the system argz 
facility works])],
 [ARGZ_H=argz.h
-- 
1.7.1




Re: [PATCH] Do not absolutize paths eagerly.

2010-08-21 Thread Charles Wilson
On 8/21/2010 2:03 AM, Ralf Wildenhues wrote:
 * Ralf Wildenhues wrote on Fri, Aug 20, 2010 at 06:34:58AM CEST:
 Fixed the regression as expected, didn't show up any other failures.
 OK to apply to the sysroot branch?
 I still need somebody to test a sysroot-enabled setup with this.

Tested sysroot.at tests using cygwin-mingw sysroot-enabled cross compiler.

118: -L=.../lib -l   ok
119: -L SYSROOT/.../lib -l   ok
120: SYSROOT/.../*.laok

--
Chuck



Re: [PATCH v2 0/3] sysroot followup patches

2010-08-16 Thread Charles Wilson
On 8/12/2010 9:23 PM, Paolo Bonzini wrote:
 These cover bullets 3/5 of Charles' list:
 
 3) issue with '# Collect and forward deplibs of preopened libtool libs'
In progress? Anything?
 4,5)
* patch for old libtool, to not barf on '='
* TBD mechanism to strip '=' from .la after deployment on $host
 6) support in libltdl for '=' in .la files
 
 I didn't do 4...

Well, sure. We really need to discuss how to approach this. It's not
like we want to cut a new release of libtool-1.5; if people are going to
update their local libtool, we'd really rather they update to
libtool-2.2.latest, not a minor update to 1.5.

My impression was that Ralf was concerned about people who are using,
say, libtool-2.2.6 which is fairly new, but don't want to update to the
latest libtool for whatever reason.  Well, we're not going to release a
new libtool-2.2.6b (nor 2.2.4b, 2.2.2b, ) for all possible old
versions of libtool.

Instead, I think we should develop a simple patch that will apply
relatively cleanly to libtool-2.2.old, and just make that available on
libtool's webpage (a link to the ml archive post?) so that people who
(a) must use an older libtool, and (b) are impacted by rogue .la files
that include '=', can patch their local old libtool manually.

But I don't think we need to worry much more than that.

Also, I don't think we need try to backport the = support from
libltdl-current, once we implement it, to libltdl-old.  At that point,
it becomes a distributor question: if you ship .la files with '=', then
you're requiring that all libltdl clients that access those particular
.la files must link with libltdl-new.

 I would like some help for 6... 
 Ok to push to sysroot branch?
 
 Paolo Bonzini (4):
   fix sysroot tests to pass on Fedora 13
   fix sysroot handling for deplibs of preopened libtool libs
   reorganize parsing of --mode=finish arguments
   add libtool --mode=finish mode for sysroot

I've tested the sysroot branch, with these four patches, as well as:

[PATCH] improve code for sysroot --mode=finish
http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00143.html

[PATCH] Factor the sed command used to make a regex from a literal.
http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00144.html

and the attached correction.  I tested on:

cygwin native:
==
old: All 122 tests passed (2 tests were not run)
new: 111 tests behaved as expected.  9 tests were skipped.


linux native:
=
old: All 106 tests passed (*)
new: 102 tests behaved as expected. 18 tests were skipped.

(*) I don't have fortran installed. It's not clear why the fc and f77
tests aren't shown as 'skipped'.


mingw native (e.g. on MSYS):
==
old: 2 of 122 tests failed (2 tests were not run) (**)
new: in progress. will update later, but I don't expect any regressions.

(**) This is longstanding, and fixed by one of my unmerged patches. Not
a regression.

linux-mingw (cross compiler has sysroot):
==
tested new(118-120), the sysroot.at tests. all pass

cygwin-mingw (cross compiler has sysroot):
==
tested new(118-120), the sysroot.at tests. all pass


Here is the patch I found necessary:

2010-08-15  Charles Wilson  ...

* libltdl/config/ltmain.m4sh (func_mode_finish): Fix logic
bug in $opt_dry_run test.

So, the current status of this series (the original four patches, plus
the two corrections referenced above, plus the attached fix) is as follows:

  1/4: ok
  2/4: mental note: not covered by testsuite
  3/4: fix log entry; libltdl.m4sh around line 1397 should use
  for opt in $nonopt ${1+$@}
   instead of
  for opt in $nonopt $@
  4/4: some .texi changes:
   Ralf This is fine with me, but I think it wouldn't hurt
   Ralf if we mentioned 'sysroot' explicitly here.  You can
   Ralf of course also just do this when you add general
   Ralf description of --with-sysroot.

One those are addressed, I think this series would be ready for the
sysroot branch.  After that, all we have left are: backport patch for
old libtool+'=' in .la files (discussed above), and support in (new)
libltdl for '=' in .la files, and we'll be ready to merge to master. I
think.

--
Chuck
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 8fc7a35..06dcdf6 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -1427,7 +1427,11 @@ func_mode_finish ()
   fi
 
   # Remove sysroot references
-  if $opt_dry_run; then
+  if ${opt_dry_run-false}; then
+for lib in $libs; do
+  echo removing references to $lt_sysroot and \`=' prefixes from $lib
+done
+  else
 tmpdir=`func_mktempdir`
 for lib in $libs; do
 	  sed -e ${sysroot_cmd} s/\([ ']-[LR]\)=/\1/g; s/\([ ']\)=/\1/g $lib \
@@ -1435,10 +1439,6 @@ func_mode_finish ()
 	  mv -f $tmpdir/tmp-la $lib
 	done
 ${RM}r $tmpdir

Re: [PATCH v2 0/3] sysroot followup patches

2010-08-16 Thread Charles Wilson
:/cygwin-1.7/usr/$host/sys-root
for cygwin-mingw, etc...

 I've tested the sysroot branch, with these four patches, as well as:

 [PATCH] improve code for sysroot --mode=finish
 http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00143.html

 [PATCH] Factor the sed command used to make a regex from a literal.
 http://lists.gnu.org/archive/html/libtool-patches/2010-08/msg00144.html

 and the attached correction.  I tested on:
 
 linux native:
 =
 old: All 106 tests passed (*)
 new: 102 tests behaved as expected. 18 tests were skipped.

 (*) I don't have fortran installed. It's not clear why the fc and f77
 tests aren't shown as 'skipped'.
 
 Can you rerun only those tests with
   make check-local TESTSUITEFLAGS='-k FC -k F77 -v -d -x'

Err, sure, but the NEW testsuite did report the correct skippage:

 29: passing F77 flags through libtool skipped (flags.at:24)
 30: passing FC flags through libtool  skipped (flags.at:24)
 31: passing GCJ flags through libtool skipped (flags.at:24)
 35: F77 convenience archives  skipped (convenience.at:111)
 36: FC convenience archives   skipped (convenience.at:171)
 37: Java convenience archives skipped (convenience.at:231)
 59: F77 inferred tag  skipped (infer-tag.at:56)
 60: FC inferred tag   skipped (infer-tag.at:70)
 61: GCJ inferred tag  skipped (infer-tag.at:84)

It's just that the OLD testsuite didn't even mention the F77/FC tests:
PASS: tests/tagdemo-undef.test
PASS: tests/tagdemo-make.test
PASS: tests/tagdemo-exec.test
 I expected stuff here 

All 106 tests passed


That is, I expected:
SKIP: tests/f77demo-static.test
SKIP: tests/f77demo-make.test
SKIP: tests/f77demo-exec.test
SKIP: tests/f77demo-conf.test
SKIP: tests/f77demo-make.test
SKIP: tests/f77demo-exec.test
SKIP: tests/f77demo-shared.test
SKIP: tests/f77demo-make.test
SKIP: tests/f77demo-exec.test
SKIP: tests/fcdemo-static.test
SKIP: tests/fcdemo-make.test
SKIP: tests/fcdemo-exec.test
SKIP: tests/fcdemo-conf.test
SKIP: tests/fcdemo-make.test
SKIP: tests/fcdemo-exec.test
SKIP: tests/fcdemo-shared.test
SKIP: tests/fcdemo-make.test
SKIP: tests/fcdemo-exec.test

106 tests passed
(18 tests skipped)


I've attached what you asked for, but I don't know what it will tell you.

 and post output?
 
 Here is the patch I found necessary:

 2010-08-15  Charles Wilson  ...

  * libltdl/config/ltmain.m4sh (func_mode_finish): Fix logic
  bug in $opt_dry_run test.
 

 One those are addressed, I think this series would be ready for the
 sysroot branch.  After that, all we have left are: backport patch for
 old libtool+'=' in .la files (discussed above), and support in (new)
 libltdl for '=' in .la files, and we'll be ready to merge to master. I
 think.
 
 I agree with your description of the current state, except that I
 haven't re-read all past threads now (will do right before merge),
 and except for the issue exposed on AIX which is a real regression,
 independent of other bugs found so far, and requires fixing.

Ah, sorry. Forgot about the AIX bug.


 -  if $opt_dry_run; then
 +  if ${opt_dry_run-false}; then
 
 I don't get it.  opt_dry_run is initialized unconditionally early in the
 libtool script, from general.m4sh, and never unset.  What's the reason
 for ${...-default}?

I was just copying the pattern I saw elsewhere. If it's safe to proceed
without the default, then that's fine too.

 Other than that, the logic fix is obviously good, thanks!
 (And I overlooked that in Paolo's patch, too)
 You might want to fold this right in.

Right, as it is a fix to one of the follow-on patches TO the follow-on
series! and as such hasn't actually been published in the sysroot branch
yet...

--
Chuck
abs_srcdir=`CDPATH=${ZSH_VERSION+.}:  cd ../libtool-sysroot  pwd`; cd 
tests; \
CONFIG_SHELL=/bin/sh /bin/sh $abs_srcdir/tests/testsuite \
  MAKE=make CC=gcc CFLAGS=-g -O2 CPP=gcc -E CPPFLAGS= 
LD=/usr/bin/ld LDFLAGS= LIBS=-ldl  LN_S=ln -s NM=/usr/bin/nm -B 
RANLIB=ranlib M4SH=autom4te --language=m4sh SED=/bin/sed STRIP=strip 
lt_INSTALL=/usr/bin/install -c MANIFEST_TOOL=: OBJEXT=o EXEEXT= 
SHELL=/bin/sh CONFIG_SHELL=/bin/sh CXX=g++ CXXFLAGS=-g -O2 CXXCPP=g++ 
-E F77= FFLAGS= FC= FCFLAGS= GCJ= GCJFLAGS=-g -O2 
_lt_pkgdatadir=/home/cwilson/tmp/libtool/_build/../libtool-sysroot 
LIBTOOLIZE=/home/cwilson/tmp/libtool/_build/libtoolize 
LIBTOOL=/home/cwilson/tmp/libtool/_build/libtool 
tst_aclocaldir=/home/cwilson/tmp/libtool/_build/../libtool-sysroot/libltdl/m4 
-k FC -k F77 -v -d -x
## --- ##
## GNU Libtool 2.2.11a test suite. ##
## --- ##

Testing libtool functions.

29. flags.at:24: testing ...
++ set +x
../../libtool-sysroot/tests/flags.at:24: { test -n $F77  test X$F77 != 
Xno; } || (exit 77)
++ test -n ''
++ exit 77
29. flags.at:24:  skipped (flags.at:24)

30. flags.at:24

  1   2   3   4   5   >