64 bit: build problems

Thomas Wolff towo@towo.net
Fri Mar 29 20:54:00 GMT 2013


Am 29.03.2013 15:43, schrieb Corinna Vinschen:
> On Mar 29 15:13, Corinna Vinschen wrote:
>> On Mar 29 12:37, Thomas Wolff wrote:
>>> Am 29.03.2013 10:42, schrieb Corinna Vinschen:
>>>> On Mar 29 10:00, Thomas Wolff wrote:
>>>>> Am 28.03.2013 20:51, schrieb Corinna Vinschen:
>>>>>> On Mar 28 19:45, Thomas Wolff wrote:
>>>>>>> I've tried to build my package (mined) with freshly installed 64-bit
>>>>>>> cygwin (default + gcc + make).
>>>>>>> When I try it with make, nothing happens, make simply hangs.
>>>>>>> When I try it without make, it fails with:
>>>>>>> linking mined
>>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
>>>>>>> cannot find -ladvapi32
>>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
>>>>>>> cannot find -lshell32
>>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
>>>>>>> cannot find -luser32
>>>>>>> /usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld:
>>>>>>> cannot find -lkernel32
>>>>>>  From your cygcheck output w32api is, in fact, missing, just as Adam wrote.  Other than that, the hang is strange.  I installed Cygwin 64 on 3 machines, W7, 2K8R2, and W8, and none of them is suffering a hang.
>>>>>> I don't know what to say.  Can you try to debug that?
>>>>> make -d reads all makefiles (with includes), then hangs.
>>>>> make option --trace, as mentioned in the manual page, does not exist.
>>>>> Any further hints how/what to debug?
>>>> strace and gdb are the usual tools here.  I don't know what to say else.
>>>> I'm running native builds using cygport for a couple of days now, and
>>>> sure enough I found a few bugs, but I didn't have a make hang at all.
>>>> Are you trying to build the exact 2012.22 package?  What's your exact
>>>> set of make options?  I can try if this occurs for me too.
>>> I verified that my local copy is identical to the 2012.22 package.
>>> Then strace gave me some hint indeed;
>>> If I comment out line 573 of include file mkinclud.mak (the "links:"
>>> target), all works fine.
>>> Otherwise, strace ends like this:
>>> [...]
>>>     30 1643627 [main] make 1412 symlink_info::check: 0 =
>>> symlink.check(D:\temp\mined-2012.22\src, 0x227700) (0x4022)
>>>     18 1643645 [main] make 1412 path_conv::check:
>>> this->path(D:\temp\mined-2012.22\src\links), has_acls(1)
>>>     19 1643664 [main] make 1412 __set_errno: int
>>> stat_worker(path_conv&, stat*):1880 setting errno 2
>>>     32 1643696 [main] make 1412 stat_worker: -1 =
>>> (\??\D:\temp\mined-2012.22\src\links,0x228960)
>>>    271 1643967 [main] make 1412 stat64: entering
>>>     15 1643982 [main] make 1412 normalize_posix_path: src //xmined
>>>     18 1644000 [main] make 1412 normalize_posix_path: //xmined =
>>> normalize_posix_path (//xmined)
>> Any idea why it tries to access a file called //xmined?  The double
>> slash at the beginning indicates a network UNC path.  So what Cygwin
>> does is trying to access a server called xmined on your network.
The purpose of this make clause is to install links into the bin 
directory, but only when calling make recursively from the install 
target, in which case $(linkdir) would be set e.g. to /usr/bin.
When not installing, make should not really access those files, and in 
fact, make-32 does not (as shown by strace),
only make-64 invokes some actions on the filenames simply when parsing 
the makefile.
Plus...
> Ok, so your linkdir is apparently '/'.  That's not good here since it leads to the leading double slash.
as I tested, linkdir is actually *not* "/" but rather empty, so the path 
names involved should be e.g. /xmined, not //xmined. Still mysterious.

Furthermore, the suffix $(EXE) seems to be needed for the problem to occur.
Simplified test case: the following makefile hangs in cygwin64 but not 
in cygwin32:

all:
         echo x$(linkdir)y

links:  $(linkdir)/xmined$(EXE)

------
Thomas



More information about the Cygwin-apps mailing list