Michael Haubenwallner writes: > Before I really can tell what I need regarding the rebase, I need to learn > what > exactly is recorded into the rebase database, and probably how the recorded > data > does influence the rebase procedure right now.
Just where the DLL resides in the filesystem, what address it has been rebased to and what size it occupies. If you rebase a new DLL with the database, it will give you the first gap in the address space that this new DLL fits into for doing the rebase and record that into the database. With the --oblivious option, it keeps the database file untouched, so the information about the newly rebased DLL gets lost whenh the program exits. That's why you need to do all oblivious rebasing in a single invocation. > My thoughts so far for what I probably need: > > * First, rebase new dlls before being installed into the target file system > directory with respect to currently installed dlls (the --oblivious > option), You always rebase after the install so that the path information is correct. Pre-rebasing is useless. > * Second, register new dlls just installed into the target file system > directory into the rebase database without performing a rebase, and No, rebasing the installed DLL already does that. > * Third, unregister dlls being removed from the rebase database. Rebase already removes any entries that are no longer accessible from the database. > Also, it may make sense to allow for reusing the base address of an installed > dll by it's update replacement - while the old version dll still is in use and > the new version dll is in some temporary staging directory. Rebase already re-uses the base-address if the path for the new DLL is the same and it still fits into the gap. In general, however, that won't work when the size of any DLL changes. You can ask for more guardband around each entry, but that doesn't actually solve the problem as it's only useful for the initial (full) rebase. > As there may be multiple instances of Gentoo Prefix within one single > operating > system instance, it does not make sense to record the dll's base addresses > into > the rebase database of the underlying Cygwin instance in /etc, but still the > base addresses already recorded there should be respected when rebasing dlls > for within a particular Gentoo Prefix instance. If you can limit the address space that's used by the Cygwin base system, I'd just give your Gentoo prefix installation its own address space and rebase it independently from the base system. That probably requires some fooling around with the (currently hardcoded) rebase database files, but should otherwise just work. > Furthermore, with so called "Stacked Prefix", it is possible to have a second > level of Gentoo Prefix, so what I'm after is some option to tell the rebase > utility which database to record dll base addresses into, and which > multiple(!) > databases take into account while performing a rebase. I don't think you'll want to do that. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Wavetables for the Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
