This is the mail archive of the
cygwin-apps
mailing list for the Cygwin project.
Re: perl-5.14.4
- From: Achim Gratz <Stromeko at nexgo dot de>
- To: cygwin-apps at cygwin dot com
- Date: Mon, 16 Feb 2015 16:42:47 +0100
- Subject: Re: perl-5.14.4
- Authentication-results: sourceware.org; auth=none
- References: <87bnkwci40 dot fsf at Rainer dot invalid> <20150215103230 dot GN7225 at calimero dot vinschen dot de> <87bnkvxqi6 dot fsf at Rainer dot invalid> <20150215143117 dot GT7225 at calimero dot vinschen dot de> <87sie7vvfr dot fsf at Rainer dot invalid> <20150216091720 dot GW7225 at calimero dot vinschen dot de> <871tlq194r dot fsf at Rainer dot invalid> <20150216102535 dot GD7225 at calimero dot vinschen dot de> <20150216122528 dot GA8493 at calimero dot vinschen dot de> <87k2ziylnz dot fsf at Rainer dot invalid> <20150216153057 dot GH8493 at calimero dot vinschen dot de>
Corinna Vinschen writes:
> Uh oh, the debug information is either broken (which is unlikely) or GDB
> doesn't use it anymore due to the CRC mismatch. Maybe the same CRC
> mismatch breaks objcopy in cygport, given that both are based on the
> same BFD code?
Maybe, but none of the tools ever complained about the CRC (I remember
that GDB checks it though). A CRC should be a fixable thing, though.
> For the time being, is it really required to rebase the DLLs for testing
> before the debug information is split off? If you could do the rebase
> and test cycle after splitting off the debug info, the problem should be
> neglectable.
For the moment I've changed the patch to EUMM to check if it's run from
cygport and not rebase the just produced DLL in that case. I only need
to remember to package the module before testing instead of the other
way around (and do a manual rebase before testing, but that isn't
difficult). So, I have a workaround.
Regards,
Achim.
--
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+
Wavetables for the Terratec KOMPLEXER:
http://Synth.Stromeko.net/Downloads.html#KomplexerWaves