This is the mail archive of the
mailing list for the Cygwin project.
Re: Confusion re: use of rebaseall vs. rebase to relieve BitDefender woes REDUX
Eliot Moss wrote:
Ok, I was wrong about ash (not) using cygwin1.dll.
Running ldd on rebase and peflags reveals that they use it
too, which pretty much says that they are cygwin apps.
Thanks. I was beginning to think I'd lost my mind...
However, it also shows that the preferred load address, on
my system anyway, for cygwin1.dll is 0x61000000. That
explains the starting point for my -d rebasing -- to go
Interesting. That explains the 0x61000000 -- it's certainly not
cygwin1.dll has its base set when it is built. There may be
some way to rebase it, but I don't know what it is, though I
expect that there is a Windows tools for doing it if it
Well, what BitDefender recommended, and what had always worked
until the last time I upgraded Cygwin 1.7, was the following:
1) Turn off BitDevender's Advanced Virus Control (AVC);
2) Open a cmd.exe window;
3) Run the following commands in that window:
copy cygwin1.dll cygwin_orig.dll
copy cygwin1.dll cygwin_tmp.dll
rebase -b 0x35000000 cygwin_tmp.dll
copy cygwin_tmp.dll cygwin1.dll
4) Reenable AVC.
In other words, they're explicitly using the cygwin rebase command to move
cygwin1.dll's load address to 0x35000000. Which I assume is far, far away
from whatever BitDefender library is interfering with it.
As I say, that worked find up until my last upgrade. After I ran the above
steps on that upgraded Cygwin distro, all the windows and most of the
commands worked. But piping output among various cygwin commands (and even
the find -exec flag) began failing if the amount of info being piped from
one command to the other was more than a line or two. That's when I searched
through the cygwin forum to try and find something a little more sophisticated
than the above -- on the assumption that perhaps I was experiencing a mis-match
between where the cygwin1.dll library was now loaded and where some other
unknown library expected it to be. Naive perhaps, but I didn't think I had
time to research the relationships among the various components of cygwin. As
it turned out, I had several days -- the time I spent attacking it in a whack-
a-mole fashion :-)
It was not necessary for me.
Checking my scripts, I eliminate cygwin1.dll from the list of
dlls, and ash.exe and peflags.exe from the list of exes. Could
probably remove rebase.exe as well, but it did not seem to
It *is* important that ash does *not* load some other big
dlls related to C libraries, which bash tends to want.
These in particular:
cygintl-8.dll => /usr/bin/cygintl-8.dll (0x58f70000)
cygiconv-2.dll => /usr/bin/cygiconv-2.dll (0x59060000)
cygreadline7.dll => /usr/bin/cygreadline7.dll (0x57320000)
cygncurses-9.dll => /usr/bin/cygncurses-9.dll (0x6db80000)
cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x5c1e0000)
Didn't see any of those in the ProcessExplorer output, so I guess I'm golden
(Part of the output from ldd /bin/bash.)
Hope there's something here that helps ... Eliot
Quiet a bit, actually. I was beginning to think I'd lost my mind there for
Again, thank you for all your assistance. After that last experience, I blew
away my cygwin distro, and I'm reinstalling it now. Once that's finished
I'll give your method another go and see what happens!
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple