[PATCH RFC] fork: reduce chances for "address space is already occupied" errors

Achim Gratz Stromeko@nexgo.de
Fri Mar 29 07:16:00 GMT 2019

Brian Inglis writes:
> File list my-dlls.txt is your local test rebase db listing all your
> test dlls.

I think Michael got confused by your usage of "db" here.  This is in
fact just a listing of all the DLL to operate on, not the rebase
database (which won't be changed at all by an oblivious rebase, only
read in order to not collide the new rebase with the already existing

> If you are packaging your own exes and dlls with your own local Cygwin distro,
> you should point to your local utility directory with a path in a file under
> /var/lib/rebase/user.d/$USER for each Cygwin userid on each system, or perhaps
> you might also need to add your own production exes and dlls into
> /var/cache/rebase/rebase_user and /var/cache/rebase/rebase_user_exe: see
> /usr/share/doc/Cygwin/_autorebase.README.

What Michael is using is a fairly complex build system that would indeed
benefit from a layered rebase database, i.e. the one for the base system
providing the substrate for the build system and then at leat on other
one that collects the information from inside the build system (maybe
even a third layer for tests).  How to deal with the complexities of
when you want to push information down to a previous layer would likely
be a main point of contention, so you'd probably best skip it in the

SHTDI, PTC, etc.pp.

With the current rebase, you'll have to use "--oblivious" (which, again,
doesn't remember any data for the newly rebased objects) and those
non-existing upper layers will have to be provided by side-channel
information that the build system has to collect and maintain itself,
then feed to the rebase command.

+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Factory and User Sound Singles for Waldorf rackAttack:

More information about the Cygwin-patches mailing list