On Mar 14 21:30, Achim Gratz wrote:
Corinna Vinschen writes:
So the binutils problem is fixed upstream, we're just waiting for GDB
to catch up. Another collegue of mine will have a look as soon as time
permits.
Here's one for testing, Achim:
Corinna Vinschen writes:
So the binutils problem is fixed upstream, we're just waiting for GDB
to catch up. Another collegue of mine will have a look as soon as time
permits.
Here's one for testing, Achim:
https://cygwin.com/ml/cygwin-announce/2015-03/msg00020.html
That works correctly
On Mar 5 14:20, Corinna Vinschen wrote:
On Feb 16 16:42, Achim Gratz wrote:
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
On Feb 16 16:42, Achim Gratz wrote:
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?
Corinna Vinschen writes:
Hang on. Perhaps I just missed the crucial point here, but it just
occured to me that the DLLs are rebased as part of the autorebase
script.
Yes, they routinely are. Even on 64bit when they have been
auto-image-based originally.
So what you have is a DLL which gets
On Feb 16 15:29, Achim Gratz wrote:
As long as the debug information is made unuseable by doing the rebase,
I don't see why we should start rebasing the debug files. AFAIK, if we
keep them non-rebased then everything works fine or we'd have heard
complaints by now.
Ok, I took the opportunity
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
Corinna Vinschen writes:
Back to the drawing board… The section names in rebase are completely
different,
completely different? -v, please?
I gave up in disgust… anyway, instead of the .debug_* section names,
rebase finds something like /19. I can't find a way to have objdump
use the same
On Feb 16 10:46, Achim Gratz wrote:
Corinna Vinschen writes:
Back to the drawing board… The section names in rebase are completely
different,
completely different? -v, please?
I gave up in disgust… anyway, instead of the .debug_* section names,
rebase finds something like /19. I
Corinna Vinschen writes:
Where? rebase.c calls ReBaseImage64, which is
a) a Windows function in imagehlp.dll and
b) the function name of a function in the imagebase library, implemented
in rebaseimage.cc.
We're going path b. The core of imagebase's implementation of
ReBaseImage64 is
Corinna Vinschen writes:
We're going path b. The core of imagebase's implementation of
ReBaseImage64 is the call to LinkedObjectFile::performRelocation (line
123 in imagehelper/rebaseimage.cc), which in turn calls
Relocations::relocate in imagehelper/sections.cc. This function
performs the
On Feb 14 22:12, Achim Gratz wrote:
Achim Gratz writes:
Achim Gratz writes:
It turns out that doing so damages the debug information in the library
and then it can't be extracted later, so I'll have to skip this step
when building with cygport. I have no idea how and why this happens;
Achim Gratz writes:
It turns out that doing so damages the debug information in the library
and then it can't be extracted later, so I'll have to skip this step
when building with cygport. I have no idea how and why this happens;
the debug information is still there, but quite obviously it
Achim Gratz writes:
Achim Gratz writes:
It turns out that doing so damages the debug information in the library
and then it can't be extracted later, so I'll have to skip this step
when building with cygport. I have no idea how and why this happens;
the debug information is still there, but
David Stacey writes:
In readiness for the new perl test package, I've removed the test
version of perl-Text-CSV_XS that was linked against perl-5.18.2.
Thanks.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD adaptations for KORG EX-800 and
On 04/02/15 20:41, Achim Gratz wrote:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks.
In readiness for the new perl test package, I've removed the test
Achim Gratz writes:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks. Comments or suggestions?
While I have to do some more polishing of the cygport file and
Corinna Vinschen writes:
Would you mind to discuss your problem on the binutils mailing list?
Hopefully they know if there's a way which preserves the info so that
GDB doesn't fish in muddy waters.
Looking at the traffic of the past few weeks on that list (consisting
mostly of patches) I'm not
Corinna Vinschen writes:
I think it's important to keep the information in sync while building
the packages. A later rebase will break the connection between debug
symbols and runtime symbols as well, obviously.
Obviously? I have no indication that the debug information is damaged
once it's
On Feb 9 18:15, Achim Gratz wrote:
Corinna Vinschen writes:
I think it's important to keep the information in sync while building
the packages. A later rebase will break the connection between debug
symbols and runtime symbols as well, obviously.
Obviously? I have no indication that
On Feb 8 21:19, Achim Gratz wrote:
Achim Gratz writes:
Major progress: the cygport file starts to look sane. I've ripped out
the rebase changes in EU::MM and replaced them with an oblivious rebase,
which is the first time I could compile and test on 32bit without manual
intervention.
Achim Gratz writes:
Major progress: the cygport file starts to look sane. I've ripped out
the rebase changes in EU::MM and replaced them with an oblivious rebase,
which is the first time I could compile and test on 32bit without manual
intervention.
It turns out that doing so damages the
Achim Gratz writes:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks.
Major progress: the cygport file starts to look sane. I've ripped out
the rebase
Reini Urban writes:
Which SHA1? In the filenames of my patches?
Yes.
Probably old rebased away commits in rurban/perl.git branch cygwin,
sorry. Do you need them?
OK, that would explain things. I guess I can still find them by the
title...
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305
Reini Urban writes:
I expect them to be compatible, but I haven't tested that assumption yet.
You need to keep the useint* and usemymalloc settings from 5.14.2, then
it should be ok.
I'll check again but I don't think these have been altered for 5.14.4.
For the new 5.22 one you need to
On Feb 4 21:41, Achim Gratz wrote:
As I said in another thread I intend to skip directly to version 5.22
shortly after it becomes available in May (assuming the release schedule
is still holds).
While looking into some of the test fails on 5.18.4 I've moved back to
5.14.4 for comparison
BTW, does anyone know what repository the SHA1 in the patch files refer
to? One of them is in the official perl.git, but the rest I cannot find
in either rurban/perl.git nor the Cygports repository.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
SD
On 02/05/2015 05:13 PM, Achim Gratz wrote:
BTW, does anyone know what repository the SHA1 in the patch files refer
to? One of them is in the official perl.git, but the rest I cannot find
in either rurban/perl.git nor the Cygports repository.
Regards,
Achim.
Which SHA1? In the filenames of
On 02/04/2015 11:10 PM, Achim Gratz wrote:
David Stacey writes:
On 04/02/15 20:41, Achim Gratz wrote:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks.
David Stacey writes:
On 04/02/15 20:41, Achim Gratz wrote:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks. Comments or suggestions?
Do you expect the XS
As I said in another thread I intend to skip directly to version 5.22
shortly after it becomes available in May (assuming the release schedule
is still holds).
While looking into some of the test fails on 5.18.4 I've moved back to
5.14.4 for comparison (the fail turned out to be a combination of
On 04/02/15 20:41, Achim Gratz wrote:
If this sounds like a good idea to everybody else I'd remove the current
test package for 5.18.4 on 32bit and replace it with another test
package for 5.14.4, likely in about two weeks. Comments or suggestions?
Do you expect the XS modules built against
32 matches
Mail list logo
