Strange errors running gcc tests on Cygwin
Marco Atzeri
marco.atzeri@gmail.com
Mon Mar 13 17:25:00 GMT 2017
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
More information about the Cygwin
mailing list