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

[Brian Inglis <Brian dot Inglis at SystematicSw dot ab dot ca>]

On 2019-03-29 14:23, Achim Gratz wrote:
> Brian Inglis writes:
>>> 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.

>> Achim, thanks for the clarifications; could you please comment on the suggested
>> approach for handling local production dlls and exes, or explain the best
>> approach for migrating from test to prod and handling rebase on target systems?

> I'm not quite sure what you want to know.  As I said before oblivious
> rebase was invented for running tests that use freshly built DLL (I
> usually package them before running the tests, so the package will have
> the un-rebased DLL from before the test was run).  For this it suffices
> to simply feed in all new DLL names to rebase.  If you were to build in
> stages and/or combine different builds then you'd somehow have to
> remember the DLL from each stage or build, or just collect all the DLL
> names again each time you change something.  The important thing is that
> each oblivious rebase needs to get the list of _all_ DLL that need to
> get rebased, since the database only knows about the host system
> (i.e. you can't rebase incrementally with --oblivious).

I was wondering as my first para above stated, whether rebase_user{,_exe} would
be the proper place to add 3rd party Cygwin dlls and exes, that are distributed
with Cygwin (internally)?

-- 
Take care. Thanks, Brian Inglis, Calgary, Alberta, Canada

This email may be disturbing to some readers as it contains
too much technical detail. Reader discretion is advised.