I'm happy to report that I was finally able to run a
successful "rebaseall" (after tracking down and stopping
the pesky service that was using Oracle DLLs and restarting
itself every time I killed it in the Task Manager).
Now that the Oracle DLLs have been rebased, the app runs.
I'm now into other
Brian Dessent writes:
>I think your best bet would be to keep poking at rebase to see if you
>can't actually rebase the Oracle DLLs.
>
>> (2) Rebase the CygWin DLL so that it loads by default into a
>> space not used in either memory map (I'd need help in
>> choosing such a space). I've
Mark Geisert writes:
> >I can't do more without learning a lot more than I currently know
> >about the internals of DLLs and of rebase.
>
> You have the "problem" Oracle DLLs, we don't :-) so you might be the
> only one who can ultimately solve the problem. But see below...
Right. But you (colle
We are finally zeroing in on the problem.
Mark Geisert writes:
> The code at /src/rebase-2.3.1/rebase.c:255 assumes the signature is at
offset 0x80
> in the image. This was true in the early Windows days but has long since
been
> generalized. The technique nowadays is to obtain the short integer
I wrote:
> Could I
> "fix" the problem by providing a stripped-down app that links all
> the DLLs and and all the same static libraries, but does nothing
> but launch a shell, which can then be used to launch the real app?
Nope, didn't work. Got the same message:
2 [main] ? (-5768) d:\m1\voy
Dave Korn wrote
>On 17 February 2006 19:21, Brian Dessent wrote:
>
>> Dave Korn wrote:
>>
>>> Absolutely so. I reckon doing a proper rebaseall that includes the
>>> oracle dlls should make a noticeable difference.
>>
>> This is important. The rebaseall script only knows about DLLs installed
>
In another context, Dave Korn writes:
> Have you looked into 'rebaseall' yet?
My reaction:
o Don't know about that, let's look it up.
o Try "man rebaseall" in CygWin shell. No luck.
o Try searching Windows 2003 Help. No luck.
o Google search turns up people who are complaining
Dave Korn writes:
> Right, thanks for giving us something we can actually get our teeth
into...
> it would really have been helpful to bring out some of this information a
bit
> earlier in the thread, like in the very first post for instance, but
better
> late than never!
Sorry I didn't send con
More test results:
> I can run tests in which I allocate static arrays of increasingly
> large size, and I hit the cygheap base problem *exactly* when I
> try to make an array bigger than 1.5 Gb.
This still happens reliably, and note that I can declare an array
of *exactly* 1.5 Gb, and load and r
Chris Taylor writes:
> You know, it wouldn't exactly be rocket science to try 1.5.19-4 ...
> Dave mentioned that there have been many improvements in the last year on
this issue - > 1.5.18-1 is rather dated now.
>
> It can't hurt to try now, can it?
Got me fair and square. I took my IT guy's ass
Dave Korn writes:
> > Unfortunately for me, (e) is impractical. It's not clear whether
> > it is my source code or CygWin's that I need to fix,
>
> Have you actually *tried* this application of yours under Cygwin and
> discovered that it indeed *is* one of the rare ones that actually runs
into
Dave Korn writes:
> On 15 February 2006 22:23, Jens Dill wrote:
>
> Jens Dill writes:
> >
> >> Original Message
> >>> From: Andreas Heckel
> >>> Sent: 07 April 2005 11:13
> ^
> > Dave:
> >
> > What you write makes it appear that CygWin simply will not support
> > la
Christopher Faylor wrote:
> On Wed, Feb 15, 2006 at 10:22:30PM +, Jens Dill wrote:
> >What you write makes it appear that CygWin simply will not support
> >large executables that reference the CygWin DLL and are also launched
> >from a CygWin shell. I can't believe that nobody has found a bett
13 matches
Mail list logo
