DomainKey-Signature: a=rsa-sha1; c=nofws; d=sourceware.org; h=list-id
	:list-unsubscribe:list-subscribe:list-archive:list-post
	:list-help:sender:subject:to:references:from:message-id:date
	:mime-version:in-reply-to:content-type
	:content-transfer-encoding; q=dns; s=default; b=QNdwPyqDdmtIoU1r
	W/aL7YUqDqSlrdQhZNNIG2BBE0+m68CUKL0o3ihkDOabNiHIvhvZN4qgHS7MGIuL
	0EeG4BHLsKN875gNgP5UrCKoypCZIks+TjCGgNmMlCgED0kGpYADa3NOLdV7aKj5
	0rJ/DeKbwdSysyXe5oYNt0Ck+Wk=
Mailing-List: contact cygwin-help@cygwin.com; run by ezmlm
Sender: cygwin-owner@cygwin.com
Mail-Followup-To: cygwin@cygwin.com
Subject: Re: Strange errors running gcc tests on Cygwin
To: cygwin@cygwin.com
References: <8fa02a72-e684-2ead-eacb-a5347d7594ae@pobox.com> <82b31abc-7b7f-8f13-fc22-521c9ef84abf@pobox.com> <8bda181f-f0bc-b0dc-2d2d-1bb17031ccee@gmail.com> <b6c0f704-1f04-63ea-8220-ee30d623a9d6@pobox.com> <583230d9-f45c-aaa0-ed77-5c50863406f5@gmail.com> <9b872914-d9cf-378e-6eec-96c175a61ffe@pobox.com> <ab35a49e-93e3-4384-bf81-3e8ac99b7194@gmail.com> <7372df4f-c55d-f9a3-325d-3f8800d67d98@pobox.com> <aab8c02e-2fe7-8ebf-5f3b-126e0ea0a745@gmail.com> <a7aca745-bbf2-a356-704a-4956ae6a28b3@pobox.com> <937197c6-f0cd-a7a0-a12f-d3f943ba2c1d@SystematicSw.ab.ca> <affe4ca0-4677-6eb9-1d7d-94a129adc30c@pobox.com> <53efff58-2f84-123a-95a4-a7c426c003ce@SystematicSw.ab.ca> <87pohp6jvk.fsf@Rainer.invalid> <9b62f080-94f1-74d9-36ec-869e9490db2f@pobox.com>
From: Marco Atzeri <marco.atzeri@gmail.com>
Message-ID: <d9f1e1f0-cdad-7f14-d873-1c63f63645c9@gmail.com>
Date: Mon, 13 Mar 2017 18:25:31 +0100
User-Agent: Mozilla/5.0 (Windows NT 6.1; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.8.0
MIME-Version: 1.0
In-Reply-To: <9b62f080-94f1-74d9-36ec-869e9490db2f@pobox.com>
Content-Type: text/plain; charset=windows-1252; format=flowed
Content-Transfer-Encoding: 7bit

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