This is the mail archive of the cygwin@cygwin.com mailing list for the Cygwin project.
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |
Other format: | [Raw text] |
On Sat, Dec 08, 2001 at 10:08:14AM +1100, Robert Collins wrote: > Yes. There is actually a longer term solution... which is to 'rebase' > every cygwin linked .dll on a particular system to not conflict with > each other - which has to be done by setup.exe. I just tried a hand rebase of my system using the MS supplied rebase tool to see if this will fix the problem at least for the Python case. Specifically, I rebased the following DLLs: o Python DLL (e.g., libpython2.2.dll) o all Python standard shared extension modules (e.g., _socket.dll) o all Cygwin DLLs in /usr/bin that match cyg*.dll except for the following: - cygwin1.dll: since I believe that it relies on being based at 0x61000000 - cygcurl-2.dll: because it gets "whacked" by rebase and AFAICT is not used by Python anyway - cygtclpip80.dll: because it appears not to be relocatable Additionally, following the suggestions from the MSDN, I rebased from 0x68000000 down. So, all of the above DLLs were rebased into the range of 0x672e0000 - 0x68000000. After rebasing, the minimal test case that previously exhibited the problem: http://cygwin.com/ml/cygwin/2001-12/msg00419.html now works fine. Unfortunately, when I run the complete Python regression test, I still get the same three test failures as reported by Michael without rebasing: test_popen2 test_pty test_socket When I run these tests individually (i.e., not part of the complete test suite), then they pass. Hence, the rebasing appears not to completely solve this problem. See the attached snippet of output from a regression test run (and search for 0x1A). It shows that although there should not be DLL base address conflicts, some DLLs are being rebased in the parent anyway. A few examples are: _socket.dll: rebased to 0x67f50000 loaded at 0x1A260000 cygz.dll: rebased to 0x678b0000 loaded at 0x1A310000 Would other Python users (with access to MS's rebase tool) be willing to try to reproduce my findings to eliminate the possibility of cockpit error on my part? Does anyone understand why the DLLs are being rebased even though there theoretically is no chance of a base address conflict anymore? Thanks, Jason
Attachment:
rebase.txt
Description: Text document
-- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Bug reporting: http://cygwin.com/bugs.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Index Nav: | [Date Index] [Subject Index] [Author Index] [Thread Index] | |
---|---|---|
Message Nav: | [Date Prev] [Date Next] | [Thread Prev] [Thread Next] |