Here is a reworked patch series, this time as single patches in separate
mail. For the sake of completeness I'm sending all patches again. They
should all apply seperately if necessary. Some comments below.
[PATCH 1/4] README: document some recent changes in the build environment
I've
From 991a4e1455b73abfffef6651583edae0079c077f Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 25 Jan 2013 13:23:10 +0100
Subject: [PATCH 1/4] README: document some recent changes in the build environment
* setup/README (HOW TO BUILD): Cross compiler package is now named
mingw-gcc-g++,
From a8ffe947b5e64b9f29cecc8c404d0d508ab7be67 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 18 Jan 2013 14:33:29 +0100
Subject: [PATCH 2/4] Makefile: additional targets strip and upx
* setup/Makefile.am: Provide new targets strip and upx to remove
debugging symbols and compress the
From a246270621b2b4fbd476aa386fc217ed14f3fe10 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 25 Jan 2013 12:12:41 +0100
Subject: [PATCH 3/4] Allow delete and reinstall from CLI, re-implement install from CLI
* choose.cc: Add new CLI option -g/--upgrade-also, considers all
installed
From ead437489d0873f983103cef24b708af18a9a391 Mon Sep 17 00:00:00 2001
From: Achim Gratz
Date: Fri, 18 Jan 2013 17:05:52 +0100
Subject: [PATCH 4/4] Allow a different basename (instead of setup)
* setup/ini.h: Modify macro definition to pick up name from external
variable SetupBaseName instead
On 1/26/2013 1:08 AM, szgyg wrote:
On 1/24/2013 1:29 PM, Corinna Vinschen wrote:
On Jan 24 11:41, marco atzeri wrote:
On 1/24/2013 10:39 AM, Corinna Vinschen wrote:
I debugged this last week, and I don't see how this could be a rebase
bug. [...] To me this indicates a bug in objcopy.
Strip
wget --recursive --no-host-directories --cut-dirs=3 \
http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6+b2-2-src.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/bzr/bzr-2.6+b2-2.tar.bz2 \
http://cante.net/~jaalto/tmp/cygwin/bzr/setup.hint
Jari
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-64bit-branch
Changes by: kti...@sourceware.org 2013-01-25 14:44:41
Modified files:
winsup/cygwin : autoload.cc
Log message:
* autoload.cc (LoadDLLfuncEx3): Adjust assembler for x64
to avoid
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-64bit-branch
Changes by: kti...@sourceware.org 2013-01-25 15:05:18
Modified files:
winsup/cygwin : ChangeLog.64bit
Log message:
Missed commit. sorry
Patches:
CVSROOT:/cvs/src
Module name:src
Branch: cygwin-64bit-branch
Changes by: cori...@sourceware.org 2013-01-25 17:07:43
Modified files:
winsup/cygwin : ChangeLog.64bit cygwin.sc.in cygwin64.din
gendef
Log message:
* cygwin.sc.in:
These two packages should exist according to the package list, but their
corresponding directories are empty. I have the 4.5.3 versions installed, but
the rest of Qt is already at 4.8.4. Could someone please check whether the
directories should be deleted (there doesn't seem to be any package
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
The file header has been changed already. If you call the
same rebase, it will try to rebase the file to the same new
address. If current file base address == requested file base
2013/1/25 marco atzeri marco.atz...@gmail.com:
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
The file header has been changed already. If you call the
same rebase, it will try to rebase the file to the same new
address. If
Well, here are my 2-cents about that issue. In general it is a flaw
to have an base-relocation in debug-section, as this means such debug
information can't be moved into a separate debug-file anymore. A
debug-file has no relocation-information.
Nevertheless it would be good, if objcopy gets
On Jan 25 14:19, Kai Tietz wrote:
2013/1/25 marco atzeri marco.atz...@gmail.com:
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
The file header has been changed already. If you call the
same rebase, it will try to rebase the
I have downloaded and installed cygwin on one machine and would like to install
it on a second machine which is non-networked and for which I don't have
administrator rights. However, I am running into some issues which are described
below.
I have created a Mapped Network Drive (X:) for the
On 1/25/2013 4:00 PM, Corinna Vinschen wrote:
On Jan 25 14:19, Kai Tietz wrote:
2013/1/25 marco atzeri marco.atz...@gmail.com:
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
The file header has been changed already. If you call
Hi,
anyone can reproduce this dvipdfmx bug?
i've already fixed this by replacing rungs to gs in
/usr/share/texmf/dvipdfmx/dvipdfmx.cfg like this:
--- /usr/share/texmf/dvipdfmx/dvipdfmx.cfg.orig 2013-01-26
02:21:56.31250 +0900
+++ /usr/share/texmf/dvipdfmx/dvipdfmx.cfg 2013-01-26
Hi - I'm not sure if this will help your problem, but in the past I
have had to install Cygwin to a number of non-networked machines. For
me, the easiest way was to use setup.exe with the option of save
files but don't install. You can copy the saved folder and setup.exe
onto a CD and take it to
I originally thought this problem was due to installing as non-admin, but
further investigation has led me to conclude the problem is due to
installing to a Mapped Network Drive (or even a drive other than C:).
I am trying to install cygwin on a non-networked computer as a non-admin
user. But for
On 1/25/2013 12:30 PM, KIMURA Masaru wrote:
Hi,
anyone can reproduce this dvipdfmx bug?
i've already fixed this by replacing rungs to gs in
/usr/share/texmf/dvipdfmx/dvipdfmx.cfg like this:
[...]
or, including rungs properly is the way to fix?
Yes, /usr/bin/rungs should be part of
On 1/25/2013 8:19 PM, Alan wrote:
I originally thought this problem was due to installing as non-admin, but
further investigation has led me to conclude the problem is due to
installing to a Mapped Network Drive (or even a drive other than C:).
I am trying to install cygwin on a non-networked
On Fri, Jan 25, 2013 at 8:11 AM, marco atzeri wrote:
On 1/25/2013 4:00 PM, Corinna Vinschen wrote:
On Jan 25 14:19, Kai Tietz wrote:
2013/1/25 marco atzeri marco.atz...@gmail.com:
On 1/24/2013 11:00 AM, Corinna Vinschen wrote:
I already explained why: The SEGV happens during relocation.
On 1/26/2013 7:32 AM, Reini Urban wrote:
rebase is not to blame. I agree ;-)
Someone else is incorrectly managing the reloc table,
and also objcopy seems innocent ...
Postgresql dll's are built in this way:
My strong guess is dllwrap.
No other packages uses the ancient dllwrap anymore.
I
24 matches
Mail list logo
