Re: Strange errors running gcc tests on Cygwin

[Marco Atzeri <marco.atzeri@gmail.com>]

On 13/03/2017 17:39, Daniel Santos wrote:
> On 03/10/2017 12:56 PM, Achim Gratz wrote:
>> Brian Inglis writes:
>>> Ensure that all Cygwin dlls including anything you build are included
>>> in every rebase, and do an incremental rebase after every build.
>> Don't do this, it's not what incremental rebase is for.  I've
>> specifically implemented the "ephemeral" option to rebase to temporarily
>> deal with DLL in staging directories without polluting the global rebase
>> map.  The rebase map is still used if you specify that in order to work
>> around the address space used by the installation, but the newl rebased
>> libraries don't get recorded there.  Since that rebase is throw-away you
>> have to specify all the ephemeral DLL that can potentially collide in
>> each invocation of rebase.  That's still easier than doing a full rebase
>> once you're done building.
>
> Well this is interesting.  What happens if there is a collision? Will a
> detailed error message exist anywhere (syslogs, NT's event log, etc.)?
>
> So when I run gcc's bootstrap, I'm building dlls that sit (temporarily)
> in the build directory.  If I do not explicitly rebase these, can I end
> up with collisions if I try to use them?

The risk of collision is very low on 64 bit.
It is higher on 32 bit but as gcc don't depend on other libraries,
I don't expect that to happen.

If happens you can rebase in tree before running the tests,
providing the list of new dll to rebase.
I used it when I had problem on testing  Octave; but Octave
dlls with debugging symbols are huge and pull tons of
other dlls so the collision was almost sure on 32bit

> Thanks,
> Daniel

Regards
Marco

--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple