This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Strange errors running gcc tests on Cygwin

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



Problem reports:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]