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

2010-10-20 Thread Cesar Strauss

On 10/20/2010 02:53 PM, Peter Rosin wrote:

Den 2010-10-20 17:55 skrev 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=detail&aid=3081421&group_id=2435&atid=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?


Yes, I think that was a coincidence.



Not really.

I follow this particular list, and noticed Peter's ping for his MSYS 
patch over here.


Regards,
Cesar




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

2010-10-20 Thread Peter Rosin
Den 2010-10-20 18:53 skrev Peter Rosin:
> Den 2010-10-20 17:55 skrev Charles Wilson:
>> 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}

Forgot to say that I think that this needs to be something like

start %WD%error_mode -cgf %WD%rxvt {other args}

since error_mode must be a MinGW app, and thus does not understand
MSYS paths.

Cheers,
Peter



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

2010-10-20 Thread Peter Rosin
Den 2010-10-20 17:55 skrev 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=detail&aid=3081421&group_id=2435&atid=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?

Yes, I think that was a 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.

Yes, that was high priority.

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

The other ways to activate that I can think of is via some environment
variable, but checking that for every new process is going to add on
to the already painful fork cost. Either that or using some interface
like cygwin_internal to manipulate "myself->children_error_mode", but
that would require adding a shopt to bash that sets the desired error
mode and that it should be inherited by future children. And what about
other shells?

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

Yes, integration in msys.bat would be nice.  But this is a corner case,
and if you create a shortcut (which I have done), it really doesn't
matter how you spell it.  But as I said, it still would be nice.

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

I assume you mean the closed mingw-dvlpr list? In that case, I can't
join the fun, since I'm not a member...

(This is getting off topic)

Cheers,
Peter



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=detail&aid=3081421&group_id=2435&atid=302435
> 
> The silence is deafening. 
> 
> Chuck, have you looked at this?

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

wait...

Looks like Cesar responded earlier today.  Coincidence?

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

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

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

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

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

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

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

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

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

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

--
Chuck



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

2010-10-20 Thread Peter Rosin
Hi Gary,

Den 2010-10-20 08:55 skrev Gary V. Vaughan:
> On 20 Oct 2010, at 13:31, Peter Rosin wrote:
>> Den 2010-10-05 13:33 skrev Peter Rosin:
>>> Den 2010-09-30 09:44 skrev Peter Rosin:
 Maybe the shopt isn't needed after all.  If the SetErrorMode call checks
 if the SEM_FAILCRITICALERRORS is already set, that could be used to
 determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in
 spawn_guts.  Then you could start an MSYS process with a custom error
 mode, and the error mode would be inherited.  Hopefully anyway, I might
 easily have missed something...
>>>
>>> I have implemented exactly that and just posted this to the MinGW patch
>>> tracker:
>>> http://sourceforge.net/tracker/index.php?func=detail&aid=3081421&group_id=2435&atid=302435
>>
>> The silence is deafening.  I wonder if I should have been more explicit
>> about the implications of this patch?  Let me spell it out, I can run
>> the libtool testsuite on MSYS without having to dismiss a single
>> dialog, independent of which compiler I'm using.  All tests are non-
>> interactive if you patch and start MSYS as described in the above
>> tracker.  If you want the dialogs, then simply start MSYS as you have
>> always done and it will behave as it has always done.  I find the patch
>> really nice!
> 
> If you are confident the patch is good, and doesn't need peer review,
> you can commit under the 72 hour rule as long as no-one has asked for
> more time to review or expressed doubts about applying it.
> 
> If you're not confident about the patch, and would rather get a peer
> review before committing, then keep pinging like this until someone
> takes a look.
> 
> I am following the lists, but I'm short on time, and don't have (or
> want) access to any windows machines to determine whether this works
> as advertised.  Briefly following your link, this looks like a mingw
> patch anyway... there is no error-mode.c file in libtool; did you
> post the wrong link?

No, everything is as intended.  Well, apart from the fact that I made
you waste time on this.  I should have been more explicit about this
being a patch for another project, with the only relevance for libtool
being that it helps the libtool testsuite when it runs on MSYS.  It is
indeed a patch for MSYS (shipped by the MinGW crew) and not for libtool.
But I thought at least Chuck would have something to say since he
maintains libtool for the MinGW project and I imagine that he does a fair
bit of libtool hacking on MSYS, at least from time to time, where this
patch would be welcome.

Cheers,
Peter



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

2010-10-20 Thread Gary V. Vaughan
Hi Peter,

On 20 Oct 2010, at 13:31, Peter Rosin wrote:
> Den 2010-10-05 13:33 skrev Peter Rosin:
>> Den 2010-09-30 09:44 skrev Peter Rosin:
>>> Maybe the shopt isn't needed after all.  If the SetErrorMode call checks
>>> if the SEM_FAILCRITICALERRORS is already set, that could be used to
>>> determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in
>>> spawn_guts.  Then you could start an MSYS process with a custom error
>>> mode, and the error mode would be inherited.  Hopefully anyway, I might
>>> easily have missed something...
>> 
>> I have implemented exactly that and just posted this to the MinGW patch
>> tracker:
>> http://sourceforge.net/tracker/index.php?func=detail&aid=3081421&group_id=2435&atid=302435
> 
> The silence is deafening.  I wonder if I should have been more explicit
> about the implications of this patch?  Let me spell it out, I can run
> the libtool testsuite on MSYS without having to dismiss a single
> dialog, independent of which compiler I'm using.  All tests are non-
> interactive if you patch and start MSYS as described in the above
> tracker.  If you want the dialogs, then simply start MSYS as you have
> always done and it will behave as it has always done.  I find the patch
> really nice!

If you are confident the patch is good, and doesn't need peer review,
you can commit under the 72 hour rule as long as no-one has asked for
more time to review or expressed doubts about applying it.

If you're not confident about the patch, and would rather get a peer
review before committing, then keep pinging like this until someone
takes a look.

I am following the lists, but I'm short on time, and don't have (or
want) access to any windows machines to determine whether this works
as advertised.  Briefly following your link, this looks like a mingw
patch anyway... there is no error-mode.c file in libtool; did you
post the wrong link?

Cheers,
-- 
Gary V. Vaughan (g...@gnu.org)

PGP.sig
Description: This is a digitally signed message part


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

2010-10-19 Thread Peter Rosin
Den 2010-10-05 13:33 skrev Peter Rosin:
> Den 2010-09-30 09:44 skrev Peter Rosin:
>> Maybe the shopt isn't needed after all.  If the SetErrorMode call checks
>> if the SEM_FAILCRITICALERRORS is already set, that could be used to
>> determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in
>> spawn_guts.  Then you could start an MSYS process with a custom error
>> mode, and the error mode would be inherited.  Hopefully anyway, I might
>> easily have missed something...
> 
> I have implemented exactly that and just posted this to the MinGW patch
> tracker:
> http://sourceforge.net/tracker/index.php?func=detail&aid=3081421&group_id=2435&atid=302435

The silence is deafening.  I wonder if I should have been more explicit
about the implications of this patch?  Let me spell it out, I can run
the libtool testsuite on MSYS without having to dismiss a single
dialog, independent of which compiler I'm using.  All tests are non-
interactive if you patch and start MSYS as described in the above
tracker.  If you want the dialogs, then simply start MSYS as you have
always done and it will behave as it has always done.  I find the patch
really nice!

Chuck, have you looked at this?

Cheers,
Peter



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

2010-10-05 Thread Peter Rosin
Den 2010-09-30 09:44 skrev Peter Rosin:
> Maybe the shopt isn't needed after all.  If the SetErrorMode call checks
> if the SEM_FAILCRITICALERRORS is already set, that could be used to
> determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in
> spawn_guts.  Then you could start an MSYS process with a custom error
> mode, and the error mode would be inherited.  Hopefully anyway, I might
> easily have missed something...

I have implemented exactly that and just posted this to the MinGW patch
tracker:
http://sourceforge.net/tracker/index.php?func=detail&aid=3081421&group_id=2435&atid=302435

Cheers,
Peter



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

2010-10-01 Thread Ralf Wildenhues
Hi Peter,

* Peter Rosin wrote on Wed, Sep 29, 2010 at 11:21:11PM CEST:
> Den 2010-09-29 21:01 skrev Ralf Wildenhues:
> > * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST:
> >> Ok to push this one?
> > 
> > I don't mind it, but I'll note that the patch will cause testsuite
> > failures when no wrapper is actually used.  This can happen
> > 
> > - with --disable-shared passed toplevel, or on static-only systems,
> > - on systems where a wrapper is not needed even in shared mode
> > 
> > At least for lalib-syntax it will thus cause failure for the wrong
> > reason (the current XFAIL hides that I guess).
> 
> I think you are wrong here.

Well, all the better then, both because that means the situation is
better than feared, and because you're not letting yourself get
distracted.

> lalib-syntax only looks at the 1st argument so the fact that I
> have added a 2nd argument should not matter in practice.  We don't
> call it without arguments so its "argc < 2" check is just cosmetics.
> 
> > For demo-relink that is irrelevant, as demo/main.c ignores its
> > arguments, tests/depdemo/main.c however also uses them.
> 
> The only prior argument to depdemo/main.c that I could find was -alt,
> which is explicitly tested for in main(), so if an extra --lt- option
> "bleeds in", it should be ignored and not cause any harm.  I might
> have missed something though.
> 
> So, I actually don't think the patch will affect the testsuite results.

OK good.

> > Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with
> > check-(non)interactive?
> 
> --lt-no-interactive is fine by me, but why not --lt-non-interactive?

Hmm.  Was thinking about how GCC does options, I guess, with -ffoo
mapped to -fno-foo.  no-interactive sounds weirder when spoken out,
though.

> I'll think some more about the general issue.  What I really would
> like is a bash shopt to set the error mode from the shell when
> running testsuites.  Then we could really forget this issue.  Either
> that or some way to make MSYS not force the "default" error mode so
> hard.  I have tried to start MSYS with an inherited error mode, but
> I couldn't make it stick.  I guess I need to start digging in the
> sources of those projects, and see if I can see what would be the
> best/easiest solution.

That would indeed be cool.  IIUC your followup post shows this isn't so
easy though.  So feel free to go ahead with the change.

Thanks,
Ralf



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

2010-09-30 Thread Peter Rosin
Den 2010-09-29 23:21 skrev Peter Rosin:
> I'll think some more about the general issue.  What I really would
> like is a bash shopt to set the error mode from the shell when
> running testsuites.  Then we could really forget this issue.  Either
> that or some way to make MSYS not force the "default" error mode so
> hard.  I have tried to start MSYS with an inherited error mode, but
> I couldn't make it stick.  I guess I need to start digging in the
> sources of those projects, and see if I can see what would be the
> best/easiest solution.

Ok, since I find this:

  int flags = CREATE_DEFAULT_ERROR_MODE | GetPriorityClass (hMainProc);

in spawn_guts, line 616 in (1), introducing a shopt in bash is with all
likelihood going to be futile.

I wonder if that CREATE_DEFAULT_ERROR_MODE can be made optional
somehow, or even removed?  I don't really see what good it's doing.
Sure, it makes it certain how things are going to behave when you are
not relying on inheriting the error mode, but it's rather inflexible.

*thinks*

Maybe MSYS processes set the error mode on init, and this flag is set
here so that you do get the popup instead of just a "silent" exit status
when you are running a program that e.g. is missing a dll?

*digging some more*

Yes, that appears to be the case, since I find this:

  (void) SetErrorMode (SEM_FAILCRITICALERRORS);

in dll_crt0_1, line 670 in (2).

So, it is not acceptable to simply remove CREATE_DEFAULT_ERROR_MODE above.
Which means that *both* a shopt in the shell and some support for it in
MSYS is going to be needed.  Good luck with that, because I'm not going to
try anytime soon.

*thinks again*

Maybe the shopt isn't needed after all.  If the SetErrorMode call checks
if the SEM_FAILCRITICALERRORS is already set, that could be used to
determine if the CREATE_DEFAULT_ERROR_MODE flag should be added in
spawn_guts.  Then you could start an MSYS process with a custom error
mode, and the error mode would be inherited.  Hopefully anyway, I might
easily have missed something...

Cheers,
Peter

(1) 
http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/spawn.cc?revision=1.29&view=markup
(2) 
http://mingw.cvs.sourceforge.net/viewvc/mingw/msys/rt/src/winsup/cygwin/dcrt0.cc?revision=1.11&view=markup



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

2010-09-29 Thread Peter Rosin
Hi Ralf,

Den 2010-09-29 21:01 skrev Ralf Wildenhues:
> * Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST:
>> Ok to push this one?
> 
> I don't mind it, but I'll note that the patch will cause testsuite
> failures when no wrapper is actually used.  This can happen
> 
> - with --disable-shared passed toplevel, or on static-only systems,
> - on systems where a wrapper is not needed even in shared mode
> 
> At least for lalib-syntax it will thus cause failure for the wrong
> reason (the current XFAIL hides that I guess).

I think you are wrong here.

lalib-syntax only looks at the 1st argument so the fact that I
have added a 2nd argument should not matter in practice.  We don't
call it without arguments so its "argc < 2" check is just cosmetics.

> For demo-relink that is irrelevant, as demo/main.c ignores its
> arguments, tests/depdemo/main.c however also uses them.

The only prior argument to depdemo/main.c that I could find was -alt,
which is explicitly tested for in main(), so if an extra --lt- option
"bleeds in", it should be ignored and not cause any harm.  I might
have missed something though.

So, I actually don't think the patch will affect the testsuite results.

> (This need for internal knowledge about when wrappers are used, is why
> I disliked the arguments to them; or am I misremembering and we have
> changed the wrappers to be used in more cases for some reason?)

Agreed, it is hard(ish) to determine if it is safe to add the --lt-
argument and if unrelated changes are needed it is easy to regress.

> Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with
> check-(non)interactive?

--lt-no-interactive is fine by me, but why not --lt-non-interactive?

I'll think some more about the general issue.  What I really would
like is a bash shopt to set the error mode from the shell when
running testsuites.  Then we could really forget this issue.  Either
that or some way to make MSYS not force the "default" error mode so
hard.  I have tried to start MSYS with an inherited error mode, but
I couldn't make it stick.  I guess I need to start digging in the
sources of those projects, and see if I can see what would be the
best/easiest solution.

Cheers,
Peter



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

2010-09-29 Thread Ralf Wildenhues
Hi Peter,

* Peter Rosin wrote on Wed, Sep 29, 2010 at 10:06:00AM CEST:
> Ok to push this one?

I don't mind it, but I'll note that the patch will cause testsuite
failures when no wrapper is actually used.  This can happen

- with --disable-shared passed toplevel, or on static-only systems,
- on systems where a wrapper is not needed even in shared mode

At least for lalib-syntax it will thus cause failure for the wrong
reason (the current XFAIL hides that I guess).

For demo-relink that is irrelevant, as demo/main.c ignores its
arguments, tests/depdemo/main.c however also uses them.

(This need for internal knowledge about when wrappers are used, is why
I disliked the arguments to them; or am I misremembering and we have
changed the wrappers to be used in more cases for some reason?)

Hmm, --lt-no-interactive instead of --lt-no-popup, for consistency with
check-(non)interactive?

Thanks,
Ralf

> Subject: [PATCH] tests: make more tests non-interactive on MSYS.
> 
> * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src):
> Recognize --lt-no-popup and set the w32 error mode so that
> Windows do not popup dialogs if the option is seen.
> * libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize
> --lt-no-popup and strip it out (with no side effect, there is
> no API for adjusting the w32 error mode from within a shell).
> * tests/demo-relink.test, tests/depdemo-relink.test: Use the
> above option to make the test non-interactive on MSYS.
> tests/lalib-syntax.at: Use the above option to make the test
> non-interactive on MSYS/MSVC (the MSVC version of assert/abort
> pops up an error dialog).
> * docs/libtool.texi (Wrapper executables): Document the new
> option of the wrapper.



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

2010-09-29 Thread Peter Rosin
Den 2010-09-29 17:00 skrev 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

Yes, that's a complete drag.

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

Well, there are pages like this:
http://www.sybase.be/detail?id=47705

Anyway, SetErrorMode is win9x-safe.

Cheers,
Peter



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: don't use assert/abort on MSVC as they are interactive.

2010-09-29 Thread Peter Rosin
Den 2010-09-29 15:47 skrev 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?

I don't foresee any problems, because SetErrorMode is really old.  You
were worrying about the entry point not being there, right?

Cheers,
Peter



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 Peter Rosin
Den 2010-09-28 22:09 skrev Ralf Wildenhues:
> Hello Peter,
> 
> * Peter Rosin wrote on Tue, Sep 28, 2010 at 08:08:13PM CEST:
>> Ok to push?
> 
> Avoiding assert doesn't seem like a scalable solution: lots of packages
> use assert for testing.  assert is ANSI C.  We use assert in slist.at.
> Is there a way to avoid popups?
> 
> Hmm, or, if there is no way, then I guess you're saying popups are ok if
> it only happens for unexpected failures.  Then I don't have a good
> argument against the patch any more.

I started out by setting the w32 error mode directly in the executable in
the test, and that revealed that I was wrong in what error mode flag
this was connected to (I thought SEM_FAILCRITICALERRORS, but it really is
SEM_NOGPFAULTERRORBOX).  That revelation made me reimplement an idea I
had a while back that I didn't get to work because of that misconception.

So, here's a patch with a different take on the problem that makes the old
testsuite non-interactive on MSYS, and that fixes this non-interactiveness
too. The two remaining interactive tests (link-order2.at and static.at)
unfortunately runs installed binaries so this scheme is not working there.

I didn't want to unconditionally fiddle the error mode when running through
the wrapper, as that would royally screw users depending on the error
dialog to be there.

Cygwin is always running with this error mode (I think), MSYS is not.

Ok to push this one?

Cheers,
Peter

>From fa648e86ec81defc48e035ca952635e2dc42cc51 Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Wed, 29 Sep 2010 09:59:18 +0200
Subject: [PATCH] tests: make more tests non-interactive on MSYS.

* libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src):
Recognize --lt-no-popup and set the w32 error mode so that
Windows do not popup dialogs if the option is seen.
* libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize
--lt-no-popup and strip it out (with no side effect, there is
no API for adjusting the w32 error mode from within a shell).
* tests/demo-relink.test, tests/depdemo-relink.test: Use the
above option to make the test non-interactive on MSYS.
tests/lalib-syntax.at: Use the above option to make the test
non-interactive on MSYS/MSVC (the MSVC version of assert/abort
pops up an error dialog).
* docs/libtool.texi (Wrapper executables): Document the new
option of the wrapper.

Signed-off-by: Peter Rosin 
---
 ChangeLog  |   17 +
 doc/libtool.texi   |7 +++
 libltdl/config/ltmain.m4sh |   16 ++--
 tests/demo-relink.test |2 +-
 tests/depdemo-relink.test  |2 +-
 tests/lalib-syntax.at  |2 +-
 6 files changed, 41 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a7aa489..3967d0a 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,20 @@
+2010-09-29  Peter Rosin  
+
+   tests: make more tests non-interactive on MSYS.
+   * libltdl/config/ltmain.m4sh (func_emit_cwrapperexe_src):
+   Recognize --lt-no-popup and set the w32 error mode so that
+   Windows do not popup dialogs if the option is seen.
+   * libltdl/config/ltmain.m4sh (func_parse_lt_options): Recognize
+   --lt-no-popup and strip it out (with no side effect, there is
+   no API for adjusting the w32 error mode from within a shell).
+   * tests/demo-relink.test, tests/depdemo-relink.test: Use the
+   above option to make the test non-interactive on MSYS.
+   tests/lalib-syntax.at: Use the above option to make the test
+   non-interactive on MSYS/MSVC (the MSVC version of assert/abort
+   pops up an error dialog).
+   * docs/libtool.texi (Wrapper executables): Document the new
+   option of the wrapper.
+
 2010-09-27  Peter Rosin  
 
tests: check if sys_lib_search_path_spec works on MSVC.
diff --git a/doc/libtool.texi b/doc/libtool.texi
index cd5a181..a9f6c5a 100644
--- a/doc/libtool.texi
+++ b/doc/libtool.texi
@@ -904,6 +904,13 @@ These command line options include:
 Causes the wrapper to print a copy of the wrapper @emph{script}
 to @code{stdout}, and exit.
 
+...@item --lt-no-popup
+This option makes the wrapper attempt to set things up so that the
+program does not issue any error dialogs, and instead report errors with
+an exit status as is the normal way.  This is particularly useful in
+testsuites on w32, as w32 has a tendency to pop up error dialogs for
+certain errors potentially making the testsuite non-interactive.
+
 @item --lt-debug
 Causes the wrapper to print diagnostic information to @code{stdout},
 before launching the program executable.
diff --git a/libltdl/config/ltmain.m4sh b/libltdl/config/ltmain.m4sh
index 0418007..cacf68f 100644
--- a/libltdl/config/ltmain.m4sh
+++ b/libltdl/config/ltmain.m4sh
@@ -3111,8 +3111,8 @@ _LTECHO_EOF'
 # (application programs are unlikely to have options which match
 # this pattern).
 #
-# There are only two supported options: --lt-debug and
-# --lt-dump-script. There is, deliberately, no --lt-help.
+# There are onl

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

2010-09-28 Thread Ralf Wildenhues
Hello Peter,

* Peter Rosin wrote on Tue, Sep 28, 2010 at 08:08:13PM CEST:
> Ok to push?

Avoiding assert doesn't seem like a scalable solution: lots of packages
use assert for testing.  assert is ANSI C.  We use assert in slist.at.
Is there a way to avoid popups?

Hmm, or, if there is no way, then I guess you're saying popups are ok if
it only happens for unexpected failures.  Then I don't have a good
argument against the patch any more.

Thanks,
Ralf

> From f17e568aea90ea2def14d0d0825da927b4a2421d Mon Sep 17 00:00:00 2001
> From: Peter Rosin 
> Date: Tue, 28 Sep 2010 20:02:22 +0200
> Subject: [PATCH] tests: don't use assert/abort on MSVC as they are 
> interactive.
> 
> * tests/lalib-syntax.at (main.c): Rewrite to not use assert as
> assert in turn calls abort which pops up a dialog on MSVC.



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

2010-09-28 Thread Peter Rosin
Hi!

Ok to push?

Cheers,
Peter

>From f17e568aea90ea2def14d0d0825da927b4a2421d Mon Sep 17 00:00:00 2001
From: Peter Rosin 
Date: Tue, 28 Sep 2010 20:02:22 +0200
Subject: [PATCH] tests: don't use assert/abort on MSVC as they are interactive.

* tests/lalib-syntax.at (main.c): Rewrite to not use assert as
assert in turn calls abort which pops up a dialog on MSVC.

Signed-off-by: Peter Rosin 
---
 ChangeLog |6 ++
 tests/lalib-syntax.at |   16 +++-
 2 files changed, 17 insertions(+), 5 deletions(-)

diff --git a/ChangeLog b/ChangeLog
index a7aa489..ce0c144 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2010-09-28  Peter Rosin  
+
+   tests: don't use assert/abort on MSVC as they are interactive.
+   * tests/lalib-syntax.at (main.c): Rewrite to not use assert as
+   assert in turn calls abort which pops up a dialog on MSVC.
+
 2010-09-27  Peter Rosin  
 
tests: check if sys_lib_search_path_spec works on MSVC.
diff --git a/tests/lalib-syntax.at b/tests/lalib-syntax.at
index 0f78ca8..45fc2d6 100644
--- a/tests/lalib-syntax.at
+++ b/tests/lalib-syntax.at
@@ -30,7 +30,6 @@ AT_XFAIL_IF([:]) dnl libltdl does not consistently return 
non-NULL lt_dlerror
 AT_DATA([main.c],
 [[#include 
 #include 
-#include 
 
 int
 main (int argc, char* argv[])
@@ -54,9 +53,16 @@ main (int argc, char* argv[])
   else
 {
   const char *error = lt_dlerror ();
-  assert (error != NULL);
-  printf ("plugin failed to open: %s\n", error);
-  err = 1;
+  if (NULL != error)
+   {
+ printf ("plugin failed to open: %s\n", error);
+ err = 1;
+   }
+  else
+   {
+ printf ("plugin failed to open\n");
+ err = 3;
+   }
 }
   lt_dlexit ();
   return err;
@@ -131,7 +137,7 @@ libdir='/somewhere'
 for file in ./missing-closing-quote.la ./wrong-quotes.la \
./no-dlname.la ./nonexistent-dlname.la; do
   LT_AT_EXEC_CHECK([./main], [1], [stdout], [ignore], [$file])
-  AT_CHECK([grep 'plugin failed to open' stdout], [], [ignore])
+  AT_CHECK([grep 'plugin failed to open:' stdout], [], [ignore])
 done
 
 AT_CLEANUP
-- 
1.7.1