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: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
On 10/25/2011 6:51 AM, Gary V. Vaughan wrote:

 Do you forsee any issues on Windows with my doing that?

Yes.

 I'm almost certain that modern gcc and hence cygwin and variants will
 continue to work correctly without LT_SCOPE, LTDL_DLL_IMPORT and friends,
 but I have no clue whether vendor compilers that currently work (or at
 least are supported and supposed to work) with the current release are
 relying on LT_SCOPE magic from libltdl.

Modern gcc will be fine on cygwin, mingw, and mingw64.  What will break
completely is any version of Visual Studio, including 2010 -- which I'm
fairly sure is not a museum piece.  It would be a shame to obviate all
of Peter's work getting libtool itself to work with MSVC, and then to
break that platform's libltdl.dll.

But I'll let Peter take point on this one.

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson
On 10/25/2011 11:03 AM, Peter Rosin wrote:
 Gary V. Vaughan skrev 2011-10-25 14:17:
 I configures both the way I usually configure libtool for msvc, i.e.
 
 ../configure autobuild_mode=msvc CC=/c/cygwin/home/peda/automake/lib/compile 
 cl CFLAGS=-MD -Zi -EHsc CXX=/c/cygwin/home/peda/automake/lib/compile cl 
 CXXFLAGS=-MD -Zi -EHsc LD=link NM=dumpbin -symbols STRIP=: 
 AR=/c/cygwin/home/peda/automake/lib/ar-lib lib RANLIB=: F77=no FC=no GCJ=no
 
 The testsuite result seems identical, with two good old failures:

Be sure and check the exports from libltdl*.dll from before and after...

--
Chuck


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Obsoleting LT_SCOPE

2011-10-25 Thread Charles Wilson

On 10/25/2011 11:51 AM, Gary V. Vaughan wrote:

I have to bow to your superior knowledge of Windows, which I haven't used
for development since Windows NT 4, but it feels weird that Libltdl really
does twist itself into a pretzel for Windows... and yet all the other GNU
projects I've looked at do no such thing (possibly because I haven't yet
found another one that can be compiled with MSVC).


Well, a couple of points: #1, libltdl is not normal: unlike most 
libraries, we provide explicit support for (a) linking externally, (b) 
incorporating as a subproject and linking locally (separate 
./configure), and (c) incorporating as a submodule(?) and linking 
locally (combined ./configure).  Very few other libraries support any 
such thing OOB.


#2, I can think of one other GNU projects that support similar 
sub-inclusion: libintl.  And /that/ library, and its cousin libiconv, 
also twist themselves into giant pretzels for Windows -- even moreso 
than libltdl.  Bruno invented a whole new method of linking! 
http://www.haible.de/bruno/woe32dll.html


BTW: one possible solution to this whole conundrum is to adopt Bruno's 
method [*], which works for both MSVC and gcc.  The idea is to *always* 
declare exported symbols as declspec(dllimport), even when linking 
against the static library.  The trick is, some additional build steps 
when building the library itself, to add the requisite import thunks 
to the static lib.  See the URL above for more info.


FWIW, Bruno has long said that this method would work better with 
just a few additional lines of code in libtool.  However, as he's 
never actually posted just WHAT those additional lines of code would BE, 
I've been at a loss to move forward.  That's been the status now for 
several years (not really high on my priority list).


[*] without the -Wl,--disable-auto-import

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


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: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-23 Thread Charles Wilson
On 6/23/2011 11:03 AM, Vadim Zeitlin wrote:
 On Thu, 23 Jun 2011 09:24:35 -0500 (CDT) Bob Friesenhahn 
 bfrie...@simple.dallas.tx.us wrote:
 
 BF On Thu, 23 Jun 2011, Vadim Zeitlin wrote:
 BF 
 BF  I.e. it created a shared library with undefined symbols without any
 BF  problems because it never actually passed -no-undefined to g++/ld.
 BF 
 BF In actual practice, it seems difficult or impossible to build programs 
 BF under systems like Linux with -no-undefined.
 
  I didn't know this but doesn't this make the situation even worse? I.e.
 because of the above you can't even recommend people to use -no-undefined
 by default. So the default behaviour will remain the current one, i.e. no
 DLLs at all under Windows.

No, what it means is that, IF the project maintainers want to support
shared libraries (DLLs) on win32, then they must do the following -- and
this is true regardless of whether libtool is involved.

1) Ensure that when building for win32, that the various object files
that will be combined into the DLL, as well as the library dependencies
(-lwhatever) are such that there WILL BE no undefined symbols, at least
*when building for win32*.  Otherwise, ld will refuse to create the DLL.

This may involve restructuring the code, and possibly changing the
division of labor between various DLLs if your project has multiple
interdependent ones.  It is *very* difficult to build stuff on win32
where you have circular dependencies between DLLs, or between DLLs and
an EXE -- not impossible, just very difficult. (*)

Now, if you are going to go thru all that trouble to support
win32...you'd just be making a lot of extra work for yourself to
maintain TWO separate library structures -- one for win32 (and, btw,
AIX) where everything is no undefined symbols clean, and one for
everything else where undefined symbols are allowed.  So...most projects
that end up in this place (**), finally decide to restructure their
shared libraries for *ALL* platforms.

Notice I haven't said anything about libtool yet.


2) Once you've gone thru the exercise in #1, now you might as well add
-no-undefined unconditionally to your libtool invocation -- if you are
using libtool, that is.  Remember, all the stuff in #1 is required just
to build DLLs on win32 *at all*, libtool or no libtool.


(*) You basically have to create an export file for DLL A (or the EXE),
and an import lib for it.  THEN, you can build DLL B as normal, and
specify -lDLLA (or -lEXE).  Finally, you build the real DLL A (or
EXE), and specify -lDLLB.  Libtool has /no/ direct mechanism to support
this.

(**) Except for those that use a plugin architecture, where the plugin
DLLs *must* be able to call back to the EXE.  That's really tricky, and
they usually end up using another solution, of which there are several
(see http://edll.sourceforge.net/ for a good description of several
different approaches).  But that's outside the scope of our discussion here.


--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-21 Thread Charles Wilson
On 6/21/2011 8:29 AM, Vadim Zeitlin wrote:
 Charles Wilson don't feed spammers writes:
 No, I think --disable-static, if specified, should actually *disable
 static*.  That should be sufficient.

 If it's not doing that, then it's a bug IMO.
 
  Just to confirm: no, currently it doesn't do this. The example of my
 original message came from libxml2 build configured with --disable-static.
 
  So should I try to create a patch making libtool fail in this case?

I think so.

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-20 Thread Charles Wilson
On 6/20/2011 3:32 AM, Marco atzeri wrote:
 Hi Chuck,
 I guess func_win32_libid() is not failing but the gcc/linker is
 smarter than libtool expect; or that autoconf is misleading libtool.

 /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.a
 /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.dll.a
 /lib/gcc/i686-pc-cygwin/4.3.4/libgfortran.la
 /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.a
 /lib/gcc/i686-pc-cygwin/4.3.4/libgfortranbegin.la
 
 libgfortran is available as dynamic and static,
 while libgfortranbegin is only static
 
 libgfortranbegin.a is included as object in the build
 of the dll/exe, while libgfortran.dll.a is used
 for the linking with cyggfortran-3.dll

Hm.  This is a big, general problem: it means you libtool can't build
ANY fortran DLLs -- because they will all need libfortranbegin.a  IIRC,
the fortran startup object used to be *an object*, so it didn't trigger
this problem.

We're really collecting more and more reasons to rewrite the support in
libtool for the gcc compiler to just use $(CC) (or $CXX, etc) to link,
and NOT muck around with detecting all these objects and compiler
runtime libs and crud -- which we currently do so that libtool can link
using $(LD) directly.

Now, even if we DID do that, it won't fix the problem below:

 Similar thing happens for the few libraries
 that are available only as static like SuiteSparse
 
 checking for ccolamd in -lccolamd
 result: yes
 
 so
 CCOLAMD_LIBS = -lccolamd
 
 But Suitesparse libs are only static:
 /usr/lib/libamd.a
 /usr/lib/libbtf.a
 /usr/lib/libcamd.a
 /usr/lib/libccolamd.a
 /usr/lib/libcholmod.a
 /usr/lib/libcolamd.a
 /usr/lib/libcsparse.a
 /usr/lib/libcxsparse.a
 /usr/lib/libklu.a
 /usr/lib/libspqr.a
 /usr/lib/libumfpack.a
 
 so they are included as objects in the dll build.

Well, in this case, libtool is doing what it is programmed to do: don't
allow DLLs to depend on static libs.  As I said earlier, this is in
general a good rule for win32.

You've found a case where this heuristic fails, and violating it does
not /appear/ to cause any problems for this particular application.

I think, in this case, overriding the autoconf variable as you are doing
is actually the right procedure!  I'm leery of making this a configure
option (--allow-static-deps) because then the uninitiated might use it
all the time...and invariably they WILL run into the problems I warned
about.


 For your notice, building octave with
 lt_cv_deplibs_check_method=pass_all
 works fine and the program pass all the tests,
 while without it the program is unusable.

But we still have the problem with fortran DLLs in general.  Sigh.

--
Chuck


___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-18 Thread Charles Wilson
On 6/17/2011 10:19 AM, Vadim Zeitlin wrote:
 On Thu, 16 Jun 2011 19:10:39 -0500 (CDT) Bob Friesenhahn 
 bfrie...@simple.dallas.tx.us wrote:
 BF Most projects using libtool come from Unix/Linux where auto-import 
 BF is the default so it can be seen that most projects already depend on 
 BF it
 
  My personal experience seems to contradict it. Maybe because auto-import
 is relatively recent

It was developed back in 2000, and all cygwin and mingw compilers since
that date have supported it, EXCEPT for the old msys gcc-2.95.1 toolkit
which was used to create *msys* executables up until 2009.

 or maybe because most originally Unix projects that
 target Windows (meaning not only Cygwin but usually MinGW as well and
 sometimes even MSVC) need to fix other Windows-specific issues anyhow and
 so do make the relatively small extra effort to add the necessary declspecs
 too. 

This.  IF -- and usually ONLY if -- the upstream maintainers have ported
to *msvc* FIRST, then they have added the declspec stuff.  Then, when it
comes to supporting mingw, they have a choice: do things the unix way
and DON'T activate the declspec stuff and use autoimport instead, OR, do
things the MSVC way.

My experience has been that this decision usually goes the win32 way,
but a significant fraction go the unix way for mingw.

The alternate path is this: the upstream maintainers port to mingw
FIRST, and fix the obvious things like using _mkdir(one arg) instead of
mkdir(two, args) -- but don't want to uglify their headers with
declspec.  THEN, they port to msvc and are forced to uglify.  At that
point, they have a new choice: do they retrofit the declspec stuff for
their existing mingw build, or not.  Most do not.

Obviously, packages developed originally on/for windows have the
declspec stuff, and usually keep it turned on for msvc and mingw.

  Anyhow, this is purely anecdotal and it's going to be hard to find an
 objective way of determining whether it's the case.

True.

  A more interesting question is if the current situation with libtool can
 be improved because I continue to believe that getting a static library
 when you're trying to build a shared one can be very unexpected. And this
 can be the case even under Unix where there would be presumably too much
 resistance to change the way --disable-static works if it is controversial
 even under Windows where I thought it would be obviously correct.
 
  So it seems the only solution with any chance of acceptance would be to
 add a different option doing what I want, e.g. --enable-shared-only. Or
 maybe allow --enable-shared=(yes|no|only)?

No, I think --disable-static, if specified, should actually *disable
static*.  That should be sufficient.

If it's not doing that, then it's a bug IMO.

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 3:46 AM, Marco atzeri wrote:
 on cygwin
 
 lt_cv_deplibs_check_method=pass_all
 
 is my workaround at configure stage to bypass incorrect
 libtool detection of system capabilities and to allow
 shared libs building.

It's not about system capabilities in this case. It's about the fact
that this -- creating a shared library by linking against existing
static libraries -- is a really bad idea.

If any of those static libs (a) exports a data item, and (b) is used by
more than one DLL in your stack, then you'll end up with two different
copies of the data item, and one DLL will use the first copy while the
other DLL will use the second copy.

Similarly, if the static lib even has a private global data item (that
is, not exposed to clients, but used in common by many of the static
lib's API functions), then you end up with the same problem.  The first
DLL will call one copy of those functions, which modify/access the first
instance of this private global data, while the second DLL will call
the second copy of those functions, which modify/access the second
instance of this private global data.

Imagine if the data item was a mutex.

IIRC elf can put these static elements in a .common section of each
.so, and the elf loader will consolidate them at runtime.  Not so with
pe/coff and the windows loader.

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: libtool shouldn't switch to creating static library if it can't create the shared one under Windows

2011-06-17 Thread Charles Wilson
On 6/17/2011 11:03 AM, Marco atzeri wrote:
 Sorry Chuck,
 but I can assure you that I am linking against shared dlls,
 but the detection is incorrect.

Well, then that's a bug. Can you give an example of a foo.a, foo.dll.a,
and foo-N.dll (plus the -lfoo incantation) you're using for which the
detection fails?

Maybe we can figure out why func_win32_libid() is failing.

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: Shared library versioning

2011-06-16 Thread Charles Wilson
On 6/16/2011 2:50 PM, Lasse Collin wrote:
 About -version-info vs. -version-number: *If* it turns out that all 
 operating systems supported by Libtool should use a versioning style 
 that is essentially the same as version_type=linux, could 
 -version-number become the recommended option to set the library 
 version?

Oh, please god, no.  On windows and cygwin, where (a) symlinks can't be
used for DLL resolution, and (b) there is no ld.conf/ld.so to manage
versions, we REALLY depend on a sane numbering system, because it gets
embedded into both the name of the DLL and its clients. (Remember:
unlike the *nix schemes, no redirecting via symbolic links is allowed)

 Major:minor:revision is easier to understand than current:revision:age, 

Major:minor:revision artificially entangles package release numbering
with API/ABI changes.  Typically when one 'goes up' so does the other,
but not always -- and not by the same increment.

And what if...your package has two different libraries, and only one of
them had an ABI change?

 which in practice is (major+minor):revision:minor. 

ONLY if you slavishly follow the one particular scheme for your package
version numbering.  I'll point out that linux itself (the kernel)
doesn't follow that scheme.  Nor does TeX.  And what if you increment
package $major because your *application* has had a major new
functionality addition, AND its command line interface has changed...but
the DLL hasn't changed at all?  Why should the DLL soname be changed
just because one of its clients has a new set of cmdline options?


Actually, that particular scheme ('bump major for ABI breaks; bump minor
for significant new features, bump micro for bugfixes') is honored more
in the breach than actually followed...Many projects appear to
(accidentally?) break library ABIs with minorver updates...and sometimes
majorver updates don't modify the ABI at all but simply represent a big
new feature addition -- or a promotion to 'stable' (**)

 Using a scheme that 
 is easier to understand would hopefully reduce mistakes in library 
 versioning.

No, it just ensures that the version numbers associated with shared
libraries will ALSO be infected with marketing-induced version inflation.

current:revision:age is VERY simple -- if you bother to read the libtool
manual (a tall order, for some project maintainers, I'll grant you).
But the key point is, *library* version numbers should be entirely
unrelated (*) to the *package* version numbers (**).

(*) except in the most vague sense of 'when ones goes up, the other one
might go up too. Maybe.'

(**) Which is why I was mildly annoyed when xz-5.0-final was published,
and included a wholly unnecessary version bump from 0:0:0 to 5:0:0.
Granted, it helped *me* out because I was already using 1:0:0 on cygwin
due to an ABI change in the prereleases.  Anyway, my annoyance was only
mild, because you had announced that soname plan LONG before the event,
so we were well prepared for it.

--
Chuck

___
https://lists.gnu.org/mailman/listinfo/libtool


Re: -no-undefined vs gcc 4.6.0

2011-03-19 Thread Charles Wilson
On 3/19/2011 6:25 AM, LRN wrote:

 I expect to find a lot of libtool-using projects that will require such
 hacks or workarounds, because `unrecognized option  '-no-undefined'' is
 very common.

Ah, but actually -no-undefined should be added by the upstream
maintainers, in Makefile.am, to libfoo_la_LDFLAGS.  It is a
*description* of the library -- which is true regardless of the host
platform the library is being built for.

It is a claim by the library designer that: This library, when linked,
will not reference any symbols, unless they are defined either in its
own source objects or in other explicitly listed dependencies

In order to build a library on win32/cygwin, libtool requires that the
library designer assure it of this fact.

So, either a library DOES or DOES NOT satisfy the claim: if it doesn't,
then it can't be built on windows without massive surgery. If it does,
then it does no harm to tell ALL platforms that it does so -- thus,
upstream should add -no-undefined to their Makefile.am/libfoo_la_LDFLAGS.

This declaration is usually NOT passed via an explicit variable
statement on the make or configure command line.

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


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: DLL creation and static libs

2010-11-02 Thread Charles Wilson
On 11/2/2010 2:14 AM, Ralf Wildenhues wrote:
 OTOH, if the w32 maintainers agree, then we can also give in and allow
 linking against static libraries plainly.  I tried the trivial patch
 (set deplibs_check_method to pass_all) a while ago but that caused a
 number of test failures, so somebody would at least have to look into
 this issue.

the problem is there are TWO different libuuid's.  There's the one that
is part of the win32 api, and simply contains a number of static objects
that represent UUIDs of elements of the Windows OS. [1] Then, there's
the unix-derived one that provides routines for *generating* new UUIDs. [2]


[1] On cygwin this is /usr/lib/w32api/libuuid.a (On mingw, it's
/usr/lib/libuuid.a).  In both cases, it IS a static library, not an
import library.

[2] On cygwin, this is /usr/lib/libuuid.[a,dll.a].  To my knowledge,
there is no corresponding element for mingw.

So...the special casing is going to be pretty complex, because you don't
want to treat cygwin's unix-derived /usr/lib/libuuid* differently than
any other library, but mingw's /usr/lib/libuuid.a and cygwin's
/usr/lib/w32api/libuuid.a would both need the special treatment.  (FYI:
we'd also need to add similar logic to binutils' ld, to special case the
auto-export).

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


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



[SCM] GNU Libtool branch, master, updated. v2.4-10-gb76bfa8

2010-10-07 Thread Charles Wilson
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  b76bfa87f56ee9491b77a10ce6fcfd3ec09bd7c8 (commit)
  from  c161010e9deec544410a3e91d105d07ed9ec9911 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit b76bfa87f56ee9491b77a10ce6fcfd3ec09bd7c8
Author: Roumen Petrov bugtr...@roumenpetrov.info
Date:   Sun Oct 3 17:15:17 2010 -0400

Add test case for 69e77671 (cwrapper PATH manipulation order)

* tests/cwrapper.at: Add new test 'cwrapper and installed shared
libraries.'

Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm

---

Summary of changes:
 ChangeLog |6 
 tests/cwrapper.at |   67 +
 2 files changed, 73 insertions(+), 0 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index c0492fe..9caba84 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-10-07  Roumen Petrov  bugtr...@roumenpetrov.info
+
+   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  p...@lysator.liu.se
 
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


hooks/post-receive
-- 
GNU Libtool



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: GNU Libtool 2.4 released [stable]

2010-10-01 Thread Charles Wilson
On 10/1/2010 4:22 PM, Alon Bar-Lev wrote:
 On Fri, Oct 1, 2010 at 3:35 PM, Charles Wilson
 please-don't-feed-the-spammers wrote:
   ^^^

 Please, over the past three months there were hundreds of messages
 discussing sysroot and how it shoold be handled.  While libtool's
 support is not yet complete, what IS there is the result of those
 discussions.  Please read them; I have a suspicion you don't quite grok
 what sysroot is really FOR, so your assumptions about how it
 should/shouldn't/does/doesn't work are somewhat flawed.
 
 You assume wrong.
 I use cross compilers as much as I use native ones.

Then why was your example, demonstrating how sysroot should work,
shown as using native tools?  I don't know of a single distributor that
enables sysroot support in their native toolchain.

And...sysroot support, per se, is still very very new even in GCC.  But,
gcc cross compilers with sysroot support is the primary milieu for which
libtool's own sysroot stuff was implemented.

 This why I waited and followed for long libtool's lacking support in
 these environments.
 I guess you know better and sure that all OK, this ends the discussion
 before it started.

No.  It's just that your statements, and your *example*, lead one to
believe that you were approaching the sysroot issue from a perspective
OTHER than the one for which libtool's implementation was designed.

IF you have an issue with that design, AND you were following for long
libtool's development of it...why didn't you chime in three months ago?

 Anyway, sysroot and cross compile sysroot can be the same, however,
 making the cross compiler sysroot dirty, may cause undesirable
 results, especially in build machines.

See, this is exactly what I'm talking about.  The whole POINT of
libtool's sysroot is so that you CAN install the built libs into the
compiler's sysroot, so that they can be automatically used there when
building OTHER libs and apps that depend on them.  It's not making it
dirty...

 Here comes the DESTDIR to the
 rescue.

And you can STILL use DESTDIR if you like.  However, if you are trying
to create *multiple* sysroots that can be used by the same compiler (at
different times, obviously)...then you can do this:

set CFLAGS+=--sysroot=/my/sysroot1

(similar for CPPFLAGS, CXXFLAGS, LDFLAGS, etc)

That way, your compiler will use the correct sysroot.  Then, you can
also ensure that *libtool* knows to turn on sysroot support for
linking .la files, by configuring whatever it is you are building with
libtool's --with-sysroot=/my/sysroot1 option.

(I'm not sure if you can get away with just --with-sysroot; it OUGHT to
work, since `$(CC) $(CFLAGS) -print-sysroot` (that is, `gcc
--sysroot=/a/b/c -print-sysroot` should return '/a/b/c', but I'm not
sure about that.)

 But you know better...

Possibly.  Possibly not.  I do know that I've been participating in this
discussion for months now, and testing multiple libtool patchsets
related to sysroot in dozens of configurations with a handful of cross
compilers on a couple of $build platforms...and you have been silent.
So I have no idea what you do or do not know.  All I can go by is what
you've said in this thread.

Which didn't start off well:
Also, why not take the value of the sysroot from the DESTDIR automake
variable?

DESTDIR != sysroot.  It is similar, but *different*, and behaves in a
different way. (And I'm talking here about how gcc/binutils use the
term; regardless of how libtool addresses the issue).  With DESTDIR, you
still have to ensure that your CFLAGS includes
-I$DESTDIR/$prefix/include and LDFLAGS includes
-L$DESTDIR/$prefix/lib.  Worse, those paths leak into your compiled
results.  With sysroot, IF it is done correctly, you shouldn't need to
specify EITHER of those things, since $sysroot/$prefix/{include,lib} is
already IN the (cross)compiler's default search path.  So, no leakage;
all you need is to tell the compiler that it ought to use $DESTDIR for
the sysroot.  (And, of course, if you use the default sysroot, you don't
need to tell it anything; it'll Just Work(tm)).


What if I wanted to build an SDK for linux-mingw, that a client
(developer) could install in THEIR compiler's (default) sysroot on
linux?  I'd need a DESTDIR in /tmp/ where I could package it up, but
underneath that DESTDIR I'd still need to see both the sysroot and the
prefix:

/tmp/my-build/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}
  ^     ^^^
   DESTDIR  sysrootprefix (on $host)

Then, I'd create my RPM/deb from /tmp/my-build, so that Sally can
install on her linux box, and it would all end up in

/usr/i686-pc-mingw32/sys-root/mingw/{include,lib,...}

just like it's supposed to.  Then, when she uses her i686-pc-mingw32-gcc
to build the bar.exe client of libfoo (for the mingw $host), the new
libs and headers will be found.  Now, the libfoo.la file in
/usr/i686-pc-mingw32/sys-root/mingw/lib
might contain

Re: GNU Libtool 2.4 released [stable]

2010-09-30 Thread Charles Wilson
On 9/30/2010 7:19 AM, Paolo Bonzini wrote:
 Note that it's perfectly possible to use .la files on the final system
 that didn't go through libtool --mode=finish, as long as all the
 packages you compile are upgraded to Libtool 2.4 (and IIUC, cygwin's
 packaging system for example is already re-libtoolizing each package, so
 it's not that hard to do this).

Except that we still haven't added '=' support to libltdl.

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


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: bogus warning 'seems to be moved'

2010-09-23 Thread Charles Wilson
Just FYI...

I don't think the following scenario applies to either of you, but I ran
into the warning in the case described below -- and the warning is valid
(e.g. we shouldn't try to fix MY case).

I was using a cross compiler with sysroot support (cygwin-mingw) to
build cygwin's setup.exe.  I was linking against some pre-built
libraries (compression, gpg) built using that cross compiler, but using
an older, pre-sysroot-support version of libtool.  (E.g. these libs are
NOT the mingw-libfoo packages currently available from cygwin.com).

Anyway, so what I had was:

/usr/i686-pc-mingw32/sys-root/mingw/lib/liblzma.la

etc, but -- because the lib was built using a non-sysroot libtool, the
.la file specifies

libdir='/mingw/lib'

NOT

libdir='=/mingw/lib'

So, when building setup.exe using a libtool that supports
--with-sysroot, it (quite rightly) complains that liblzma.la appears to
be moved -- because it (a) is NOT in /mingw/lib, and (b) doesn't have
the magic '=' sysroot marker.

This is as designed.  The fix is for me to rebuild liblzma et al using
a sysroot-capable libtool.

Just wanted to point out this scenario, which has similar symptoms as
those reported by Marco and Dave, but is NOT an error.

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: bogus warning 'seems to be moved'

2010-09-23 Thread Charles Wilson
On 9/24/2010 12:45 AM, Marco Atzeri wrote:
 I am not sure to follow your explanation.
 
 on cygwin
 
 $cd /usr/lib

I'm cross building, using $build_os=cygwin, but $host_os=mingw32, and a
cross compiler.  I am *not* building natively.

In this situation, and with the new sysroot support in libtool, .la
files will have a magic marker like this: -L=/some/path, or
libdir='=/some/path'.

The extra '=' symbol is interpreted by (new) libtool, WHEN it too is
told that sysroots are active, to mean:

pretend /some/path is prefixed by whatever the sysroot of the current
compiler is; e.g. 'i686-pc-mingw32-gcc -print-sysroot' might report:
/usr/i686-pc-mingw32/sys-root

So, if the .la file in /usr/i686-pc-mingw32/sys-root/mingw/lib/foo.la
claims that its libdir should be =/mingw/lib, libtool will magically
prepend the compiler's sysroot, and interpret the libdir specification
AS IF it said
   libdir='/usr/i686-pc-mingw32/sys-root/mingw/lib' and not
   libdir='=/mingw/lib'
Since that IS where the .la file is located, all is well and no warning
is printed.  However, WITHOUT sysroot support in libtool (or if the .la
file doesn't have the magic '=' marker) none of this occurs, and libtool
will print the warning.

But...that's what it is supposed to do in this case.

Now, I'm talking ONLY about a cross build situation.

See (latest 2.4 libtool) info.  There's a whole section about it.

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


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



Re: 2.4 Release in 24hrs

2010-09-21 Thread Charles Wilson
On 9/20/2010 1:41 PM, Ralf Wildenhues wrote:
 I'd really appreciate if you guys could send build logs to the autobuild
 server...
 Here's what I use, more or less, to create the logs:
 
   ( ../libtool/configure [OPTIONS] \
  make \
  make -k check
 cat test-suite.log tests/testsuite.log
 if tail tests/testsuite.log | grep '^| ' /dev/null; then :; else
   sed 's/^/| /' config.log
 fi
   )  logfile
 
   $sanitize logfile
   mail libtool_autobuild.josefsson.org  logfile
 
 with the underscore replaced by @.  For now, OPTIONS includes
 autobuild_mode=bla if there is anything special about the build.

See, that's what was missing.  You had asked about a month ago for me to
save all the logs from my various tests...but I had no idea what to DO
with them.  Anyway, those are all a month out of date, so I'll test the
2.4 release on those platforms and submit new reports.

We should probably create some sort of reporting script (post 2.4, of
course) and mention it (and its usage) in HACKING.  Perhaps also in the
message you get at the end of the new testsuite when there are failing
tests.  Right now that message says (for instance):

=
Please send `tests/testsuite.log' and all information you think might help:

   To: bug-libtool_gnu.org
   Subject: [GNU Libtool 2.2.11a] testsuite: 78 112 failed

You may investigate any problem if you feel able to do so, in which
case the test suite provides a good starting point.  Its output may
be found below `tests/testsuite.dir'.
=

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


Re: 2.4 Release in 24hrs

2010-09-21 Thread Charles Wilson
On 9/21/2010 9:21 PM, Gary V. Vaughan wrote:
 I don't recall having done so in a while but, according to bootstrap:
 
 # It is okay for the bootstrap process to require unreleased autoconf
 # or automake, as long as any released libtool will work with at least
 # the newest stable versions of each.  Generally, newer versions offer
 # better features, and configure.ac documents oldest version of each
 # required for bootstrap (AC_PREREQ, and AM_INIT_AUTOMAKE).
 
 And in the release template in HACKING:
 
 You will then need to have recent (possibly as yet unreleased) versions
 of Automake and Autoconf installed to bootstrap the checked out
 sources yourself.
 
 So, I will install git automake at the front of my PATH, and if the
 release process works, then I'll go ahead and use it for the release.

OK.  If it's documented, then that's fine.

 Is there a better way to save rebootstrappers from accidental
 downgrade than specifying AM_INIT_AUTOMAKE([1.11a]) in libtool's
 configure.ac?  Pity Automake doesn't use gnulibs `git-version-gen' so
 that I could specify the particular revision with the compile script
 patch that we want at libtool bootstrap time.

Well, now that I think about it, it doesn't REALLY matter (to me).  The
only case, at this time, in which you need the compile script IN libtool
to be latest-n-greatest is if you are building libtool itself using
cl.exe/MSVC.  I'm not.  So...it doesn't matter if I downgrade the
compile script by rebootstrapping with released automake.

--
Chuck


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: 2.4 Release in 24hrs

2010-09-20 Thread Charles Wilson
On 9/20/2010 11:31 AM, Bob Friesenhahn wrote:
 On Sun, 19 Sep 2010, Charles Wilson wrote:
 MinGW/MSYS:
 old -- All 122 tests passed (2 tests were not run)
 new -- 108 tests behaved as expected.  12 tests were skipped.
 
 With Charles Wilson's assistance, I updated my MinGW environment to the
 latest, but using the latest TDM GCC 4.5.1 compiler (only C  C++
 supported).
 
 These were the results:
 
 ERROR: 102 tests were run,
 6 failed (4 expected failures).
 18 tests were skipped.
 
 The test which failed (twice) was the C++ exception handling test.
 Similar tests also failed in the GraphicsMagick test suite so it seems
 that C++ exceptions are unreliable with this compiler.

This is really strange.  TDM's builds include special support
*specifically* addressing C++ exception handling when linking against
the static libstdc++ (and, IIUC, linking against the shared libstdc++
Just Works(tm) for both TDM and mingw.org compilers).

IIRC, TDM's compilers link against static libstdc++ by default, and
mingw.org's link against the shared libstdc++ by default -- but I'll
need to double check that.

Bob, if I were you I'd raise this as a bug on TDM's sf page:

http://tdm-gcc.tdragon.net/bugs
http://sourceforge.net/tracker/?group_id=200665atid=974439

because if it works with mingw.org, but fails with TDM...well, that's
a TDM bug, since John E. attempts to allow working
exceptions-across-dll-boundaries for BOTH -static-libstdc++ and
-shared-libstdc++. (Note that mingw.org's g++ WILL fail to propagate
exceptions across the DLL boundary unless -shared-libgcc, which is the
default for -shared-libstdc++, which itself is the default.  Not sure
about -static-libstdc++ with -shared-libgcc, but -static-libstdc++
-static-libgcc is right out.  However, since it *works* with mingw.org,
I don't think a screwup related to these flags is the culprit.)

 As a side note, I find that the GNU make delivered with current MinGW is
 at least 60X slower than before.  It takes GNU make 2.5 minutes before
 it does any actual work (while building GraphicsMagick), which
 represents most of the compilation time with the previous make.  A
 one-year old Cygwin make takes maybe 1.5 seconds to start working when
 given the same environment.

And for this, I'd appreciate it if you could open a bug at mingw.org's
tracker:
http://sourceforge.net/tracker/?group_id=2435atid=102435

--
Chuck


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
On 9/19/2010 11:45 AM, Bob Friesenhahn wrote:
 Unfortunately, my MinGW testing is not so successful.  The testing still
 quits part-way through with some sort of make-related issue (as reported
 in detail previously).

Odd.  My last test on MinGW was very successful. This was version 1.3266
(ef56e98f3 IIRC).  I'll give it another go @ f0584085.

--
Chuck


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
On 9/19/2010 3:27 PM, Bob Friesenhahn wrote:
 The 'make' used is GNU make 3.79.1.

Yikes.  Where did THAT come from?  MSYS has provided at least make-3.81
for several years; the current msys make is 3.82.

 There is a 'mingw32-make' which is
 GNU make 3.82, but does not seem to work under MSYS.

Right.  mingw32-make is for when you do NOT have msys installed, and
just want to use a makefile with MinGW gcc.  Obviously, without msys,
you can't run configure scripts, or generate Makefile's from
Makefile.in's, etc -- or use libtool.  Just as obviously, when building
libtool itself, you darned well better have msys installed, so
mingw32-make is not appropriate.  Besides, mingw32-make doesn't grok
msys-style pathnames.

I sounds like your msys installation is WAY out of date.  What I would
suggest is the following:

1) download and install mingw-get (get the .zip file, and unpack it
somewhere innocuous like C:\Temp\MinGW-Installer -- NOT C:\MinGW,
because we don't want to disturb your existing TDM mingw compiler.

You do not want to use easier mingw-get-inst wrapper, because it will
automatically also install mingw.org's gcc, and you're using TDM.  You
*could* use mingw-get-inst, but (a) you'd have to pick a different
installation directory, and (b) by default, your new msys would be in
C:\mingw-inst-dir\msys\1.0, NOT C:\msys\1.0.


2) edit C:\Temp\MinGW-Installer\var\lib\mingw-get\data\profile.xml (if
it doesn't exist, copy default.xml).  You should change the following
two lines:

sysroot subsystem=mingw32 path=%R /
sysroot subsystem=MSYS path=%R/msys/1.0 /

To this:

sysroot subsystem=mingw32 path=%R /
sysroot subsystem=MSYS path=C:/msys/1.0 /

The default configuration will install a new MinGW into whereever
mingw-get is, and a new MSYS into whereever mingw-get-is/msys/1.0.
You don't want that...so you have to edit the defaults.

You might want to move your existing msys installation out of the way.

Then, from a cmd prompt, cd to C:\Temp\MinGW-Installer\bin and do this:

mingw-get update
mingw-get install mingw-dtk

The first command updates all of the locally cached package manifests to
the latest version.  The second command downloads and installs a
selection to tools that will closely mimic the old MSYS-DTK package --
into C:\msys\1.0\*.  However, as mingw-dtk (and the old MSYS-DTK)
collection includes mingw-ish autoconf/automake/libtool, THOSE tools
will get installed into wherever-mingw-get-is/*.

It's up to you whether you should brute force copy these files over onto
your existing TDM C:\MinGW  or not (but do NOT put them into
C:\msys\1.0!!!)  Alternatively, of course, you could edit the mingw32
subsystem path specification in profile.xml, and install THOSE
components directly into C:\MinGW.

After that, you need to edit C:\msys\1.0\etc\fstab to add
   C:\MinGW /mingw
as usual...but that's old hat.

--
Chuck


___
http://lists.gnu.org/mailman/listinfo/libtool


Re: 2.4 Release in 24hrs

2010-09-19 Thread Charles Wilson
On 9/19/2010 12:57 PM, Charles Wilson wrote:
 On 9/19/2010 11:45 AM, Bob Friesenhahn wrote:
 Unfortunately, my MinGW testing is not so successful.  The testing still
 quits part-way through with some sort of make-related issue (as reported
 in detail previously).
 
 Odd.  My last test on MinGW was very successful. This was version 1.3266
 (ef56e98f3 IIRC).  I'll give it another go @ f0584085.

MinGW/MSYS:
old -- All 122 tests passed (2 tests were not run)
new -- 108 tests behaved as expected.  12 tests were skipped.

MinGW.org gcc 4.5.0
MinGW.org binutils 2.20.51.20100613
MSYS 1.0.15(0.47/3/2) 2010-07-06 22:04 i686 Msys
make-3.81-3 (not 3.82! I should probably update...)
msys-bash-3.1.17-3
msys-coreutils-5.97-3
msys-m4-1.4.14-1
mingw-runtime-3.18 (/mingw/include/_mingw.h)
w32api-3.14(/mingw/include/w32api.h)

--
Chuck

___
http://lists.gnu.org/mailman/listinfo/libtool


[SCM] GNU Libtool branch, master, updated. v2.2.10-186-g301c4cf

2010-09-17 Thread Charles Wilson
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  301c4cf24f5ddaa565ffb773906247deb1319aa2 (commit)
  from  254f5280e6cb6f69b17b581e0febbb73cd02b606 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 301c4cf24f5ddaa565ffb773906247deb1319aa2
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date:   Fri Sep 17 12:28:46 2010 -0400

Document libtool variable to_host_file_cmd.

* doc/libtool.texi (libtool script contents:to_host_file_cmd): Document
variable.
(libtool script contents:to_tool_file_cmd): Prefer `build platform'
to `build system'; Ditto `host platform'.

Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm

---

Summary of changes:
 ChangeLog|8 
 doc/libtool.texi |   14 --
 2 files changed, 20 insertions(+), 2 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 44a76e2..334a5d0 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,11 @@
+2010-09-17  Charles Wilson  libt...@cwilson.fastmail.fm
+
+   Document libtool variable to_host_file_cmd.
+   * doc/libtool.texi (libtool script contents:to_host_file_cmd):
+   Document variable.
+   (libtool script contents:to_tool_file_cmd): Prefer `build platform'
+   to `build system'; Ditto `host platform'.
+
 2010-09-16  Charles Wilson  libt...@cwilson.fastmail.fm
 
Fix sh.test failure introduced in 72064249
diff --git a/doc/libtool.texi b/doc/libtool.texi
index a3555dc..0d3ff7f 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -6822,11 +6822,21 @@ Linker flag (passed through the C compiler) used to 
generate thread-safe
 libraries.
 @end defvar
 
+...@defvar to_host_file_cmd
+If the toolchain is not native to the build platform (e.g.@: if you are using
+MSYS to drive the scripting, but are using the MinGW native Windows compiler)
+this variable describes how to convert file names from the format used by the
+build platform to the format used by host platform.  Normally set to
+...@samp{func_convert_file_noop}, libtool will autodetect most cases in which
+other values should be used.  On rare occasions, it may be necessary to 
override
+the autodetected value (@pxref{Cygwin to MinGW Cross}).
+...@end defvar
+
 @defvar to_tool_file_cmd
-If the toolchain is not native to the build system (e.g.@: if you are using
+If the toolchain is not native to the build platform (e.g.@: if you are using
 some Unix to drive the scripting together with a Windows toolchain running
 in Wine) this variable describes how to convert file names from the format
-used by the build system to the format used by the toolchain.  Normally set
+used by the build platform to the format used by the toolchain.  Normally set
 to @samp{func_convert_file_noop}.
 @end defvar
 


hooks/post-receive
-- 
GNU Libtool



[SCM] GNU Libtool branch, master, updated. v2.2.10-187-g69e7767

2010-09-17 Thread Charles Wilson
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  69e77671311ab54de44ba24ff5dbf5568bf1221d (commit)
  from  301c4cf24f5ddaa565ffb773906247deb1319aa2 (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 69e77671311ab54de44ba24ff5dbf5568bf1221d
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date:   Fri Sep 17 12:23:28 2010 -0400

Fix order of PATH manipulation in cwrapper and shwrapper

* 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

Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm

---

Summary of changes:
 ChangeLog  |   11 +++
 libltdl/config/ltmain.m4sh |   26 +-
 2 files changed, 28 insertions(+), 9 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 334a5d0..17e50cf 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,5 +1,16 @@
 2010-09-17  Charles Wilson  libt...@cwilson.fastmail.fm
 
+   Fix order of PATH manipulation in cwrapper and shwrapper
+   * 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
+
+2010-09-17  Charles Wilson  libt...@cwilson.fastmail.fm
+
Document libtool variable to_host_file_cmd.
* doc/libtool.texi (libtool script contents:to_host_file_cmd):
Document variable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 7bbca85..4f5bbb3 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3293,6 +3293,18 @@ func_exec_program ()
 
   if test -f \\$progdir/\$program\; then
 
+   # fixup the dll searchpath if we need to.
+   #
+   # 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.
+   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 +3319,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 +3707,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);
+  /* 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. */
   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));


hooks/post-receive
-- 
GNU Libtool



[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



[SCM] GNU Libtool branch, master, updated. v2.2.10-185-g254f528

2010-09-16 Thread Charles Wilson
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  254f5280e6cb6f69b17b581e0febbb73cd02b606 (commit)
  from  3d4f9e324590737af07de73ce4d4eefea85fb16e (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit 254f5280e6cb6f69b17b581e0febbb73cd02b606
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date:   Thu Sep 16 22:53:47 2010 -0400

Fix sh.test failure introduced in 72064249

* libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor syntax.

Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm

---

Summary of changes:
 ChangeLog  |6 ++
 libltdl/config/ltmain.m4sh |2 +-
 2 files changed, 7 insertions(+), 1 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index 37f6c84..44a76e2 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-16  Charles Wilson  libt...@cwilson.fastmail.fm
+
+   Fix sh.test failure introduced in 72064249
+   * libltdl/config/ltmain.m4sh (func_mode_link): Avoid poor
+   syntax.
+
 2010-09-16  Ralf Wildenhues  ralf.wildenh...@gmx.de
 
tests: avoid localization failure due to unstable compiler messages.
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


hooks/post-receive
-- 
GNU Libtool



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



[SCM] GNU Libtool branch, master, updated. v2.2.10-175-gef56e98

2010-09-12 Thread Charles Wilson
This is an automated email from the git hooks/post-receive script. It was
generated because a ref change was pushed to the repository containing
the project GNU Libtool.

The branch, master has been updated
   via  ef56e98f3bb4ed780a08bced638f8adf673c0041 (commit)
  from  048979e10ffcbe67dad11e3b58365ecc66232e5a (commit)

Those revisions listed above that are new to this repository have
not appeared on any other notification email; so we list those
revisions in full, below.

- Log -
commit ef56e98f3bb4ed780a08bced638f8adf673c0041
Author: Charles Wilson libt...@cwilson.fastmail.fm
Date:   Sun Sep 12 09:19:51 2010 -0400

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.

Signed-off-by: Charles Wilson libt...@cwilson.fastmail.fm

---

Summary of changes:
 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  libt...@cwilson.fastmail.fm
+
+   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  ralf.wildenh...@gmx.de
 
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


hooks/post-receive
-- 
GNU Libtool



[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

  1   2   3   4   5   6   >