RE: Perl Win32::Shortcut screws up fork

RE: Perl Win32::Shortcut screws up fork

[Adye, TJ (Tim)]

Answering my own question

> cygiconv-2.dll is used by bash, but rebaseall is a bash script.
> What can I do?

I found I could do this by saving the rebase command-line and file list
that rebaseall generates and then running the rebase command directly
from the DOS prompt. Now Perl's Win32::Shortcut and fork work together!
Thanks for the hint.

Nevertheless, there does seem to be a problem with the rebaseall.

Tim.

> -----Original Message-----
> From: Adye, TJ (Tim) 
> Sent: 07 July 2005 19:55
> To: 'Cygwin List'
> Subject: RE: Perl Win32::Shortcut screws up fork
> 
> Hi Larry,
> 
> Sorry, I assumed that the rebasing problem was ancient 
> history, since I hadn't encountered it for so long (and 
> remembered a long-ago comment about rebaseall being a 
> stop-gap measure). Thanks for putting me right.
> 
> Unfortunately I can't get rebaseall to work... running from a 
> bash prompt in a DOS box (as the docs tell me to), I get
> 
> % ps -a
>       PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>      1668       1    1668       1668    0 22534 19:36:55 /usr/bin/bash
>      1268    1668    1268       1800    0 22534 19:45:04 /usr/bin/ps
> % rebaseall
> ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6
> 
> cygiconv-2.dll is used by bash, but rebaseall is a bash 
> script. What can I do?
> 
> Thanks,
> Tim.
> 
> > -----Original Message-----
> > From: Larry Hall
> > Sent: 07 July 2005 19:09
> > To: Adye, TJ (Tim); cygwin@cygwin.com
> > Subject: Re: Perl Win32::Shortcut screws up fork
> > 
> > At 01:10 PM 7/7/2005, you wrote:
> > >In an attempt to work round the problem with readshortcut 
> I reported
> > >earlier, I thought I'd use a Perl script. Unfortunately the
> > >Win32::Shortcut package seems to cause problems with 
> process forking
> > >(unlike the readshortcut error, this one isn't specific to 
> the latest
> > >cygwin DLL). I get an error
> > >
> > >C:\cygwin\bin\perl.exe (3088): *** unable to remap
> > >C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcu
> > t\Shortcut.
> > >dll to same address as parent(0xBF0000) != 0x1110000
> > >     13 [main] perl 3716 fork_parent: child 3088 died 
> waiting for dll
> > >loading 
> > 
> > 
> > Sounds like a classic rebasing issue to me.  Have you tried running 
> > 'rebaseall'?
> > 
> > 
> > 
> > 
> > --
> > Larry Hall                              http://www.rfk.com
> > RFK Partners, Inc.                      (508) 893-9779 - RFK Office
> > 838 Washington Street                   (508) 893-9889 - FAX
> > Holliston, MA 01746                     
> > 
> > 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Perl Win32::Shortcut screws up fork

[Reini Urban]

Adye, TJ (Tim) sagte:
> Answering my own question
>> cygiconv-2.dll is used by bash, but rebaseall is a bash script.
>> What can I do?
>
> I found I could do this by saving the rebase command-line and file list
> that rebaseall generates and then running the rebase command directly
> from the DOS prompt. Now Perl's Win32::Shortcut and fork work together!
> Thanks for the hint.

BTW: Since I'm the libwin32 maintainer I want to add that this my package
is one of the rare packages with a gbs script actually having a rebase
step,
so that the required rebaseall is a rare condition.

But with the latest updates (perl, bash, cygwin, gcc, ...) libwin32
certainly needs an update to the actual 0.24 version; sorry, without any
cygwin visible fixes, yet.
perl-5.8.7 is much better though.
I hope to make a perl-libwin32-0.24 during the weekend.
The new Win32::GUI is top priority, which will be released today or
tommorrow.
Maybe a cygwin Win32::API with callbacks will also be available soon.

> Nevertheless, there does seem to be a problem with the rebaseall.


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Mon, Jul 11, 2005 at 08:43:07AM -0400, Jason Tishler wrote:
>On Thu, Jul 07, 2005 at 11:50:38PM -0400, Christopher Faylor wrote:
>> On Thu, Jul 07, 2005 at 08:24:20PM -0600, Eric Blake wrote:
>> >But what was wrong with my idea of making rebaseall a #!/bin/ash
>> >script?
>> 
>> You still couldn't run the script from bash since the dlls would still
>> be loaded.  That would mean that you'd have to do something like:
>> 
>> c:\>ash rebaseall
>> 
>> (Currently rebaseall won't work as an ash script but the fix is
>> trivial)
>> 
>> I guess that's better than nothing but I still think that just not
>> rebasing the bash dlls is going to result in fewer mailing list
>> complaints.
>
>My inclination is to convert rebaseall to an ash script.

Once again, let me point out -- that will not solve the problem.  You won't
be able to run the script from bash, for obvious reasons.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Jason Tishler]

On Thu, Jul 07, 2005 at 11:50:38PM -0400, Christopher Faylor wrote:
> On Thu, Jul 07, 2005 at 08:24:20PM -0600, Eric Blake wrote:
> >But what was wrong with my idea of making rebaseall a #!/bin/ash
> >script?
> 
> You still couldn't run the script from bash since the dlls would still
> be loaded.  That would mean that you'd have to do something like:
> 
> c:\>ash rebaseall
> 
> (Currently rebaseall won't work as an ash script but the fix is
> trivial)
> 
> I guess that's better than nothing but I still think that just not
> rebasing the bash dlls is going to result in fewer mailing list
> complaints.

My inclination is to convert rebaseall to an ash script.

> OTOH, if we had some coordination between the maintainers of DLLs in
> the distribution we could reduce the need for rebase a lot.  I don't
> know if using --enable-auto-image-base would fix every problem but I
> suspect that it might help.

It will, but I have empirical evidence that DLLs need to be rebased with
some padding between them to guarantee that fork() does not fail.

Jason

-- 
PGP/GPG Key: http://www.tishler.net/jason/pubkey.asc or key servers
Fingerprint: 7A73 1405 7F2B E669 C19D  8784 1AFD E4CC ECF4 8EF6

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Gerrit P. Haase]

Christopher Faylor wrote:

>>But what was wrong with my idea of making rebaseall a #!/bin/ash script?
> 
> 
> You still couldn't run the script from bash since the dlls would still
> be loaded.  That would mean that you'd have to do something like:
> 
> c:\>ash rebaseall
> 
> (Currently rebaseall won't work as an ash script but the fix is trivial)
> 
> I guess that's better than nothing but I still think that just not
> rebasing the bash dlls is going to result in fewer mailing list
> complaints.
> 
> OTOH, if we had some coordination between the maintainers of DLLs in
> the distribution we could reduce the need for rebase a lot.  I don't
> know if using --enable-auto-image-base would fix every problem but
> I suspect that it might help.


I suggest another simple solution.  Teach rebase to read an INI file if
called without options, this INI includes all options needed for
rebaseall and then after closing all Cygwin processes a simple double
click on rebase from explorer (or calling from a .bat file) would be
sufficient to start it.


Gerrit

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 08:24:20PM -0600, Eric Blake wrote:
>According to Christopher Faylor on 7/7/2005 8:05 PM:
>>>Option B would be to write a C or C++ program to do the job of what
>>>rebaseall currently does.  That's even more work.
>> 
>> I was going to suggest that but it requires that the user had loaded
>> the C compiler which seems like overkill for this.
>
>I think the intent of this suggestion was to replace rebaseall (the shell
>script) with rebaseall.exe (the static executable), not to have rebaseall
>output C source code, compile it, then run it.
>
>But what was wrong with my idea of making rebaseall a #!/bin/ash script?

You still couldn't run the script from bash since the dlls would still
be loaded.  That would mean that you'd have to do something like:

c:\>ash rebaseall

(Currently rebaseall won't work as an ash script but the fix is trivial)

I guess that's better than nothing but I still think that just not
rebasing the bash dlls is going to result in fewer mailing list
complaints.

OTOH, if we had some coordination between the maintainers of DLLs in
the distribution we could reduce the need for rebase a lot.  I don't
know if using --enable-auto-image-base would fix every problem but
I suspect that it might help.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 10:21:29PM -0400, Igor Pechtchanski wrote:
>On Thu, 7 Jul 2005, Christopher Faylor wrote:
>
>> On Thu, Jul 07, 2005 at 06:41:31PM -0700, Brian Dessent wrote:
>>
>> >Option B would be to write a C or C++ program to do the job of what
>> >rebaseall currently does.  That's even more work.
>>
>> I was going to suggest that but it requires that the user had loaded
>> the C compiler which seems like overkill for this.
>
>I think (hope) Brian meant a C/C++ program to replace the rebaseall bash
>script, not that rebaseall produced a C program that would need to be
>compiled and run... :-)

Right.  Duh.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Eric Blake wrote:

> Except that even the /bin/sh postinstalls often did mv, cp, or some other
> action involving one of the coreutils.  It's hard to do much of anything
> without using the coreutils, which have depended on iconv and intl since
> their 5.2.1 days.

You're right.  As I said, I hadn't actually thought through this
scenario very well.  :-)

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 7/7/2005 8:21 PM:
>>coreutils already requires libintl and libiconv since 5.2.1 days, so most
>>useful actions in a postinstall script have already depended on having
>>libraries available as part of Base.  Based on several months of no
>>complaints, I think we can discount the theoretical problems of this scenario.
> 
> Postinstall scripts almost universally have /bin/sh in the shebang, and
> so were using ash regardless of which bash was installed.  The recent
> replacement of /bin/sh with bash means that prior to now we had no
> experience in this area.

Except that even the /bin/sh postinstalls often did mv, cp, or some other
action involving one of the coreutils.  It's hard to do much of anything
without using the coreutils, which have depended on iconv and intl since
their 5.2.1 days.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzecl84KuGfSFAYARAkVEAJwJohzcIOEcEVJ1cPuKwSG1pHXD7wCeJl5C
0K/KUiYy6gOyqsjlNPg78GI=
=RSRh
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Eric Blake wrote:

> Or, you could make rebaseall a #!/bin/ash script, which would require that
> we never kill ash from the distribution, while freeing you from bash's
> dynamic linking.

Ah, hadn't thought of that.  This seems like the best short-term
solution, since it involves minimal changes.  The only potential problem
is that it requires that the user upgrade their 'ash' package, but they
would have to also presumably upgrade their 'rebase' package too
anyway.  I don't think anyone here wants to try to support people that
refuse to upgrade certain packages to 'Curr', so it's not a big deal.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Eric Blake wrote:

> coreutils already requires libintl and libiconv since 5.2.1 days, so most
> useful actions in a postinstall script have already depended on having
> libraries available as part of Base.  Based on several months of no
> complaints, I think we can discount the theoretical problems of this scenario.

Postinstall scripts almost universally have /bin/sh in the shebang, and
so were using ash regardless of which bash was installed.  The recent
replacement of /bin/sh with bash means that prior to now we had no
experience in this area.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Christopher Faylor on 7/7/2005 8:05 PM:
>>Option B would be to write a C or C++ program to do the job of what
>>rebaseall currently does.  That's even more work.
> 
> I was going to suggest that but it requires that the user had loaded
> the C compiler which seems like overkill for this.

I think the intent of this suggestion was to replace rebaseall (the shell
script) with rebaseall.exe (the static executable), not to have rebaseall
output C source code, compile it, then run it.

But what was wrong with my idea of making rebaseall a #!/bin/ash script?

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzePU84KuGfSFAYARAtBVAKDHj6dMOmdifA3uILtO/XhOMVJ6YACfXP6V
nSEuITr77f5r2+Buu2MMGxI=
=3t+9
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Igor Pechtchanski]

On Thu, 7 Jul 2005, Christopher Faylor wrote:

> On Thu, Jul 07, 2005 at 06:41:31PM -0700, Brian Dessent wrote:
>
> >Option B would be to write a C or C++ program to do the job of what
> >rebaseall currently does.  That's even more work.
>
> I was going to suggest that but it requires that the user had loaded
> the C compiler which seems like overkill for this.

I think (hope) Brian meant a C/C++ program to replace the rebaseall bash
script, not that rebaseall produced a C program that would need to be
compiled and run... :-)
	Igor
-- 
				http://cs.nyu.edu/~pechtcha/
      |\      _,,,---,,_		pechtcha@cs.nyu.edu
ZZZzz /,`.-'`'    -.  ;-;;,_		igor@watson.ibm.com
     |,4-  ) )-,_. ,\ (  `'-'		Igor Pechtchanski, Ph.D.
    '---''(_/--'  `-'\_) fL	a.k.a JaguaR-R-R-r-r-r-.-.-.  Meow!

"The Sun will pass between the Earth and the Moon tonight for a total
Lunar eclipse..." -- WCBS Radio Newsbrief, Oct 27 2004, 12:01 pm EDT

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 06:41:31PM -0700, Brian Dessent wrote:
>Christopher Faylor wrote:
>>>I think we will require a statically linked bash, or some kind of
>>>trickery in the rebaseall script.  One potential way around this might
>>>be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
>>>$COMSPEC to run the commands.  This would have the advantage of not
>>>requiring any Cygwin DLLs in use during the rebase, but it sounds more
>>>error prone and complicated.
>>
>>But, the alternative of creating a version of bash just so that people
>>can run rebaseall sounds even more error prone.
>>
>>I don't see any other foolproof way of doing this.
>>
>>Btw, don't '.bat' files work on NT, too?
>
>By 'error prone' I meant that the current rebaseall script knows to stop
>the process when the first error happens.  A .bat file would just try to
>plow through without checking, though you could certainly write more
>logic to check the errorlevel.  But you would have to limit yourself to
>the command.com level of functionality, which is pretty prehistoric
>IIRC.

I was thinking that rebaseall would just create a simple .bat file which
would be run when no other cygwin process was running.  The only thing I
see in rebaseall that wouldn't be doable in a .bat file is the
cleanup-on-error part.  The only thing you couldn't do then is
cleanup-on-error.

If rebaseall wanted to be really clever, it could detect dlls that are
currently loaded into memory, copy them to another temporary name,
rebase those dlls, and then set things up so that the correct dlls are
copied on reboot.  Or a program or .bat file could be run at the user's
discretion to rename the dlls to the correct name.  This would be run
when all cygwin processes had exited.

Or, perhaps we should make sure that the dlls used by bash are already
nicely based and tell rebase to 1) make sure that no other dlls are
rebased into their load address and 2) ignore the dlls.  That's probably
the ultimate solution.

>Option B would be to write a C or C++ program to do the job of what
>rebaseall currently does.  That's even more work.

I was going to suggest that but it requires that the user had loaded
the C compiler which seems like overkill for this.

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 7/7/2005 7:41 PM:
> 
> Option B would be to write a C or C++ program to do the job of what
> rebaseall currently does.  That's even more work.

True - there are many actions where scripts are just more convenient than
full-blown programs, even though it introduces a dependency on the shell
running the script.

> 
> When I mentioned a static bash I was thinking of just making the base
> package statically compiled, not having an alternative.  Somehow I
> imagined that this would make it a little faster too, but that's
> probably going to be insignificant.
> 
> I'm also wondering if the issue would ever come up in postinstall
> scripts.  Where before with ash or bash 2.x, we only required a working
> Cygwin DLL, now any postinstall script has to also have these 4 core
> DLLs in addition to the Cygwin DLL in place for any postinstall to
> function.  I haven't really though this through though, as to whether
> this scenario matters.

coreutils already requires libintl and libiconv since 5.2.1 days, so most
useful actions in a postinstall script have already depended on having
libraries available as part of Base.  Based on several months of no
complaints, I think we can discount the theoretical problems of this scenario.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD8DBQFCzd7c84KuGfSFAYARArF0AJ4vwRWQaQ81V3CJXULqyhEknMd5hQCg2OiV
DLMDtNFn4FGM6Qe19fmb1XQ=
=YTpA
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Brian Dessent]

Christopher Faylor wrote:

> >I think we will require a statically linked bash, or some kind of
> >trickery in the rebaseall script.  One potential way around this might
> >be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
> >$COMSPEC to run the commands.  This would have the advantage of not
> >requiring any Cygwin DLLs in use during the rebase, but it sounds more
> >error prone and complicated.
> 
> But, the alternative of creating a version of bash just so that people
> can run rebaseall sounds even more error prone.
> 
> I don't see any other foolproof way of doing this.
> 
> Btw, don't '.bat' files work on NT, too?

By 'error prone' I meant that the current rebaseall script knows to stop
the process when the first error happens.  A .bat file would just try to
plow through without checking, though you could certainly write more
logic to check the errorlevel.  But you would have to limit yourself to
the command.com level of functionality, which is pretty prehistoric
IIRC.

Option B would be to write a C or C++ program to do the job of what
rebaseall currently does.  That's even more work.

When I mentioned a static bash I was thinking of just making the base
package statically compiled, not having an alternative.  Somehow I
imagined that this would make it a little faster too, but that's
probably going to be insignificant.

I'm also wondering if the issue would ever come up in postinstall
scripts.  Where before with ash or bash 2.x, we only required a working
Cygwin DLL, now any postinstall script has to also have these 4 core
DLLs in addition to the Cygwin DLL in place for any postinstall to
function.  I haven't really though this through though, as to whether
this scenario matters.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Eric Blake]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

According to Brian Dessent on 7/7/2005 7:15 PM:
> This is a problem with the new bash version 3.0, which is dynamically
> linked to the readline, libiconv, and ncurses DLLs:
> 
> The prior version of bash, 2.05b-17, is statically linked:

The problem is that bash 3.0 has grown so much since 2.05b that statically
linking it roughly triples its size, it is already the biggest shell in
/bin, and it cannot be hardlinked to save disk space without complicating
future bash upgrades.  I suppose it may be possible to compile two
versions - the full-featured dynamically-linked bash.exe for interactive
use, and the minimally-configured statically-linked sh.exe (keep all POSIX
features like aliases, but strip all extensions like array variables) for
scripts.

Looking at ./configure --help, that would mean using:
- --disable-arith-for-command --disable-array-variables
- --disable-bang-history --disable-cond-command --disable-cond-regexp
- --disable-debugger --disable-directory-stack --disable-disabled-builtins
- --disable-dparen-arithmetic --disable-extended-glob --disable-help-builtin
- --disable-multibyte --disable-net-redirections
- --disable-process-substitution --disable-progcomp
- --disable-prompt-string-decoding --disable-select
- --disable-separate-helpfiles --enable-static-link

I dunno - shipping a static /bin/sh without the full features of bash is
once again going to lead to questions of why a shell script doesn't always
work when people use bash extensions.

> 
> This presents a somewhat serious problem for the rebaseall script.  It
> can be modified to exclude cyg{intl-3,iconv-2,readline6,ncurses-8}.dll
> but that is not a very good solution, because it means they will not be
> rebased.  These DLLs unfortunately are used by lots of programs and I
> fear not rebasing them is a poor solution.

Or, you could make rebaseall a #!/bin/ash script, which would require that
we never kill ash from the distribution, while freeing you from bash's
dynamic linking.

> 
> I think we will require a statically linked bash, or some kind of
> trickery in the rebaseall script.  One potential way around this might
> be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
> $COMSPEC to run the commands.  This would have the advantage of not
> requiring any Cygwin DLLs in use during the rebase, but it sounds more
> error prone and complicated.

Eww - outputting a .bat to do your work - that doesn't sound very appealing.

- --
Life is short - so eat dessert first!

Eric Blake             ebb9@byu.net
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.0 (Cygwin)
Comment: Public key at home.comcast.net/~ericblake/eblake.gpg
Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org

iD4DBQFCzdg084KuGfSFAYARAqiFAJi2Iur/PfoQASpJpV0Ou0Jt11bNAJ4mAC3b
Su5fKRP0rqGdQcDlzvBXaw==
=RMy7
-----END PGP SIGNATURE-----

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Christopher Faylor]

On Thu, Jul 07, 2005 at 06:15:36PM -0700, Brian Dessent wrote:
>I think we will require a statically linked bash, or some kind of
>trickery in the rebaseall script.  One potential way around this might
>be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
>$COMSPEC to run the commands.  This would have the advantage of not
>requiring any Cygwin DLLs in use during the rebase, but it sounds more
>error prone and complicated.

But, the alternative of creating a version of bash just so that people
can run rebaseall sounds even more error prone.

I don't see any other foolproof way of doing this.

Btw, don't '.bat' files work on NT, too?

cgf

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Brian Dessent]

"Adye, TJ (Tim)" wrote:

> % rebaseall
> ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6
> 
> cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can
> I do?

This is a problem with the new bash version 3.0, which is dynamically
linked to the readline, libiconv, and ncurses DLLs:

  C:\cygwin\bin\cygwin1.dll
    C:\WINXP\System32\ADVAPI32.DLL
      C:\WINXP\System32\ntdll.dll
      C:\WINXP\System32\KERNEL32.dll
      C:\WINXP\System32\RPCRT4.dll
  C:\cygwin\bin\cygintl-3.dll
    C:\cygwin\bin\cygiconv-2.dll
  C:\cygwin\bin\cygreadline6.dll
    C:\cygwin\bin\cygncurses-8.dll
    C:\WINXP\System32\USER32.dll
      C:\WINXP\System32\GDI32.dll

The prior version of bash, 2.05b-17, is statically linked:

  C:\cygwin\bin\cygwin1.dll
    C:\WINXP\System32\ADVAPI32.DLL
      C:\WINXP\System32\ntdll.dll
      C:\WINXP\System32\KERNEL32.dll
      C:\WINXP\System32\RPCRT4.dll
  C:\WINXP\System32\USER32.dll
    C:\WINXP\System32\GDI32.dll

This presents a somewhat serious problem for the rebaseall script.  It
can be modified to exclude cyg{intl-3,iconv-2,readline6,ncurses-8}.dll
but that is not a very good solution, because it means they will not be
rebased.  These DLLs unfortunately are used by lots of programs and I
fear not rebasing them is a poor solution.

I think we will require a statically linked bash, or some kind of
trickery in the rebaseall script.  One potential way around this might
be for it to output a .cmd file (or .bat under 9x, grrr) and then exec()
$COMSPEC to run the commands.  This would have the advantage of not
requiring any Cygwin DLLs in use during the rebase, but it sounds more
error prone and complicated.

Brian

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Perl Win32::Shortcut screws up fork

[Larry Hall]

At 02:54 PM 7/7/2005, you wrote:
>Hi Larry,
>
>Sorry, I assumed that the rebasing problem was ancient history, since I
>hadn't encountered it for so long (and remembered a long-ago comment
>about rebaseall being a stop-gap measure). Thanks for putting me right.


Well, it's not entirely a stop-gap measure.  The original idea is that
its functionality would become integrated into 'setup.exe' so that it 
would hopefully become (more) transparent.  But it will still be there.


>Unfortunately I can't get rebaseall to work... running from a bash
>prompt in a DOS box (as the docs tell me to), I get
>
>% ps -a
>      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
>     1668       1    1668       1668    0 22534 19:36:55 /usr/bin/bash
>     1268    1668    1268       1800    0 22534 19:45:04 /usr/bin/ps
>% rebaseall
>ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6
>
>cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can
>I do?


 From your later message, I can see you figured this out for yourself.
You may have found that not being able to rebase cygiconv-2.dll wasn't
a problem for you anyway.  Or maybe you would have.  In any case, the 
message does draw some attention, correctly or not.

Glad you got your solution. :-)


--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

RE: Perl Win32::Shortcut screws up fork

[Adye, TJ (Tim)]

Hi Larry,

Sorry, I assumed that the rebasing problem was ancient history, since I
hadn't encountered it for so long (and remembered a long-ago comment
about rebaseall being a stop-gap measure). Thanks for putting me right.

Unfortunately I can't get rebaseall to work... running from a bash
prompt in a DOS box (as the docs tell me to), I get

% ps -a
      PID    PPID    PGID     WINPID  TTY  UID    STIME COMMAND
     1668       1    1668       1668    0 22534 19:36:55 /usr/bin/bash
     1268    1668    1268       1800    0 22534 19:45:04 /usr/bin/ps
% rebaseall
ReBaseImage (/usr/bin/cygiconv-2.dll) failed with last error = 6

cygiconv-2.dll is used by bash, but rebaseall is a bash script. What can
I do?

Thanks,
Tim.

> -----Original Message-----
> From: Larry Hall
> Sent: 07 July 2005 19:09
> To: Adye, TJ (Tim); cygwin@cygwin.com
> Subject: Re: Perl Win32::Shortcut screws up fork
> 
> At 01:10 PM 7/7/2005, you wrote:
> >In an attempt to work round the problem with readshortcut I reported
> >earlier, I thought I'd use a Perl script. Unfortunately the
> >Win32::Shortcut package seems to cause problems with process forking
> >(unlike the readshortcut error, this one isn't specific to the latest
> >cygwin DLL). I get an error
> >
> >C:\cygwin\bin\perl.exe (3088): *** unable to remap
> >C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcu
> t\Shortcut.
> >dll to same address as parent(0xBF0000) != 0x1110000
> >     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
> >loading 
> 
> 
> Sounds like a classic rebasing issue to me.  Have you tried running 
> 'rebaseall'?
> 
> 
> 
> 
> --
> Larry Hall                              http://www.rfk.com
> RFK Partners, Inc.                      (508) 893-9779 - RFK Office
> 838 Washington Street                   (508) 893-9889 - FAX
> Holliston, MA 01746                     
> 
> 

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Re: Perl Win32::Shortcut screws up fork

[Larry Hall]

At 01:10 PM 7/7/2005, you wrote:
>In an attempt to work round the problem with readshortcut I reported
>earlier, I thought I'd use a Perl script. Unfortunately the
>Win32::Shortcut package seems to cause problems with process forking
>(unlike the readshortcut error, this one isn't specific to the latest
>cygwin DLL). I get an error
>
>C:\cygwin\bin\perl.exe (3088): *** unable to remap
>C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
>dll to same address as parent(0xBF0000) != 0x1110000
>     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
>loading 


Sounds like a classic rebasing issue to me.  Have you tried running 
'rebaseall'?




--
Larry Hall                              http://www.rfk.com
RFK Partners, Inc.                      (508) 893-9779 - RFK Office
838 Washington Street                   (508) 893-9889 - FAX
Holliston, MA 01746                     


--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/

Perl Win32::Shortcut screws up fork

[Adye, TJ (Tim)]

Hi,

In an attempt to work round the problem with readshortcut I reported
earlier, I thought I'd use a Perl script. Unfortunately the
Win32::Shortcut package seems to cause problems with process forking
(unlike the readshortcut error, this one isn't specific to the latest
cygwin DLL). I get an error

C:\cygwin\bin\perl.exe (3088): *** unable to remap
C:\cygwin\lib\perl5\vendor_perl\5.8\cygwin\auto\Win32\Shortcut\Shortcut.
dll to same address as parent(0xBF0000) != 0x1110000
     13 [main] perl 3716 fork_parent: child 3088 died waiting for dll
loading

Here's an example that demonstrates the problem.

#!/usr/bin/perl -w
use strict;
use Win32::Shortcut;

if (my $pid= open (my $pipe, '-|')) {
  print "forked child process $pid\n";
  while (<$pipe>) { print "from child: $_"; }
  close ($pipe) or die;
} elsif (defined $pid) {
  print "this is the child\n";
  exit;
} else {
  print "fork failed: $!\n";
}

Without the "use Win32::Shortcut", the script runs fine. With the
package the fork fails with the error message I gave. Win32::Shortcut
works fine if I don't fork or don't do it until after the package is
loaded (eg. I can eval "require Win32::Shortcut" after the fork). I see
this behaviour with Perl 5.8.6 and 5.8.7 and Cygwin 1.5.17-1 and
1.5.18-1.

This error makes it a tricky to convert the Win32::Shortcut output to
Cygwin-style paths with cygpath -u (without resorting to a separate
program to parse the results). Or is there a Perl module that can do the
cygpath conversion? That would be even nicer!

Thanks,
Tim.

==============================  cut here  ==============================
Tim Adye, BaBar Group, Particle Physics Dept.,             _   /|
          Rutherford Appleton Laboratory, UK.              \'o.O'   Oop!
e-mail:   T.J.Adye@rl.ac.uk                                =(___)=  Ack!
WWW:      http://hepwww.rl.ac.uk/Delphi/Adye/homepage.html    U  Thphft!

--
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple
Problem reports:       http://cygwin.com/problems.html
Documentation:         http://cygwin.com/docs.html
FAQ:                   http://cygwin.com/faq/