Fwd: Cygwin64: mkshortcut - Segmentation fault

[Charles Wilson]

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
> /usr/bin/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
> ...
> /usr/bin/cygicons-0.dll
> ...
> /usr/lib/libcygicons.dll.a
> /usr/lib/libcygicons.la
>
> 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.

--
Chuck


--
Problem reports:       http://cygwin.com/problems.html
FAQ:                   http://cygwin.com/faq/
Documentation:         http://cygwin.com/docs.html
Unsubscribe info:      http://cygwin.com/ml/#unsubscribe-simple