This is the mail archive of the cygwin-apps 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: 64 bit: build problems

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
cannot find -ladvapi32
cannot find -lshell32
cannot find -luser32
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 =
   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.
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:

        echo x$(linkdir)y

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


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