simplifying rebaseall

simplifying rebaseall

[Al]

To rebase I currently have to do the following steps:

Open a windows command shell (cmd):
P:/cygwin/bin/ash
/bin/rebaseall
exit
exit

I wonder if there could be a more simple way, i.e. putting it into a
*.bat script and binding it to an task icon.

I am thinking of something in this sense:

P:/cygwin/bin/ash --exec /bin/rebaseall

As a longterm Linux user I have few experience with windows scripts.
Would be nice to have such a script directly linked into the start
menu.

Al

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

Re: simplifying rebaseall

[Al]

A second thought. I wonder if reabaseall could be improved to run from
within bash, without the need to close down all running windows. Then
it could even be included into build scripts to be run after each
build.

Assuming that those DLL which are up and running typically don't need
to be rebased, couldn't one simply exclude them from being rebased?
I.e. with on option:

rebaseall --exclude-loaded

Al

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

Re: simplifying rebaseall

[Charles Wilson]

On 9/17/2010 10:39 AM, Al wrote:
> A second thought. I wonder if reabaseall could be improved to run from
> within bash, without the need to close down all running windows. Then
> it could even be included into build scripts to be run after each
> build.

No, because the DLLs used by bash are OFTEN the ones that actually DO
need to be rebased (because they are used by darn near everything, so we
need to ensure that their image base does not conflict with anything
else): libintl, libiconv, libncurses, ...

> Assuming that those DLL which are up and running typically don't need
> to be rebased, couldn't one simply exclude them from being rebased?
> I.e. with on option:
> 
> rebaseall --exclude-loaded

You're missing the point of rebaseALL.  Murphy says that if you don't
rebase dll A, then dll A *will* be the culprit the next time you get
that 'unable to remap' error.

With regards to your earlier .bat file idea...Meh. You shouldn't need to
DO it that often -- certainly not often enough to clutter your start
menu or desktop with a shortcut!

--
Chuck

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

Re: simplifying rebaseall

[Larry Hall (Cygwin)]

On 9/17/2010 10:50 AM, Charles Wilson wrote:
> On 9/17/2010 10:39 AM, Al wrote:
>> A second thought. I wonder if reabaseall could be improved to run from
>> within bash, without the need to close down all running windows. Then
>> it could even be included into build scripts to be run after each
>> build.
>
> No, because the DLLs used by bash are OFTEN the ones that actually DO
> need to be rebased (because they are used by darn near everything, so we
> need to ensure that their image base does not conflict with anything
> else): libintl, libiconv, libncurses, ...
>
>> Assuming that those DLL which are up and running typically don't need
>> to be rebased, couldn't one simply exclude them from being rebased?
>> I.e. with on option:
>>
>> rebaseall --exclude-loaded
>
> You're missing the point of rebaseALL.  Murphy says that if you don't
> rebase dll A, then dll A *will* be the culprit the next time you get
> that 'unable to remap' error.
>
> With regards to your earlier .bat file idea...Meh. You shouldn't need to
> DO it that often -- certainly not often enough to clutter your start
> menu or desktop with a shortcut!

And it invites casual use without understanding the what and why.  This means
more people using it for no reason and more problems using it when it is
needed because people don't understand the requirements to make it work
(i.e. *nobody* will read the readme... wait, there's a readme? ;-) ).

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

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: simplifying rebaseall

[Al]

>
> And it invites casual use without understanding the what and why.  This
> means
> more people using it for no reason and more problems using it when it is
> needed because people don't understand the requirements to make it work
> (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ).
>

Hmm, how does information work currently? I found the hint to run
rebase somewhere in a blog, when I was hunting down a bug. Others will
be told on this list to run rebase all without the hint of a readme.
You can verify this be reading the lists archive. The only hint you
find in the FAQ is below the topic "Terminal Server machine". Who is
finding that?

I wouldn't even have an idea how to find and read this readme while
using ash. I was reading the sources before finding the readme all. I
have 10 years of Linux experience and even I didn't expect there was a
readme around in this case. If you want to make sure people are
informed before running it, it would be an option to display a small
text when the script is starting, with the hint to the readme. That
would even work with a link from the start menu.

If there is a danger that people run rebase all without reading the
readme, there is a similar danger that people give up Cygwin, before
they ever discover that they could solve their issues by running
rebaseall.

Al

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

Re: simplifying rebaseall

[Charles Wilson]

On 9/17/2010 12:18 PM, Al wrote:
>>
>> And it invites casual use without understanding the what and why.  This
>> means
>> more people using it for no reason and more problems using it when it is
>> needed because people don't understand the requirements to make it work
>> (i.e. *nobody* will read the readme... wait, there's a readme? ;-) ).
>>
> 
> Hmm, how does information work currently?

Almost EVERYTHING in cygwin has a README. Take a look in
/usr/share/doc/Cygwin sometime. Furthermore many packages (but not
rebase) have additional documentation in /usr/share/doc/$PKG/ -- just
like on linux.

> I found the hint to run
> rebase somewhere in a blog, when I was hunting down a bug. Others will
> be told on this list to run rebase all without the hint of a readme.

Because most people, when told to 'run rebaseall' will say to themselves
"I don't know how to run rebaseall. I wonder if it has a help option..."

$ rebaseall --help
rebaseall: only ash or dash processes are allowed during rebasing
    Exit all Cygwin processes and stop all Cygwin services.
    Execute ash (or dash) from Start/Run... or a cmd or command window.
    Execute '/bin/rebaseall' from ash (or dash).

No...but that's a pretty descriptive error message.  However, I still
want more information.  Maybe there's a man page:

$ man rebaseall
No manual entry for rebaseall

$ man rebase
No manual entry for rebase

Info page?
$ info rebaseall
$ info rebase

No.

Well, there must be SOME documentation somewhere.  I know: I'll look in
the /usr/share/doc

$ ls /usr/share/doc/*rebase*
ls: cannot access /usr/share/doc/*rebase*: No such file or directory

No.

Well, Cygwin puts some documentation in /usr/share/doc/Cygwin, so I
better look there:

$ ls /usr/share/doc/Cygwin/*rebase*
/usr/share/doc/Cygwin/rebase-3.0.1.README

A-HA!

Now, surely that is a lot of hunting around -- but I can only assume
that many people did so, since you are apparently the first person to
fail to locate the documentation when faced with the question "How do I
run rebaseall"?

> You can verify this be reading the lists archive. The only hint you
> find in the FAQ is below the topic "Terminal Server machine". Who is
> finding that?

Should we put "If you have a question about package foo, be sure and
look in /usr/share/doc/foo*/ and at /usr/share/doc/Cygwin/foo* for more
information" in the signature line of every message?

> I wouldn't even have an idea how to find and read this readme while
> using ash.

See above.  Most of that should be very familiar to a person with "10
years of Linux experience" -- except for the bit about "Cygwin packages
often put a cygwin-specific README file in /usr/share/doc/Cygwin/"

Maybe THAT tidbit should go in the FAQ...but I doubt the Questioned is
Frequently Asked in this form: "Where can I find additional information
about specific Cygwin packages".

No, the question would be asked "Where can I get more information about
foo" or "...rebase" or "..gcc" or "...wget"

So, even if the FAQ *did* have the following:

Q: Where can I find additional information about specific Cygwin packages?
A: Look in /usr/share/doc/Cygwin/.  Most cygwin packages put some
cygwin-specific information in a README file located in that directory.

...you still wouldn't have found it -- unless you are in the habit of
reading FAQs from top-to-bottom (I'm not...).

> If there is a danger that people run rebase all without reading the
> readme, there is a similar danger that people give up Cygwin, before
> they ever discover that they could solve their issues by running
> rebaseall.

Look, we recognize that this rebase issue has cause *you* heartburn.  It
annoys us too, but thanks to Bill G, we can't really do anything about
it.  But, what you have to realize is -- it *does not* always occur.
Not *every* user is impacted by it.  Many users might use cygwin for
years and NEVER see the dreaded "unable to remap" error.

Those people would be in danger of accidentally (or curiously) clicking
a shortcut called 'rebase'.  The pain of THAT far outweighs the tiny
convenience, for a small population of unfortunate newbies, that might
need to run rebase but are not yet experienced enough to know all about
it.  (Worse, we simply CAN'T create a shortcut if the rebase problem
hits 'bash' -- all such postinstall scripts themselves will fail with
the remap error!)

--
Chuck

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

Re: simplifying rebaseall

[Al]

Hi,

I appreciate you take the time to contribute all that information.
Hope it is not only red by me.

>
> Now, surely that is a lot of hunting around -- but I can only assume
> that many people did so, since you are apparently the first person to
> fail to locate the documentation when faced with the question "How do I
> run rebaseall"?

I wasn't faced with that question. I was face with error messages.
Google guided me by this messages (and many others) to exactly this
blog first:

http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html

... not to Cygwin list, not to the readme, not to the FAQ. The blog
rather tells how to run rebaseall not much why. The comments document
well that many people follow that advice without any knowledge of any
readme. You don't even find the word readme on that blog.

> See above.  Most of that should be very familiar to a person with "10
> years of Linux experience" -- except for the bit about "Cygwin packages
> often put a cygwin-specific README file in /usr/share/doc/Cygwin/"
>

It's familiar that regular programs have a doc, man etc. It's also
familiar that small maintenance scripts don't have. Even your posting
has more lines the he rebaseall script itself. So you wouldn't really
follow the search path for docs you give here. That there is a readme
for such a small script is the positive execption. But I have doubts
that many people will find it.

Al

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

Re: simplifying rebaseall

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 787 bytes --]

On Fri, Sep 17, 2010 at 07:38:03PM +0200, Al wrote:
> Hi,

Hello,

> It's familiar that regular programs have a doc, man etc. It's also
> familiar that small maintenance scripts don't have. Even your posting
> has more lines the he rebaseall script itself. So you wouldn't really
> follow the search path for docs you give here. That there is a readme
> for such a small script is the positive execption. But I have doubts
> that many people will find it.

I guess for many people cygwin is their first contact with a *NIX like
environment, but given your previous knowledge in Linux, it could also
have been and option to inspect the package contents:

cygcheck -l rebase

Regards.

-- 
Huella de clave primaria: 0FDA C36F F110 54F4 D42B  D0EB 617D 396C 448B 31EB

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: simplifying rebaseall

[Al]

> I guess for many people cygwin is their first contact with a *NIX like
> environment, but given your previous knowledge in Linux, it could also
> have been and option to inspect the package contents:
>
> cygcheck -l rebase
>

It's not only that many people have in Cygwin their first contact with
the *NIX world. There is always a point when you have your first
contact with a new Distro. "cygcheck" will be self-evident for every
Cygwin insider, but it is foreign for every newcomer, even with 30
years *NIX experience. I see it here the first time.

Al

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

Re: simplifying rebaseall

[David Sastre]

[-- Attachment #1: Type: text/plain, Size: 1004 bytes --]

On Fri, Sep 17, 2010 at 08:01:23PM +0200, Al wrote:
> > I guess for many people cygwin is their first contact with a *NIX like
> > environment, but given your previous knowledge in Linux, it could also
> > have been and option to inspect the package contents:
> >
> > cygcheck -l rebase
> 
> It's not only that many people have in Cygwin their first contact with
> the *NIX world. There is always a point when you have your first
> contact with a new Distro. "cygcheck" will be self-evident for every
> Cygwin insider, but it is foreign for every newcomer, even with 30
> years *NIX experience. I see it here the first time.

That's true. I used cygwin for a year or so before even noticing
cygcheck was there :) I think I started using it after reading
http://cygwin.com/problems.html (cygcheck -s -v -r > cygcheck.out)
But, well, it's more or less the same when you switch from apt/deb to yum/rpm.


-- 
Huella de clave primaria: 0FDA C36F F110 54F4 D42B  D0EB 617D 396C 448B 31EB

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 198 bytes --]

Re: simplifying rebaseall

[Larry Hall (Cygwin)]

On 9/17/2010 1:38 PM, Al wrote:
> Hi,
>
> I appreciate you take the time to contribute all that information.
> Hope it is not only red by me.
>
>>
>> Now, surely that is a lot of hunting around -- but I can only assume
>> that many people did so, since you are apparently the first person to
>> fail to locate the documentation when faced with the question "How do I
>> run rebaseall"?
>
> I wasn't faced with that question. I was face with error messages.
> Google guided me by this messages (and many others) to exactly this
> blog first:
>
> http://www.mylifestartingup.com/2009/04/fatal-error-unable-to-remap-to-same.html
>
> ... not to Cygwin list, not to the readme, not to the FAQ. The blog
> rather tells how to run rebaseall not much why. The comments document
> well that many people follow that advice without any knowledge of any
> readme. You don't even find the word readme on that blog.

But we have no control over that obviously.  I think it's important to
recognize when you go searching for information, it makes sense to weigh
what you find against its source and consider the project's source as a
more definitive and complete set of information.  Obviously, there's
nothing wrong with searching anywhere and everywhere for some clue about a
problem.  But information that comes from sites that are obviously not
the project's site, cygwin.com in this case, is also a clue that further
research using the project's resources and the new found data is a good
idea.

There's no question that there is quite a leap from the error message given
to the fact that rebasing is a possible solution (and not the only possible
solution - see <http://cygwin.com/acronyms/#BLODA> for another).  A FAQ
entry about the remap error message would probably help some at least.
Over time, the hope is that package rebuilding helps make this even less of
a problem.  But it is a pain regardless without a great solution.

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

_____________________________________________________________________

A: Yes.
> Q: Are you sure?
>> A: Because it reverses the logical flow of conversation.
>>> Q: Why is top posting annoying in email?

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

Re: simplifying rebaseall

[Christopher Faylor]

On Fri, Sep 17, 2010 at 08:01:23PM +0200, Al wrote:
>> I guess for many people cygwin is their first contact with a *NIX like
>> environment, but given your previous knowledge in Linux, it could also
>> have been and option to inspect the package contents:
>>
>> cygcheck -l rebase
>>
>
>It's not only that many people have in Cygwin their first contact with
>the *NIX world. There is always a point when you have your first
>contact with a new Distro. "cygcheck" will be self-evident for every
>Cygwin insider, but it is foreign for every newcomer, even with 30
>years *NIX experience. I see it here the first time.

If you are using any new distro you have to figure out how to query
package information.  It is not innate ancestral knowledge that comes
from having evolved from hippos.

This discussion seems to boil down to "Someone should add words about
rebaseall to the FAQ".

Anyone want to donate some words and suggest where they should go in
the FAQ?

cgf

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

RE: simplifying rebaseall

[Bill Ross]

> This discussion seems to boil down to "Someone should add words about
> rebaseall to the FAQ".

-bash-3.2$ /bin/rebaseall --help
rebaseall: only ash or dash processes are allowed during rebasing
    Exit all Cygwin processes and stop all Cygwin services.
    Execute ash (or dash) from Start/Run... or a cmd or command window.
    Execute '/bin/rebaseall' from ash (or dash).

Maybe that info could include a pointer to the doc?

Bill

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

Re: simplifying rebaseall

[Al]

>
> This discussion seems to boil down to "Someone should add words about
> rebaseall to the FAQ".
>

If words to the FAQ, then:

1.) a matching header
2.) including link to the readme
3.) including the famous error messages people enter into the search machines:

 *** fatal error - unable to remap to same address as parent :

Then I see some chances that it is found.

Al

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

Re: simplifying rebaseall

[Christopher Faylor]

On Fri, Sep 17, 2010 at 11:48:47AM -0700, Bill Ross wrote:
>> This discussion seems to boil down to "Someone should add words about
>> rebaseall to the FAQ".
>
>-bash-3.2$ /bin/rebaseall --help
>rebaseall: only ash or dash processes are allowed during rebasing
>    Exit all Cygwin processes and stop all Cygwin services.
>    Execute ash (or dash) from Start/Run... or a cmd or command window.
>    Execute '/bin/rebaseall' from ash (or dash).
>
>Maybe that info could include a pointer to the doc?

You mean the nonexistent FAQ entry mentioned above?  I think most people
would find that unhelpful.

cgf

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

Re: simplifying rebaseall

[Christopher Faylor]

On Fri, Sep 17, 2010 at 08:49:04PM +0200, Al wrote:
>>
>> This discussion seems to boil down to "Someone should add words about
>> rebaseall to the FAQ".
>>
>
>If words to the FAQ, then:
>
>1.) a matching header
>2.) including link to the readme
>3.) including the famous error messages people enter into the search machines:
>
> *** fatal error - unable to remap to same address as parent :
>
>Then I see some chances that it is found.

Hmm.  Still no actual *words*.  Just the usual propounding.

But, yes, if someone does volunteer to write a FAQ entry it should
actually be informative.  Sorry I didn't make that clear.

Next?

cgf

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

RE: simplifying rebaseall

[Bill Ross]

> >-bash-3.2$ /bin/rebaseall --help
> >rebaseall: only ash or dash processes are allowed during rebasing
> >    Exit all Cygwin processes and stop all Cygwin services.
> >    Execute ash (or dash) from Start/Run... or a cmd or command
window.
> >    Execute '/bin/rebaseall' from ash (or dash).
> >
> >Maybe that info could include a pointer to the doc?
>
> You mean the nonexistent FAQ entry mentioned above?  I think most
people
> would find that unhelpful.

If that is the only doc to point to, then you are right.
Alternatively, the recent archives might point to how hard existing docs
are to find.

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

Re: simplifying rebaseall

[Al]

>
> If that is the only doc to point to, then you are right.
> Alternatively, the recent archives might point to how hard existing docs
> are to find.

Good doc is availble. Unfortunatly it is badly linked.

http://www.tishler.net/jason/software/rebase/rebase-2.4.2.README

It's not the first thing you run into when entering the error messages.

 *** fatal error - unable to remap to same address as parent :

Meanwhile we are in the first page of google whith this thead, when
enteringering the message. Good chances that it will be more easy in
future due to this effect. :-)

Al

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

Re: simplifying rebaseall

[Al]

>> A second thought. I wonder if reabaseall could be improved to run from
>> within bash, without the need to close down all running windows. Then
>> it could even be included into build scripts to be run after each
>> build.
>
> No, because the DLLs used by bash are OFTEN the ones that actually DO
> need to be rebased (because they are used by darn near everything, so we
> need to ensure that their image base does not conflict with anything
> else): libintl, libiconv, libncurses, ...
>

What I suggest isn't that usefull when you think to base all
DLL that have been installed by setup.exe. It becomes usefull in the
moment the user starts to compile his own DLL especially if he used
scripts to control compilation. To compile somethng is a typical use
of cygwin.

I try to be more precise. Let's call it rebaseplus, but it's
code is to 80% similar to rebaseall and duplication of code has known
disadvantages.

Once rebaseall has been run from ash we can be sure the listed DLLs
have sane addresses and bash does work. Now rebaseplus can be run from
within bash (and scripts) using a user contributed list of DLL (-T-option).
It would base the user contributed DLL into a different address space than
rebaseall does.

Al

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

Re: simplifying rebaseall

[Christopher Faylor]

On Sat, Sep 18, 2010 at 08:36:28PM +0200, Al wrote:
>>> A second thought. I wonder if reabaseall could be improved to run from
>>> within bash, without the need to close down all running windows. Then
>>> it could even be included into build scripts to be run after each
>>> build.
>>
>> No, because the DLLs used by bash are OFTEN the ones that actually DO
>> need to be rebased (because they are used by darn near everything, so we
>> need to ensure that their image base does not conflict with anything
>> else): libintl, libiconv, libncurses, ...
>>
>
>What I suggest isn't that usefull when you think to base all
>DLL that have been installed by setup.exe. It becomes usefull in the
>moment the user starts to compile his own DLL especially if he used
>scripts to control compilation. To compile somethng is a typical use
>of cygwin.

No, it really isn't.

>I try to be more precise. Let's call it rebaseplus, but it's
>code is to 80% similar to rebaseall and duplication of code has known
>disadvantages.
>
>Once rebaseall has been run from ash we can be sure the listed DLLs
>have sane addresses and bash does work. Now rebaseplus can be run from
>within bash (and scripts) using a user contributed list of DLL (-T-option).
>It would base the user contributed DLL into a different address space than
>rebaseall does.

This isn't a bad idea but it's not really a typical use case.  Perhaps you'd
like to offer a patch to rebaseall to accomplish this?

cgf

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

Re: simplifying rebaseall

[Al]

>>scripts to control compilation. To compile somethng is a typical use
>>of cygwin.
>
> No, it really isn't.

I quote wikipedia:

Cygwin is used heavily for porting many popular pieces of software to
the Windows platform. It is used to compile Sun Java, OpenOffice.org,
and even server software, like lighttpd.

If that isn't valid any more, it's time to update the article.

>
> This isn't a bad idea but it's not really a typical use case.  Perhaps you'd
> like to offer a patch to rebaseall to accomplish this?
>

Sure I offer a patch. Else I wouldn't come up with a suggestion. I
need to work on that anyway.

Al

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

Re: simplifying rebaseall

[Christopher Faylor]

On Sun, Sep 19, 2010 at 12:43:17AM +0200, Al wrote:
>On Sat, Sep 18, 2010 at 05:48:07PM -0400, Christopher Faylor wrote:
>>>scripts to control compilation. To compile somethng is a typical use
>>>of cygwin.
>>
>> No, it really isn't.
>
>I quote wikipedia:
>
>Cygwin is used heavily for porting many popular pieces of software to
>the Windows platform. It is used to compile Sun Java, OpenOffice.org,
>and even server software, like lighttpd.
>
>If that isn't valid any more, it's time to update the article.

Maybe this will help:

http://cygwin.com/dontbelieveeverythingyoureadonrandomsitesaboutcygwin.html

cgf

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

Re: simplifying rebaseall

[Steven Hartland]

----- Original Message ----- 
From: "Christopher Faylor"

>>What I suggest isn't that usefull when you think to base all
>>DLL that have been installed by setup.exe. It becomes usefull in the
>>moment the user starts to compile his own DLL especially if he used
>>scripts to control compilation. To compile somethng is a typical use
>>of cygwin.
> 
> No, it really isn't.

I'd beg to differ; I'd suggest it is, as suggested by the OP,
actually quite a common use. You only have to look at the use of
say perl and you will have users quite regularly compiling their
own DLL's as they install modules via CPAN, and this is quite painful
due to all the issues it can present with rebase.

While I love cygwin, I must say that its supporting community can
be very dismissive of its users to the point of alienating potential
contributors. I myself has have experienced this on several occasions
and have ended up finding myself not raising issues that affect us
daily for fear of being shot down for no more reason that someone
doesn't "think" its import to fix or should "work" that way anyway
or even doesn't like the way you structured you post.

To reiterate I still think that developers deserve much respect
and thanks for all the effort they put in, but a little more open
mindedness and approachability like that which can be found in other
open source communities such as SFU and FreeBSD wouldn't go a miss
sometimes ;-)

    Regards
    Steve


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

Re: simplifying rebaseall

[Christopher Faylor]

On Sun, Sep 19, 2010 at 03:52:56AM +0100, Steven Hartland wrote:
>----- Original Message ----- 
>From: "Christopher Faylor"
>
>>>What I suggest isn't that usefull when you think to base all
>>>DLL that have been installed by setup.exe. It becomes usefull in the
>>>moment the user starts to compile his own DLL especially if he used
>>>scripts to control compilation. To compile somethng is a typical use
>>>of cygwin.
>> 
>> No, it really isn't.
>>
>> This isn't a bad idea but it's not really a typical use case. ?Perhaps you'd
>> like to offer a patch to rebaseall to accomplish this?
>
>I'd beg to differ; I'd suggest it is, as suggested by the OP,
>actually quite a common use. You only have to look at the use of
>say perl and you will have users quite regularly compiling their
>own DLL's as they install modules via CPAN, and this is quite painful
>due to all the issues it can present with rebase.

We have different definitions of the term "typical".  The vast VAST
majority of people who use Cygwin do not build their own DLLs but they
are likely to run into rebase problems.

>To reiterate I still think that developers deserve much respect
>and thanks for all the effort they put in, but a little more open
>mindedness and approachability like that which can be found in other
>open source communities such as SFU and FreeBSD wouldn't go a miss
>sometimes ;-)

You are responding, for some reason, to one line where I said "No, it
really isn't" and ignoring the rest of the message where I suggested
that the OP could provide a patch and they even said they were going to
do so.  This is pretty typical Cygwin mailing list behavior: ignore the
substance and focus on the indignation.  It's hardly helpful and it
doesn't really get the problem solved.

cgf

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

Re: simplifying rebaseall

[Al]

> I'd beg to differ; I'd suggest it is, as suggested by the OP,
> actually quite a common use. You only have to look at the use of
> say perl and you will have users quite regularly compiling their
> own DLL's as they install modules via CPAN, and this is quite painful
> due to all the issues it can present with rebase.
>
> While I love cygwin, I must say that its supporting community can
> be very dismissive of its users to the point of alienating potential
> contributors. I myself has have experienced this on several occasions
> and have ended up finding myself not raising issues that affect us
> daily for fear of being shot down for no more reason that someone
> doesn't "think" its import to fix or should "work" that way anyway
> or even doesn't like the way you structured you post.
>
> To reiterate I still think that developers deserve much respect
> and thanks for all the effort they put in, but a little more open
> mindedness and approachability like that which can be found in other
> open source communities such as SFU and FreeBSD wouldn't go a miss
> sometimes ;-)
>
>   Regards
>   Steve
>

thanks

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

Re: simplifying rebaseall

[Al]

> I wonder if there could be a more simple way, i.e. putting it into a
> *.bat script and binding it to an task icon.
>
> I am thinking of something in this sense:
>
> P:/cygwin/bin/ash --exec /bin/rebaseall
>
> As a longterm Linux user I have few experience with windows scripts.
> Would be nice to have such a script directly linked into the start
> menu.

It's possible to create a link with this adapted to your pathes:

%SystemRoot%\system32\cmd.exe /k P:/cygwin/bin/ash /bin/rebaseall

Same with an additional user's DLL list:

%SystemRoot%\system32\cmd.exe /k P:/cygwin/bin/ash /bin/rebaseall -T
/home/prefix/rebase.lst


Al

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