This is the mail archive of the
mailing list for the Cygwin project.
Re: Fwd: Cygwin64: mkshortcut - Segmentation fault
- From: Charles Wilson <cygwin at cwilson dot fastmail dot fm>
- To: The Cygwin Mailing List <cygwin at cygwin dot com>
- Date: Mon, 10 Jun 2013 12:18:20 -0400
- Subject: Re: Fwd: Cygwin64: mkshortcut - Segmentation fault
- References: <CAHYyVz4oA-66v2Ukb+yiQMQL2qj2+jJ9fQY+hxhhwqtvc8F6vg at mail dot gmail dot com> <CAHYyVz6MLyiLrRRzA==m3HhCXmLVC1_UaALe3DsmTHAAiEdK7A at mail dot gmail dot com> <CAHYyVz6X5LcBhU4PZAeZMLy9P=pMWhHt0ejmQiviy11ow77dKg at mail dot gmail dot com> <CAHYyVz4J23kMrKZjJyrWF8tbx+Lj7-weez2Ux9Rd5vBnWerkkw at mail dot gmail dot com>
On 6/7/2013 12:18 PM, Vasiliy wrote:
I vote for this issue be double-checked:
1) there is only one (the latest one provided by setup) cygwin1.dll in my $PATH:
$ which cygwin1.dll
$ uname -a
CYGWIN_NT-6.1 Luminous 1.7.20(0.266/5/3) 2013-06-06 17:36 x86_64 Cygwin
Well, so far so good...
and rebaseall is not (has not been) designed for a 64bit installation
(both system and Cygwin are 64-bit)
...but as Corinna pointed out, both rebase.exe and rebaseall fully
support 64bit installations.
Now, it is true that on x86_64, rebaseall still defaults to a starting
address of 0x70000000, and should probably autodetect 64ness and use
instead the agreed-upon base address starting location (0x1,7000000 IIRC?)
However, it appears that rebaseall defaults to 0x70000000 regardless (or
whatever is already in the /etc/rebase.db.* file). Since the first
version of that db file is created by setup.exe running the _autorebase
postinstall script on initial install -- but that just invokes "dash
/bin/rebaseall -p", this means that the base addr on x86_64 is typically
going to be 0x70000000 which is probably sub-optimal.
You might try to manually rebaseall (with a new -b base address above
4G). When you launch rebaseall with an explicit '-b 0x....' option, then
all DLLs will be rebased to the new area, and the database recreated
from scratch. That might help, in your case.
2) provided in (the latest by setup) cygutils 1.4.12-2 mkshortcut.exe
was, in fact, compled with a mismatched version of cygwin1.dll
I don't understand what you mean here. The internal version number
(1.7.20-1 or whatever) is not recorded in the .exe file format; only the
file name "cygwin1.dll". So there is no way you could tell whether a
"mismatch" happened at compile time. Further, since all newer
cygwin1.dll's are backwards compatible with older ones, so long as your
cygwin1.dll is the same version, or a newer version, than the one I used
to build, it should work fine [*]
[*] provided all cygwin1.dll's we're discussing have the same bitness --
64bit, in this case:
$ file mkshortcut.exe
mkshortcut.exe: PE32+ executable (console) x86-64, for MS Windows
The error you see is a runtime mismatch error. Basically, fork()/exec()
is used by bash.exe to launch mkshortcut.exe. It first forks() itself
-- so you have a parent bash and a child bash -- and the memory layout
of the child bash (stack location, DLL load addresses, version number of
the cygwin DLL loaded in each instance, etc) must be exactly the same as
that of the parent bash. Cygwin's fork() jumps thru a lot of hoops to
try and ensure that this is the case, but sometimes it fails. Then,
mkshortcut.exe itself is exec()ed. Somewhere in this process, the
address of the cygheap is checked to make sure it is the same as in the
parent (bash), and that check is failing.
The code in mkshortcut.c itself has nothing to do with where cygwin's
heap ends up during this fork/exec process. Hence, this is a system
3) cygport all from the cygutils 1.4.12-2 sources installs, indeed,
libcygicons.dll.a, as opposed to the correct spelling: libicons.dll.a
Please, indeed, take a look at the content you've just attached:
Description: Text document
and check the content of "libcygicons.la" (should be "libicons.la" as well)
You're assuming this is a bug. It isn't. Yes, typically cygwin DLLs
follow a naming pattern like:
cygfoo-N.dll <-> libfoo.dll.a <-> libfoo.a
so that -lfoo will link to the correct implib/static lib "just like on
linux" regardless of the funky naming convention used on cygwin for DLLs.
However, the cygwin icon library is cygwin specific; there is no "linux
version" that people link against, and whose name we must imitate.
(Besides, I really don't want to be -licon, because there might be a
REAL icon support library out there called "libicon"). So, as we're
cygwin-specific, I made a deliberate choice that the import library for
the DLL (and the header) would be "-lcygicon" (/usr/include/cygicon.h).
Now, that means "cygcygicon-0.dll" would be the DLL name if we
followed the typical pattern -- but that looks stupid, so the DLL is
named "cygicon-0.dll" instead.
Why are you trying to link to the cygicon dll anyway? It doesn't provide
anything except a few icons as resource objects...frankly, I probably
shouldn't even include the header/implib in the package at all.
Problem reports: http://cygwin.com/problems.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple