tcp-wrappers for 1.7.0
Fri Apr 25 17:32:00 GMT 2008
Corinna Vinschen wrote:
> On Apr 25 00:28, Charles Wilson wrote:
>> Corinna Vinschen wrote:
> Cool, thanks. Btw., the openssh package I uploaded to the release-2
> area yesterday is already using your csih-based config scripts.
Neat-o. Keeping fingers crossed...
>> I guess next I should turn of Address Space Layout Randomization, then
>> re-run rebaseall. Sigh.
> I didn't know there's something to switch on or off. As far as I
> understood this issue, the randomization is controlled by a flag in
> the executables. Did I miss something?
No, you're right (I think). Since gcc doesn't set that flag, it must not
be affecting the cygwin fork/exec process. Besides, ASLR is performed
only once per bootup; it's not like system DLLs are moving all around in
every new processes' address space.
Seems like this is just the same old problem...
>> Dare I hope that cygwin-1.7 might be better behaved, or does this have
>> absolutely nothing to do with the cygwin1.dll and is all about the *other*
> There's always hope. But you can't deny the generic problem with fork
> on Windows, unless we are in control of the entire loader process.
> Which we aren't.
Well, I'm kinda stuck, then. Cygwin (1.5) is virtually useless for
development on my Vista box, and my WinXP box won't be around forever.
I'll install 1.7 on both, and hope it works for me on Vista.
Ideas for cygwin-1.9 (not a new one):
(1) add ld.so functionality to cygwin2.dll
(2) ...miracle happens where cygwin .exe's and cygwin .dll's can
simultaneously have all symbols satisfied, yet not be linked directly to
DLLs other than cygwin2.dll and windows system .dlls.
(3) cygwin DLL controls loading dependent *cygwin* libraries at runtime.
Step 2 reminds me of the South Park underpants gnomes' business plan.
More information about the Cygwin-apps