Mail Archives: cygwin/2009/12/05/18:54:48
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
> below cygwin1.dll.
Interesting. That explains the 0x61000000 -- it's certainly not
arbitrary!
> 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
> matters.
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:
cd c:\cygwin\bin
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
> matter.
>
> 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
awhile :-)
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!
Regards,
-- Ed
--
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
- Raw text -