This is the mail archive of the cygwin mailing list for the Cygwin project.

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Fwd: Cygwin64: mkshortcut - Segmentation fault

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 issue...

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:

Attachment: cygutils-extra.txt
Description: Text document

and check the content of "" (should be "" 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:
Unsubscribe info:

Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]