---start-8---
--- cygwin-pkg-maint2015-05-09 00:24:18.0 +0200
+++ cygwin-pkg-maint.new2015-05-15 09:00:57.908064093 +0200
@@ -1216,7 +1216,7 @@
perl-Capture-TinyAchim Gratz/Ken Brown
perl-Carp
Yaakov Selkowitz writes:
Done.
Thank you.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Waldorf Blofeld:
http://Synth.Stromeko.net/Downloads.html#BlofeldUserWavetables
enough time to get to the dependency issue. Here's a
patch to fix that instance in cygport instead:
From f4113a1776d35dd39ee3a3aa114495635782a300 Mon Sep 17 00:00:00 2001
From: Achim Gratz strom...@stromeko.de
Date: Thu, 7 May 2015 22:08:18 +0200
Subject: [PATCH] lib/pkg_pkg.cygpart: Cygwin
Yaakov Selkowitz writes:
Thanks for noticing. I have added all of these, plus PHP and Ruby, to
setup.html.
The Video category is present in setup.ini, but missing from the list.
In setup.ini we currently have a mixture of Gnome and GNOME that
probably needs to be cleaned up and a lone OCaml
Ken Brown writes:
I'm wondering what your plans are for Perl 5.22, which I think is due
to be released in a couple weeks.
It'll probably be released end of May if all current blockers are
resolved by that time. If not, there's another 5.21 release and the
next release slot would be end of
Marco Atzeri writes:
Noted. But he patched autoconf and I patched cmake build.
Similar outcome, I just packed more utilities.
I will look at the zlib approach
In any case, since a bunch of Ports packages depend on that library,
you'll need to coordinate the move into Cygwin with Yaakov.
Marco Atzeri writes:
package already presents in the major disti's.
Yaakov has the previous version in ports, IIRC with a slightly different
packaging. You might want to check his cygport files and coordinate
with him.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda
Marco Atzeri writes:
I think you don't need any ITP for perl packages.
They are yours by default.
Then my !packages file should probably just say |perl\-.* at the
end. :-P
Do you need just an entry on
https://cygwin.com/cygwin-pkg-maint
Yes, thanks for doing that.
Regards,
Achim.
--
+[Q+
Achim Gratz writes:
I just realized that the 64bit distribution has a perl-Term-ReadKey
package that should have been obsoleted by perl-TermReadkey (sans the
hyphen). Can somebody please move the directory perl-Term-ReadKey into
perl-TermReadkey so I can create and install the obsoletion
Achim Gratz writes:
As requested here:
https://cygwin.com/ml/cygwin/2015-03/msg00525.html
The package provides a Perl binding to libcurl. It compiles cleanly on
x86 and with an implicit conversion overflow warning on x86_64 (looks
harmless) and tests cleanly on both architectures.
Ping
Corinna Vinschen writes:
There's another fix that should probably go into the scripts: The
service users should get SeDenyInteractiveLogonRight (they already have
SeDenyRemoteLogonRight). At least on my Windows7 Pro/64bit laptop the
accounts show up on the login screen otherwise.
Still,
Corinna Vinschen writes:
diff -up, please, it's much easier to read.
I just did a 'cvs diff'…
Yes, please apply.
Done.
That should work. IIUC Chuck was trying to check if every single right
has been granted, but the single call to editrights should do the same
thing, given that it
Corinna Vinschen writes:
I just did a 'cvs diff'…
$ echo diff -upN ~/.cvsrc
Great, done.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Waldorf MIDI Implementation additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs
Corinna Vinschen writes:
Windows 8.1 N with Bing gets reported as Windows 8.1 China (probably
renamed by MS after the fact).
Marketing wins this round apparently. All documentation I can find
still says country specific Windows variant and suggests China as
the variant name to go with that.
As requested here:
https://cygwin.com/ml/cygwin/2015-03/msg00525.html
The package provides a Perl binding to libcurl. It compiles cleanly on
x86 and with an implicit conversion overflow warning on x86_64 (looks
harmless) and tests cleanly on both architectures.
--8---cut
diff --git a/genini.pl b/genini.pl
index 973ecfd..f5b13ea 100755
--- a/genini.pl
+++ b/genini.pl
Thomas Wolff writes:
Hmm, so why does lftp ask me for a password?
Because you get bumped to the SSH connection only after you've connected
via password-less login. Create the following bookmark in lftp (yes,
that colon after cygwin is important) to avoid the password prompt:
cygwin
While csih is currently orphaned… :-( I still found these bugs:
Windows 8.1 N with Bing gets reported as Windows 8.1 China (probably
renamed by MS after the fact).
Also:
/usr/lib/csih/getAccountName.exe
/usr/lib/csih/getAccountName.exe: error while loading shared libraries:
Jon TURNEY writes:
On 28/03/2015 16:37, Achim Gratz wrote:
I have a few corrections and additions to the Perl distributions.
Applied.
Thank you very much.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Terratec KOMPLEXER:
http
-Tiny Achim Gratz
perl-CPAN-DistnameInfo Achim Gratz
perl-CPAN-Meta Achim Gratz
+perl-CPAN-Meta-Check Achim Gratz
perl-CPAN-Meta-Requirements Achim Gratz
perl-CPAN-Meta-YAML
I just realized that the 64bit distribution has a perl-Term-ReadKey
package that should have been obsoleted by perl-TermReadkey (sans the
hyphen). Can somebody please move the directory perl-Term-ReadKey into
perl-TermReadkey so I can create and install the obsoletion package?
Regards,
Achim.
Ken Brown writes:
So maybe you could dump a memory image maxima.mem and start it with a
script that calls 'clisp -M maxima.mem'.
I'm already doing that. :-)
I just took a look at the maxima package, and it seems that you
already use a script that does something like this in the absence of a
Ken Brown writes:
OK, that's good. I'd still like to get it to work, but I'm stumped at
the moment. I've tried tweaking the build in various ways, but I
can't get dumping of executables and dynamic modules to work
simultaneously.
The earlier approach of using a lisp DLL came the closest to
Ken Brown writes:
And indeed it does. I've still got a couple of things to clean up,
but I expect to upload a new clisp soon that no longer uses lisp.dll.
I hope that will solve the Maxima problem
It doesn't… Instead of lisp.dll it now requires lisp.exe to be in $PATH
and it produces an
Ken Brown writes:
Great. Thanks for testing. There's probably no reason for me to
upload a new clisp package right now (unless it would help you). But
I'll give you a heads up when I'm ready to do that.
I've now drilled to the bottom of what I had assumed were build/package
problems… it
Ken Brown writes:
How does the
lisp.exe in clisp relate to the one that would be in maxima-exec-clisp?
Achim will have to answer this one.
I don't really know either. The executable dump is provided by clisp
and you can name the resulting exe any which way you want. For maxima,
it's
Yaakov Selkowitz writes:
Looking at the executable it seems that it is a very small (~66 kiB)
stub that then proceeds to load the rest of the file after having
started the runtime. The memory image seems simply bolted on (as an
overlay?), and gets removed when the executable is stripped.
UPX
Ken Brown writes:
The clisp executables are not stripped because apparently there's a
disassemble command within clisp that doesn't work if the executables
are stripped. I don't actually know anything about this, but there
was a comment about that in the .cygport file that I inherited from
Ken Brown writes:
No it doesn't. Specifically, it doesn't like being stripped. I'll
RESTRICT that, let's hope it works now… Yup, it does.
Great. Thanks for testing. There's probably no reason for me to
upload a new clisp package right now (unless it would help you). But
I'll give you a
Ken Brown writes:
Just for testing purposes, I've built a new clisp with
/usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it
to my Cygwin repository:
http://sanibeltranquility.com/cygwin/
When you get a chance, please test it and see if it allows you to
avoid your
Achim Gratz writes:
Ken Brown writes:
Just for testing purposes, I've built a new clisp with
/usr/bin/cyglisp.dll and /usr/lib/liblisp.dll.a, and I've uploaded it
to my Cygwin repository:
http://sanibeltranquility.com/cygwin/
When you get a chance, please test it and see if it allows you
Achim Gratz writes:
The loading of memory images via clisp works, so I'll pull the
maxima-exec-clisp package until we get to the bottom of this.
Hmm. Scratch that, I think I got the maxima.exe (dumped image) to work.
Let's see if it survives installation.
No it doesn't. Specifically
Yaakov Selkowitz writes:
Is there an issue with stripping clisp executables?
Yes, with the executable dumps.
Is there a magic
number we can use to detect these automatically?
File identifies them as plain executables. CLisp knows which runtime
they were rpdocued from, so there must by some
Ken Brown writes:
My work was based on the tip of the upstream Mercurial repository,
which shows a version number of 2.49+ and is at revision 15623. So I
was thinking of using 2.49+hg15623 as the version number. Will upset
be happy with that? Or is there some other standard way of assigning
Ken Brown writes:
This sounds like a packaging error on my part. First of all, lisp.dll
is new with the latest clisp; it was part of my solution to the
dynamic loading problem. But from what you say, it sounds like I
should put it in /usr/bin. In fact, I should rename it to
cyglisp.dll,
Yaakov Selkowitz writes:
I believe these are all gone from Ports now, would you mind
double-checking?
Within the next week, yes. If I still find something, I'll let you
know.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Factory and User Sound
Ken Brown writes:
I thought this would all work fine because lisp.dll was in the same
directory as lisp.exe. And it does work fine for users of clisp. But
I didn't think about applications like Maxima that would need to link
against lisp.dll.
Maxima doesn't link against this library, it
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
Ken Brown writes:
Version numbers like the one Ken has proposed are becoming common in
Linux distributions, so we'd rather check that setup handles them
correctly. I think Jari already uses a bunch of them. The thing here
is that for all versioning schemes that use hashes you need to prepend
Yaakov Selkowitz writes:
If you are using a new build, the proper way to handle this would be to
bump RELEASE so that the distro package takes precedence; that way I
don't have to remove the package from Ports the very instant it lands in
the distro. The alternative would have been for me to
Yaakov Selkowitz writes:
Obviously we don't have %dist, but did you continue reading to the
Non-Numeric Version in Release section?
Yes. I can somewhat understand the rationale for putting this in the
release part, but I still like the openSUSE numbering better. The
central question is how
Achim Gratz writes:
As you wish. I still think his view is somewhat unique looking at the
version numbers in several Linux distros that provide packages
in-between-official-releases from several VCS. The only case that I
know where the VCS revision tag was used in the relase part
Yaakov Selkowitz writes:
https://fedoraproject.org/wiki/Packaging:NamingGuidelines#Package_Versioning
The way I read this, there is no suggestion of putting these extra
version parts in or after the %dist and/or build number, which is what
we use the release field for.
Regards,
Achim.
--
+[Q+
Ken Brown writes:
The current upstream Biber depends on File-Slurp. But it also
requires Perl 5.16 or later, so I won't be able to rebuild it and get
rid of the dependency on File-Slurp-Unicode until you update Perl in
May.
I've had a quick look. Of course they do use that one feature
Yaakov Selkowitz writes:
This is not a distribution anymore but became a bundle consiting of some
40 distributions, of which 8 don't build. Yaakov, can you please
obsolete it as nothing depends on it anyway. I'll ITP the Win32-*
packages as I get them to compile later on.
Obsolete it how?
Jon TURNEY writes:
Sure, no problem.
Thanks.
perl-Win32-GUI is only used by the startup shell script as a way to
retrieve GetSystemMetrics(SM_C(X|Y)VIRTUALSCREEN). I'm sure that can
be re-written another way.
So is that shell script just not working on x86_64 at all or is it
already
Jon TURNEY writes:
That's a result of me having built that file on openSUSE and openSUSE's
decision to default to POSIX format instead of GNU.
Hmm... maybe I should drop this patch, if the correct thing to do is
to build base-files with tar --format=gnu?
GNU's been threatening to make POSIX
Yaakov Selkowitz writes:
My work was based on the tip of the upstream Mercurial repository, which
shows a version number of 2.49+ and is at revision 15623. So I was
thinking of using 2.49+hg15623 as the version number. Will upset be
happy with that? Or is there some other standard way of
These four packages still install into the perl-5.10 directories on
32bit and need to be updated for perl-5.14.
I'll have to see what to do about the last two, because I'm pretty sure
that libwin32 doesn't build on 64bit. I may obsolete them (Win32-GUI is
required by XtoW, though, so that would
Yaakov Selkowitz writes:
On Thu, 2015-03-12 at 07:52 +0100, Achim Gratz wrote:
These four packages still install into the perl-5.10 directories on
32bit and need to be updated for perl-5.14.
The curr: release of perl-Locale-gettext is already built for 5.14, only
the prev: release is 5.10
Achim Gratz writes:
These four packages still install into the perl-5.10 directories on
32bit and need to be updated for perl-5.14.
I'll have to see what to do about the last two, because I'm pretty sure
that libwin32 doesn't build on 64bit.
This is not a distribution anymore but became
Achim Gratz writes:
Ken, would you still know if the Log-Log4Perl and Text-BibTeX tests were
clean previously? I'm getting what looks like an encoding problem from
Text-BibTeX and an offset in some file sizes(?) for Log-Log4Perl.
The offset seems to be a file mode check that doesn't work due
Corinna Vinschen writes:
On Mar 10 07:40, Achim Gratz wrote:
Achim Gratz writes:
The upload was extremely slow and I've had the connection drop a few
times. Does sourceware throttle connections? At the moment I can't
even get a directory listing via sshfs anymore, although lftp still
Corinna Vinschen writes:
I don't quite like the SUSE packaging with splitting out the language
packs, but the Fedora packaging, while using another strategy, isn't
really better, so that's ok.
…and Debian's and Arch's is even worse, IMHO. I wouldn't mind putting
the localization files back in
Achim Gratz writes:
Package is GTG With a change to the sdescs to allow a user at least
a bit of information in sdesc what the subpackages are doing.
Yeah, I'll fix that before release.
Does that look better to you?
maxima/setup.hint:sdesc: Maxima - Computer Algebra
Achim Gratz writes:
I can use lftp myself, I'll just have to creatre a bunch of aliases or
scripts, not sure yet how much I'm going to automate this.
Here's the set of lftp aliases to put into the lftp rc file.
--8---cut here---start-8---
alias cygdn lcd
Achim Gratz writes:
In order to get rid of perl_vendor on 32bit and update the packages to
the same versions on 64bit, I need to maintain the packages that were
formerly in perl_vendor plus another bunch that either are new
dependencies or are needed to build and test those packages.
Done
Achim Gratz writes:
The upload was extremely slow and I've had the connection drop a few
times. Does sourceware throttle connections? At the moment I can't
even get a directory listing via sshfs anymore, although lftp still
seems to cope just fine.
It seems I crossed a threshold
Achim Gratz writes:
Yaakov Selkowitz writes:
upset does indeed live up to its name in such a case, so we need to
rearrange directories on sourceware to match the new layout. I have
done so for perl-LWP, so please proceed.
Thank you very much. I'll do the upload later today.
The upload
Yaakov Selkowitz writes:
upset does indeed live up to its name in such a case, so we need to
rearrange directories on sourceware to match the new layout. I have
done so for perl-LWP, so please proceed.
Thank you very much. I'll do the upload later today.
Regards,
Achim.
--
+[Q+ Matrix-12
Marco Atzeri writes:
done
Thank you.
I'm ready for the upload, but there's one thing I don't know how to
handle correctly: I'm obsoleting perl-LWP in favor of perl-libwww-perl
(that's the actual distribution name and it is needed for automated
checking of dependencies via CPAN or MetaCPAN).
Marco Atzeri writes:
as perl-LWP is a 64bit package required by several other packages,
you can not just drop it.
I said I'm going to obsolete it, not drop it.
One possible solution is:
bump perl-LWP with a empty tar
put in setup.hint
category: _obsolete
requires: perl-libwww-perl
+0100
@@ -1181,7 +1181,7 @@
pcre Yaakov Selkowitz
pdftkDavid Rothenberger
perl Achim Gratz
-perl-Algorith-Diff Achim Gratz
+perl-Algorithm-Diff
Yaakov correctly pointed out the 32bit maxima I rememebered to be in
Cygwin was actually from ports, so here's the requisite ITP for maxima
to introduce it into Cygwin properly.
--8---cut here---start-8--- Maxima
Maxima is a computer algebra system comparable
In order to reap the fruits of Ken Brown's work on clisp and its
dependencies (which seem to have escaped the attention of the plush
hippo hordes so far) I'm proposing to resurrect maxima as a Cygwin
package. The packaging is modeled after openSUSE.
--8---cut
): Demote
overly talkative messages to LOG_BABBLE, so that they won't
clutter stdout by default.
---
diff --git a/ChangeLog b/ChangeLog
index 551cc94..1e97579 100644
--- a/ChangeLog
+++ b/ChangeLog
@@ -1,3 +1,9 @@
+2015-03-05 Achim Gratz strom...@nexgo.de
+
+ * package_meta.cc
Corinna Vinschen writes:
I'm proposing to resurrect maxima as a Cygwin
package. The packaging is modeled after openSUSE.
Resurrect? We had that already at one point?
Yes, but only on 32bit due to the missing clisp due to the missing
ffcall… it got removed during the recent cleanup of stale
Jon TURNEY writes:
It seems that base-files has an 'x' extended header for each file, apparently
to
store the mtime.
That's a result of me having built that file on openSUSE and openSUSE's
decision to default to POSIX format instead of GNU.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305
Corinna Vinschen writes:
Here's another one to reduce the logorrhea of setup unless otherwise
requested.
Yep, push it.
Done.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Wavetables for the Waldorf Blofeld:
Corinna Vinschen writes:
The problem here is how the Windows stack works. Stack reserve is the
initial size of the reserved virtual memory space used for the stack of
the main thread. By default that's 2 Megs.
There were in fact two threads at the point of the SEGV, one in the
kernel DLL
Corinna Vinschen writes:
The problem is, a stack overflow is correctly handled as SEGV from the
POSIX perspective.
But there should have been the right info available. If you run this
under strace, you get an exception 0xc0fd or 0xc228,
STATUS_STACK_OVERFLOW or
Corinna Vinschen writes:
On Mar 3 15:59, Warren Young wrote:
On Mar 3, 2015, at 1:25 PM, Corinna Vinschen
corinna-cygwin-rdbxbdvo6bxqt0dzr+a...@public.gmane.org wrote:
On Mar 3 13:23, Warren Young wrote:
On Mar 3, 2015, at 2:11 AM, Corinna Vinschen
Marco Atzeri writes:
I presume Corinna asked for this:
$ addr2line.exe -a 0001801C2F96 -e /usr/bin/cygwin1.dll
Then that's giving us this:
/mnt/share/maint (1964) addr2line.exe -a 0001801C2F96 -e
/usr/bin/cygwin1.dll
0x0001801c2f96
Corinna Vinschen writes:
DLL version? Did you call addr2line to see where 0001801C2F96 is
(hint: requires cygwin-debuginfo) in the DLL? This might give a clue.
/mnt/share/maint (1962) uname -a
CYGWIN_NT-6.3 Cygwin 1.7.35(0.286/5/3) 2015-02-27 17:19 x86_64 Cygwin
/mnt/share/maint (1963)
Yaakov Selkowitz writes:
Could you provide more detail here so I can better understand the
problems?
There are lots of Perl distributions that can optionally use some module
when available. I often have those modules installed since I need them
for testing or something else entirely and then
Achim Gratz writes:
While building maxima I've come across a consistent SEGV crash of python
on both architectures. To reproduce, change into the doc/info dirextory
and run
$ sh ./extract_categories.sh maxima
The crash seems to relate to the number of lines in the program (thare
are about
Corinna Vinschen writes:
Increasing the stack reserve size of the python executable to 0x40
on 32bit and 0x80 on 64bit avoids the SEGV. I'm not sure if this
indicates an error in Python itself or simply a too restricted
configuration.
Maybe it just needs a really big stack?
David Stacey writes:
I'm still trying to get to the bottom of this. The UTF16 test (the one
that works) uses std::wstring, but the UTF32 test (the one that
crashes) uses a custom string made with a 32-bit integer and
corresponding traits class. If the UTF16 test is switched from using
Corinna Vinschen writes:
Please apply.
I don't think I have commit access for that (and that should probably be
kept that way for the time being).
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Waldorf MIDI Implementation additional documentation:
Corinna Vinschen writes:
The crash occurs *during* envionment variable processing, but *in* the
application address space. Does the application come with its own
malloc?
Probably, I'll have to check. It comes with it's own GC at least.
For the time being, I declare Cygwin's innocence.
Corinna Vinschen writes:
Own malloc and own GC? WHat if it misses the fact that the C library
(aka Cygwin) uses malloc, too?
I didn't really follow through after that fail. I did successfully
compile ecl and it seems to work with maxima, but ecl doesn't produce
executables. But really,
While building maxima I've come across a consistent SEGV crash of python
on both architectures. To reproduce, change into the doc/info dirextory
and run
$ sh ./extract_categories.sh maxima
The crash seems to relate to the number of lines in the program (thare
are about 2 lines and it does
Yaakov Selkowitz
pdftkDavid Rothenberger
perl Achim Gratz
-perl-Archive-Zip Yaakov Selkowitz
+perl-Algorith-Diff Achim Gratz
+perl-Archive-Zip
X-Git-Url:
http://repo.or.cz/w/cygport/rpm-style.git/commitdiff_plain/f238f9c846690ba0d3ba259dee6c301f1ff98648
pkg_info.cygport: correct search order for Perl dependencies
* lib/pkg_info.cygpart: Correct search order for Perl dependencies and
suppress auto-generation of Perl dependencies when
David Billinghurst writes:
I have built and tested maxima-5.43.1 with your clisp release on
cygwin64. Perfect test results.I find clisp slow for routine
work, but it is good to have it available.
I've built maxima-5.35.1 for both architectures. The makefiles don't
really want to
Achim Gratz writes:
The include hiccup out of the way things start to compile, but then
raw_pre_gcl segfaults.
Something for Corinna it seems… :-)
--8---cut here---start-8---
...gcl.x86/build/unixport (1673) strace
/mnt/share/maint/gcl.x86/build/unixport
I've cygported groff and want to maintain it. The current packaging did
not have some files with perl dependencies and the X11 tools were not
present. I don't mind dropping these from the distribution if everybody
thinks they are useless, but for now they are in an additional
sub-package
Corinna Vinschen writes:
On Feb 16 16:03, Achim Gratz wrote:
Corinna Vinschen writes:
I'm more interested in seeing if you can push and how the log message on
cygwin-apss-cvs looks like since I made some script changes...
Pushed.
Thanks. The commit message on cygwin-apps-cvs looks
Corinna Vinschen writes:
Sounds good to me. However, I don't understand it. I expected that it
writens the changelog entry automatically to the ChangeLog file, but it
doesn't. I just tested it in a local branch. I added this:
[merge merge-changelog]
name = GNU-style ChangeLog
Corinna Vinschen writes:
I still carry the README patch below locally since it was not accepted
Please apply. That should work, given the file perms on sware...
Done, with the changes that have accumulated since the original patch.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron
Corinna Vinschen writes:
Uh, what? You need to keep a blank line between the (brief) commit
message and any ChangeLog lines,
That's a rule? In theory the subject line is totally useless for a
ChangeLog entry, but if that's required, ok, fine.
Not so much a rule, but rather a consequence of
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
Corinna Vinschen writes:
I'm more interested in seeing if you can push and how the log message on
cygwin-apss-cvs looks like since I made some script changes...
Pushed.
Regards,
Achim.
--
+[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]+
Samples for the Waldorf Blofeld:
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:
I inspected your code and played around with git-tag and git-describe
so it's ok.
THanks,
I'm more interested in seeing if you can push and how the log message on
cygwin-apss-cvs looks like since I made some script changes...
Later today…
Regards,
Achim.
--
+[Q+
Corinna Vinschen writes:
I saw some .gitattributes file mentioning exactly this ChangeLog merging
in the binutils-gdb repo and copied it over so it's part of our repo as
well.
That deals with the problem of merging log files. If you do keep a
manual log just about any merge would create a
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
Corinna Vinschen writes:
On Feb 14 20:06, Achim Gratz wrote:
First patch to follow the usual convention of using annotated release
tags for determining the version (tag 4782666e90 as release_2.869 for
testing).
I'm at a loss. Right now, after my last checkin, we're simply continuing
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
901 - 1000 of 1385 matches
Mail list logo
