On Apr 24 17:09, Michael Haubenwallner wrote:
> On 4/12/19 7:40 PM, Corinna Vinschen wrote:
> > Hi Michael,
>
> > Nick Clifton, one of the binutils maintainers, made the following
> > suggestion in PM:
> >
> > Allow the ld flag --enable-auto-image-base to take a filename as
> > argument.>
> >
On 4/12/19 7:40 PM, Corinna Vinschen wrote:
> Hi Michael,
> Nick Clifton, one of the binutils maintainers, made the following
> suggestion in PM:
>
> Allow the ld flag --enable-auto-image-base to take a filename as
> argument.>
> The idea: The file is used by ld to generate the start address
>
On Apr 13 09:46, Achim Gratz wrote:
> Corinna Vinschen writes:
> > Nick Clifton, one of the binutils maintainers, made the following
> > suggestion in PM:
> >
> > Allow the ld flag --enable-auto-image-base to take a filename as
> > argument.
> >
> > The idea: The file is used by ld to generate the
Corinna Vinschen writes:
> Nick Clifton, one of the binutils maintainers, made the following
> suggestion in PM:
>
> Allow the ld flag --enable-auto-image-base to take a filename as
> argument.
>
> The idea: The file is used by ld to generate the start address
> for the next built DLL. Mechanism:
Hi Michael,
On Apr 3 14:22, Corinna Vinschen wrote:
> On Apr 3 11:18, Michael Haubenwallner wrote:
> > On 4/1/19 5:56 PM, Corinna Vinschen wrote:
> > > On Apr 1 16:56, Corinna Vinschen wrote:
> > >> On Apr 1 16:28, Michael Haubenwallner wrote:
> > >>> On 3/28/19 9:30 PM, Corinna Vinschen
On 4/8/19 7:09 PM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> Well... once installed, a dll may get in use quickly, because I can not
>> require
>> to shut down all Cygwin processes. So I need to rebase and register the dll
>> in
>> some staging directory before it is installed into
Michael Haubenwallner writes:
> Well... once installed, a dll may get in use quickly, because I can not
> require
> to shut down all Cygwin processes. So I need to rebase and register the dll
> in
> some staging directory before it is installed into it's final directory, hence
> I'm about to
On 2019-04-08 06:38, Michael Haubenwallner wrote:
> On 4/3/19 2:26 PM, Corinna Vinschen wrote:
>> On Apr 3 12:38, Michael Haubenwallner wrote:
>>> 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
On 4/3/19 2:28 PM, Achim Gratz wrote:
> 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.
>
On 4/3/19 2:26 PM, Corinna Vinschen wrote:
> On Apr 3 12:38, Michael Haubenwallner wrote:
>> 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
E. Madison Bray writes:
> However, I can see how this could be inconvenient for some Python
> builds where you might have something within the setup.py script
> (which, when building Python extension modules, is still usually used)
> like (in pseudo-code):
>
> run_build_ext_command()
>
On Thu, Mar 28, 2019 at 6:50 PM Achim Gratz wrote:
>
> Michael Haubenwallner writes:
> > It will not help for conflicts between dlls within a single package while
> > this
> > package is built. I'm thinking of python modules built within the python
> > package
> > itself, where the just built
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,
On Apr 3 12:38, Michael Haubenwallner wrote:
> 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(!)
>
On Apr 3 11:18, Michael Haubenwallner wrote:
> On 4/1/19 5:56 PM, Corinna Vinschen wrote:
> > On Apr 1 16:56, Corinna Vinschen wrote:
> >> On Apr 1 16:28, Michael Haubenwallner wrote:
> >>> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> can you please collect the base addresses of all DLLs
Hi Brian, hi Achim,
Thanks a lot for your input!
On 3/30/19 5:09 PM, Brian Inglis wrote:
> On 2019-03-30 02:22, Achim Gratz wrote:
>> Brian Inglis writes:
>>> 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
On 4/1/19 5:56 PM, Corinna Vinschen wrote:
> On Apr 1 16:56, Corinna Vinschen wrote:
>> On Apr 1 16:28, Michael Haubenwallner wrote:
>>> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
can you please collect the base addresses of all DLLs generated during
the build, plus their size and
On 2019-04-01 10:31, Michael Haubenwallner wrote:
>
> On 4/1/19 5:56 PM, Corinna Vinschen wrote:
>> On Apr 1 16:56, Corinna Vinschen wrote:
>>> On Apr 1 16:28, Michael Haubenwallner wrote:
On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> can you please collect the base addresses of all
On 4/1/19 5:56 PM, Corinna Vinschen wrote:
> On Apr 1 16:56, Corinna Vinschen wrote:
>> On Apr 1 16:28, Michael Haubenwallner wrote:
>>> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
can you please collect the base addresses of all DLLs generated during
the build, plus their size and
On Apr 1 16:56, Corinna Vinschen wrote:
> On Apr 1 16:28, Michael Haubenwallner wrote:
> > Hi Corinna,
> >
> > On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> > > can you please collect the base addresses of all DLLs generated during
> > > the build, plus their size and make a sorted list? It
On Apr 1 16:28, Michael Haubenwallner wrote:
> Hi Corinna,
>
> On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> > can you please collect the base addresses of all DLLs generated during
> > the build, plus their size and make a sorted list? It would be
> > interesting to know if the hash algorithm
Hi Corinna,
On 3/28/19 9:30 PM, Corinna Vinschen wrote:
> On Mar 28 12:48, Michael Haubenwallner wrote:
>> On 3/28/19 10:58 AM, Corinna Vinschen wrote:
>>> On Mar 28 10:17, Michael Haubenwallner wrote:
As it is not some other dll being loaded at the colliding adress: any
idea how to
On 2019-03-30 02:22, Achim Gratz wrote:
> Brian Inglis writes:
>> 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
Brian Inglis writes:
> 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
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
Brian Inglis writes:
> 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
On 2019-03-29 01:15, Achim Gratz wrote:
> 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
>
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
On 2019-03-28 10:48, Michael Haubenwallner wrote:
> On 3/28/19 4:19 PM, Brian Inglis wrote:
>> On 2019-03-28 08:59, Michael Haubenwallner wrote:
>>> On 3/27/19 8:59 PM, Achim Gratz wrote:
Michael Haubenwallner writes:
> As far as I understand, rebasing is about touching already installed
Michael,
On Mar 28 12:48, Michael Haubenwallner wrote:
> On 3/28/19 10:58 AM, Corinna Vinschen wrote:
> > On Mar 28 10:17, Michael Haubenwallner wrote:
> >> As it is not some other dll being loaded at the colliding adress: any
> >> idea how to find out _what_ is allocated there (in the forked
Michael Haubenwallner writes:
> It will not help for conflicts between dlls within a single package while this
> package is built. I'm thinking of python modules built within the python
> package
> itself, where the just built modules are used within the very build process.
> Not
> sure if
On 3/28/19 4:19 PM, Brian Inglis wrote:
> On 2019-03-28 08:59, Michael Haubenwallner wrote:
>> On 3/27/19 8:59 PM, Achim Gratz wrote:
>>> Michael Haubenwallner writes:
As far as I understand, rebasing is about touching already installed
dlls as well, which would require to restart all
On Mar 28 16:02, Michael Haubenwallner wrote:
> On 3/28/19 10:15 AM, Corinna Vinschen wrote:
> > On Mar 28 09:34, Michael Haubenwallner wrote:
> >> Hi Corinna,
> >>
> >> On 3/27/19 10:16 AM, Corinna Vinschen wrote:
> >>> On Mar 27 09:26, Michael Haubenwallner wrote:
> On 3/26/19 7:28 PM,
On 2019-03-28 08:59, Michael Haubenwallner wrote:
> Hi Achim,
>
> On 3/27/19 8:59 PM, Achim Gratz wrote:
>> Michael Haubenwallner writes:
>>> As far as I understand, rebasing is about touching already installed
>>> dlls as well, which would require to restart all Cygwin processes.
>>> As the
On 3/28/19 10:15 AM, Corinna Vinschen wrote:
> On Mar 28 09:34, Michael Haubenwallner wrote:
>> Hi Corinna,
>>
>> On 3/27/19 10:16 AM, Corinna Vinschen wrote:
>>> On Mar 27 09:26, Michael Haubenwallner wrote:
On 3/26/19 7:28 PM, Corinna Vinschen wrote:
>>> Wait, let me understand what's going
Hi Achim,
On 3/27/19 8:59 PM, Achim Gratz wrote:
> Michael Haubenwallner writes:
>> As far as I understand, rebasing is about touching already installed
>> dlls as well, which would require to restart all Cygwin processes.
>> As the problem is about some dll built during a larger build job,
>>
On Mar 28 12:48, Michael Haubenwallner wrote:
> On 3/28/19 10:58 AM, Corinna Vinschen wrote:
> > On Mar 28 10:17, Michael Haubenwallner wrote:
> >> As it is not some other dll being loaded at the colliding adress: any
> >> idea how to find out _what_ is allocated there (in the forked child),
> >>
On 3/28/19 10:58 AM, Corinna Vinschen wrote:
> On Mar 28 10:17, Michael Haubenwallner wrote:
>> As it is not some other dll being loaded at the colliding adress: any
>> idea how to find out _what_ is allocated there (in the forked child),
>> to find out whether we can reserve these areas even more
On Mar 28 10:17, Michael Haubenwallner wrote:
> As it is not some other dll being loaded at the colliding adress: any
> idea how to find out _what_ is allocated there (in the forked child),
> to find out whether we can reserve these areas even more early?
I'm not sure what addresses you're
On 3/28/19 9:34 AM, Michael Haubenwallner wrote:
> On 3/27/19 10:16 AM, Corinna Vinschen wrote:
>> On Mar 27 09:26, Michael Haubenwallner wrote:
>>> On 3/26/19 7:28 PM, Corinna Vinschen wrote:
On Mar 26 19:25, Corinna Vinschen wrote:
> On Mar 26 18:10, Michael Haubenwallner wrote:
Hi Corinna,
On 3/27/19 10:16 AM, Corinna Vinschen wrote:
> On Mar 27 09:26, Michael Haubenwallner wrote:
>> On 3/26/19 7:28 PM, Corinna Vinschen wrote:
>>> On Mar 26 19:25, Corinna Vinschen wrote:
On Mar 26 18:10, Michael Haubenwallner wrote:
> Hi Corinna,
>
> as I do still
Michael Haubenwallner writes:
> As far as I understand, rebasing is about touching already installed
> dlls as well, which would require to restart all Cygwin processes.
> As the problem is about some dll built during a larger build job,
> this is not something that feels useful to me.
That's
Hi Michael,
On Mar 27 09:26, Michael Haubenwallner wrote:
> Hi Corinna,
>
> On 3/26/19 7:28 PM, Corinna Vinschen wrote:
> > On Mar 26 19:25, Corinna Vinschen wrote:
> >> Hi Michael,
> >>
> >>
> >> Redirected to cygwin-patches...
> >>
> >>
> >> On Mar 26 18:10, Michael Haubenwallner wrote:
> >>>
Hi Corinna,
On 3/26/19 7:28 PM, Corinna Vinschen wrote:
> On Mar 26 19:25, Corinna Vinschen wrote:
>> Hi Michael,
>>
>>
>> Redirected to cygwin-patches...
>>
>>
>> On Mar 26 18:10, Michael Haubenwallner wrote:
>>> Hi Corinna,
>>>
>>> as I do still encounter fork errors (address space needed by
On Mar 26 19:25, Corinna Vinschen wrote:
> Hi Michael,
>
>
> Redirected to cygwin-patches...
>
>
> On Mar 26 18:10, Michael Haubenwallner wrote:
> > Hi Corinna,
> >
> > as I do still encounter fork errors (address space needed by is
> > already occupied) with dynamically loaded dlls (but
Hi Michael,
Redirected to cygwin-patches...
On Mar 26 18:10, Michael Haubenwallner wrote:
> Hi Corinna,
>
> as I do still encounter fork errors (address space needed by is
> already occupied) with dynamically loaded dlls (but unrelated to
> replaced dlls), one of them repeating even upon
46 matches
Mail list logo
