gmane.os.cygwin.devel

Please confirm that I didn't break 64-bit cygwin build

Christopher Faylor — 2013-04-30T23:52:29

I'm not yet set up to build 64-bit cygwin on my computer.  Could someone
(Yaakov?) please confirm that my recent checkins didn't cause any
problems?

In the meantime I promise that I'll get my gentoo system set up with a
cygwin cross compiler soon.

cgf

64 bit branch merged into CVS HEAD

Corinna Vinschen — 2013-04-23T09:50:35

Hi guys,

I just merged the 64 bit code into CVS HEAD, so any further development
will be done exclusively in HEAD.  The cygwin-64bit-branch is now closed.
Please don't apply any changes there.

For bookkeeping I added a tag "cygwin-64bit-premerge" before merging,
then I created a branch "cygwin-64bit-premerge-branch" from there,
should it be necessary to do anything in the 32 bit-only code.  After
the merge I added a tag "cygwin-64bit-postmerge".


Corinna

[COMMITTED 64bit] missing parenthesis in stdint.h

Yaakov — 2013-04-22T02:56:50

I committed the attached patch as obvious.


Yaakov

64bit: gcc vs. harfbuzz

Yaakov (Cygwin/X — 2013-04-16T05:14:26

harfbuzz (since at least 0.9.12) is failing to link with gcc-4.8.0-1 on 
x86_64:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/harfbuzz

.libs/libharfbuzz_la-hb-ot-shape-complex-arabic.o:hb-ot-shape-complex-arabic.cc:(.rdata+0x1c8): 
relocation truncated to fit: R_X86_64_PC32 against 
`.text$_ZNK2OT19SubstLookupSubTable8dispatchINS_18hb_apply_context_tEEENT_8return_tEPS3_j'
[snip duplicates]
.libs/libharfbuzz_la-hb-ot-shape-complex-arabic.o:hb-ot-shape-complex-arabic.cc:(.rdata+0x1ec): 
relocation truncated to fit: R_X86_64_PC32 against 
`.text$_ZNK2OT11SubstLookup10apply_onceEPNS_18hb_apply_context_tE'
.libs/libharfbuzz_la-hb-ot-shape-complex-arabic.o:hb-ot-shape-complex-arabic.cc:(.rdata+0x1f0): 
additional relocation overflows omitted from the output
collect2: error: ld returned 1 exit status

The same package builds successfully on i686 4.5.3 (I'm building 4.7.3 
now to test).


Yaakov

[64 bit] problem using Win32 API in native Cygwin64 library

Václav Zeman — 2013-04-02T10:25:19

Hi.

I have tried to compile the log4cplus library on Cygwin64. Compilation
goes fine but linking ends with error.

The file src/.libs/liblog4cplus_la-cygwin-win32.o is the only one that
references Win32 API and includes windows.h. The library is trying to
get Windows' thread ID using the GetCurrentThreadId() function.

Here is libtool invocation:

libtool: link: g++ -shared -nostdlib
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/crtbegin.o
src/.libs/liblog4cplus_la-appenderattachableimpl.o
src/.libs/liblog4cplus_la-appender.o
src/.libs/liblog4cplus_la-asyncappender.o
src/.libs/liblog4cplus_la-clogger.o
src/.libs/liblog4cplus_la-configurator.o
src/.libs/liblog4cplus_la-consoleappender.o
src/.libs/liblog4cplus_la-cygwin-win32.o
src/.libs/liblog4cplus_la-env.o src/.libs/liblog4cplus_la-factory.o
src/.libs/liblog4cplus_la-fileappender.o
src/.libs/liblog4cplus_la-fileinfo.o
src/.libs/liblog4cplus_la-filter.o
src/.libs/liblog4cplus_la-global-init.o
src/.libs/liblog4cplus_la-hierarchy.o
src/.libs/liblog4cplus_la-hierarchylo

64bit: weak symbols

Yaakov (Cygwin/X — 2013-03-31T03:32:08

The following code links behaves on i686 and x86_64:

/* from gcc config/weakref.m4, used in libitm */
extern void fNotToBeFound(void) __attribute__((weak));
int main ()
{
  if (fNotToBeFound)
    return 1;
  else
    return 0;
}

On i686 with gcc-4.5.3, this links and returns 0.  On x86_64 with
gcc-4.8.0, this produces an error:

/tmp/ccPWiz9s.o:test.c:(.rdata$.refptr.fNotToBeFound[.refptr.fNotToBeFound]+0x0):
undefined reference to `fNotToBeFound'
collect2: error: ld returned 1 exit status


--
Yaakov

[64bit] emacs is unable to call subprocesses if display-time-mode is set

Ken Brown — 2013-03-30T10:54:05

When you set display-time-mode in emacs, the mode line near the bottom 
of the screen shows the current time.  The code that does this involves 
setting itimers.

After I set display-time-mode, every attempt to start a subprocess 
within emacs fails.  Steps to reproduce:

1. Install my build of 64-bit emacs, which was just uploaded to 
64bit/release.

2. Start emacs via `emacs -Q' in a Cygwin terminal.

3. You should now be in the *scratch* buffer.  Set display-time-mode:

   <alt-x>display-time-mode<ret>

[You should see the time displayed in the mode line.]

4. Type the following text in the *scratch* buffer, position the cursor 
at the end, and type `<cntl-j>':

(call-process "/bin/ls" nil t t)

emacs will report "Can't exec program: /bin/ls".

I tried to step through the emacs code in gdb, but gdb became 
unresponsive after a while and I had to kill it with the Task Manager.

I also tried strace, with the following results:

(a) If I attach strace to a running emacs process and then carry out 
steps 3 an

64bit segfault in cygcheck

Peter Rosin — 2013-03-28T15:20:25

Hi!

I did a "cygcheck -svc", mostly for fun, and got a segfault. A gbd
session puts the blame on cygcheck.cc:671, which currently has this:

670:  struct tm *tm = localtime ((const time_t *) &(ed->timestamp));
671:  if (tm->tm_year < 60)
672:    tm->tm_year += 2000;

The reproducer I have is:

$ cygcheck -v /bin/cygruby191.dll
Segmentation fault
$

So, since I'm not set up to build my own cygwin dll (not
comfortably anyway), I will try a blind patch and leave the
testing of it to someone else.

I haven't researched what's up with that dll, and why localtime()
would fail, but checking the return value is the right thing to do
regardless if there are other issues.

Cheers,
Peter

Index: cygcheck.cc
===================================================================
RCS file: /cvs/src/src/winsup/utils/cygcheck.cc,v
retrieving revision 1.137
diff -u -r1.137 cygcheck.cc
--- cygcheck.cc21 Jan 2013 16:28:27 -00001.137
+++ cygcheck.cc28 Mar 2013 15:08:29 -0000
< at >< at > -668,16 +668,19 < at >< at >
   ExpDirectory *ed = (Exp

64 bit Cygwin 1.7.18-12

Corinna Vinschen — 2013-03-27T15:16:56

Hi guys,


I just uploaded a new 64 bit Cygwin DLL.  This version fixes a few
problems, namely:

- Since Vista and the introduction of native symlinks, the OS has
  multiple ways to suppress symlink usage.  By default, remote symlinks
  are disallowed, or better, they are not evaluated and the OS returns
  an error instead.  This can be changed with the on-board fsutil
  utility.  Cygwin didn't yet handle the case that symlinks couldn't be
  read.  That's fixed now.  Cygwin returns ELOOP for unreadable
  symlinks.  ENOENT wouldn't work in this scenario.

- The wrong defines were set for the available build environment.  So
  far, _POSIX_V6_ILP32_OFFBIG was still 1, the others -1, which was only
  correct for the 32 bit environment.  Now on x86_64,
  _POSIX_V6_LP64_OFF64 and _POSIX_V6_LPBIG_OFFBIG are 1 instead.
  I changed confstr accordingly.

- getservbyname and getservbyport usually crashed on 64 bit.  The reason
  was that the servent structure on 64 bit Windows has reordered two
  members, one the port

tzset crash in 64-bit Cygwin

Ken Brown — 2013-03-25T21:52:59

$ uname -a
CYGWIN_NT-6.1 fiona 1.7.18(0.263/5/3) 2013-03-22 15:00 x86_64 Cygwin

$ tzset

[no output]

$ cat tzset.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=00100401B13
rax=00000001004071B0 rbx=000000000022A490 rcx=00000001004071B0
rdx=0000000000000020 rsi=0000000100402C08 rdi=000000000000007B
r8 =0000000000000000 r9 =0000000000000053 r10=00000000002B084C
r11=0000000000000000 r12=000000000022A470 r13=0000000100402080
r14=0000000000000000 r15=0000000000000000
rbp=000000000000007B rsp=000000000022A400
program=C:\cygwin64a\bin\tzset.exe, pid 16124, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B

Ken

Update RLIM_INFINITY for x86_64?

Ken Brown — 2013-03-20T17:50:43

My understanding is that RLIM_INFINITY is usually equal to (or very 
close to) SIZE_MAX on Posix-like systems.  If this is right, then I 
think we need something like the attached patch.

Ken
--- resource.h.orig2013-03-20 12:20:21.569382900 -0400
+++ resource.h2013-03-20 11:54:53.900144800 -0400
< at >< at > -34,7 +34,11 < at >< at >
 #define RLIMIT_NLIMITS  7/* upper bound of RLIMIT_* defines */
 #define RLIM_NLIMITS    RLIMIT_NLIMITS
 
+#ifdef __x86_64__
+#define RLIM_INFINITY(0xffffffffffffffffUL)
+#else
 #define RLIM_INFINITY(0xffffffffUL)
+#endif
 #define RLIM_SAVED_MAXRLIM_INFINITY
 #define RLIM_SAVED_CURRLIM_INFINITY

What you have to look for on 64 bit

Corinna Vinschen — 2013-03-19T10:48:06

Hi guys,


it just occured to me that it might be helpful to report a typical 64
bit porting bug we observed yesterday, while testing the sigdelayed
patch.

Kai was going to run the gas testsuite which requires dejagnu and
expect, but expect simply crashed.  After a bit of debugging it
turned out that expect was calling the openpty function, like so:

  char *master, *slave,*name;
  openpty (master, slave, name, 0, 0);

The last two parameters to openpty are pointers, just like the first
three.  However, the constant 0 is int by default.  int is 32 bit, but
pointers are 64 bit on x86_64.  This would have been no problem, if
expect had included the pty.h header which provides a prototype for
openpty.  GCC would have known to extend the 0 constants to 64 bit in
this case.  Alas, expect did not include pty.h and so the 0 were not 64
bit extended, but given as 32 bit parameter to openpty.  Since all
parameters take 64 bit slots, the upper 32 bit of the parameters were
undefined.  Instead of NULL pointers, openpt

New 64 bit Cygwin DLL

Corinna Vinschen — 2013-03-19T09:46:22

Hi guys,


at long last, it looks like we found the real bug which was the reason
for the random crashes.

There's a function sigdelayed, written in assembler, which is called
when a thread got a signal.  Due to the way the function is called,
it turned out that it was missing two crucial features:

- It can be called with any stack alignment, but on x86_64 it's important
  that the stack is always 16 byte aligned when calling functions.  So
  sigdelayed had to make sure to align the stack before trundling along.

- sigdelayed only saved and restored the CPU registers which are
  callee-saved in the Microsoft ABI, plus the registers used for the
  return value of a function.  Given how sigdelayed is called, this
  was insufficient.  The original, interrupted function needs the CPU
  in its original state when sigdelayed returns to it, so sigdelayed
  has to save and restore *all* registers.

So, here we go with a new 64 bit Cygwin version 1.7.18-9.  You'll
find the packages under ftp://cygwin.com/pub/cygwin/

Question on sys/reent.h

Yaakov — 2013-03-17T23:22:35

The following section of <sys/reent.h> caused a conflicting typedef
error when building libjava:

#ifndef __Long
#if __LONG_MAX__ == 2147483647L
#define __Long long
typedef unsigned __Long __ULong;
#elif __INT_MAX__ == 2147483647
#define __Long int
typedef unsigned __Long __ULong;
#endif
#endif

These types appear to be used in newlib's dtoa.c and mprec.c (it is a
copy of the latter in libjava which triggers this error).  Is this
correct or it is another ssize_t?


Yaakov

undefined reference to `strlwr' on 64bit Cygwin

Ken Brown — 2013-03-17T02:08:43

$ uname -a
CYGWIN_NT-6.1 fiona 1.7.18(0.263/5/3) 2013-03-15 16:35 x86_64 Cygwin

$ gcc --version
gcc (GCC) 4.8.0 20130307 (experimental)

$ cat strlwr_test.c
#include <string.h>
#include <stdio.h>

int
main ()
{
   char str[] = "FRED";
   printf ("%s\n", strlwr (str));
}

$ gcc strlwr_test.c
/tmp/ccW2SOn8.o:strlwr_test.c:(.text+0x20): undefined reference to `strlwr'
/tmp/ccW2SOn8.o:strlwr_test.c:(.text+0x20): relocation truncated to fit: 
R_X86_64_PC32 against undefined symbol `strlwr'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: 
/tmp/ccW2SOn8.o: bad reloc address 0x0 in section `.pdata'
/usr/lib/gcc/x86_64-pc-cygwin/4.8.0/../../../../x86_64-pc-cygwin/bin/ld: 
final link failed: Invalid operation
collect2: error: ld returned 1 exit status

Ken

P.S. Is this still the appropriate list for 64bit bug reports, or is it 
time to move to the main cygwin list?

[Cygwin64] unloading of dlls

Peter Rosin — 2013-03-15T09:14:04

Hi!

I'm wondering if there is some difference in how dlls are unloaded
on Cygwin64 vs Cygwin32?

In libggi, there's a X.dll that handles drawing on an X server.
X.dll has the capacity to dynamically load a dbe.dll (dbe.dll is
linked with -lXext, something which X.dll is not) helper that
calls XdbeQueryExtension. XdbeQueryExtension happens to store
a pointer to a hook that is supposed to be called on XCloseDisplay
in some private area. Now, if I unload dbe.dll before I close
XCloseDisplay, the hook appears to have disappeared from the
address space by the time I call XCloseDisplay, but only on
Cygwin64 (with drastic effects). While a teeny bit fragile, and
probably a practice best avoided, this still appears to work
fine on Cygwin32.

Is there some natural explanation for the 32/64 difference?

Cheers,
Peter

[Cygwin64] make segfault

Peter Rosin — 2013-03-14T16:05:18

Hi!

Sure looks familiar, but it's make this time...

$ uname -a
CYGWIN_NT-6.1 PEDA-PC 1.7.18(0.263/5/3) 2013-03-13 11:11 x86_64 Cygwin

Cheers,
Peter



Reading symbols from /usr/bin/make.exe...(no debugging symbols found)...done.
Attaching to program `/usr/bin/make.exe', process 45412
[New Thread 45412.0x5360]
[New Thread 45412.0x41b0]
[New Thread 45412.0xa8f4]
[New Thread 45412.0x2fe0]
[New Thread 45412.0x48e8]
(gdb) t a a bt

Thread 5 (Thread 45412.0x48e8):
#0  0x0000000076eb0531 in ntdll!DbgBreakPoint ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x0000000076f57ef8 in ntdll!DbgUiRemoteBreakin ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#2  0x0000000000000000 in ?? ()

Thread 4 (Thread 45412.0x2fe0):
#0  0x0000000076eb135a in ntdll!ZwWaitForSingleObject ()
   from /cygdrive/c/Windows/SYSTEM32/ntdll.dll
#1  0x000007fefd4b10dc in WaitForSingleObjectEx ()
   from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 3 (Thread 45412.0xa8f4):
#0  0x0000000076eb135a

Error building libffi on x86_64

Yaakov — 2013-03-13T04:27:36

I have encountered the following error attempting to build
libffi-3.0.12 on Cygwin:

src/x86/.libs/win64.o:/usr/src/debug/libffi-3.0.12-1/src/x86/win64.S:298:(.text+0x69): relocation truncated to fit: R_X86_64_32S against symbol `ffi_closure_win64_inner' defined in .text section in src/x86/.libs/ffi.o

The only matches on Google for this sort of error were for >2GB code on
Linux, but I suspect the problem here is with the medium code model.

Here's what I'm working with:

http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/libffi


Yaakov

[Cygwin64] Flex segfault

Teemu Nätkinniemi — 2013-03-11T18:30:30

I noticed during compiling Cocom that flex segfaults when it is trying 
to run a basic test. After working around the fault I tried several 
different scripts and they all fail.

%%
%%

This res

Starting program: /usr/bin/flex flextest.l
[New Thread 7436.0xff8]
[New Thread 7436.0x1ef4]

Program received signal SIGSEGV, Segmentation fault.
flexinit (argc=argc< at >entry=2, argv=argv< at >entry=0x23aaf0)
     at /usr/src/debug/flex-2.5.37-1/main.c:966
966             action_array[0] = '\0';

(gdb) t a a bt
Thread 2 (Thread 7436.0x1ef4):
#0  0x000007fcf1a32c4a in ?? ()
#1  0x000007fceeda6188 in ReadFile ()
    from /cygdrive/c/Windows/system32/KERNELBASE.dll
#2  0x0000000000000000 in ?? ()

Thread 1 (Thread 7436.0xff8):
#0  flexinit (argc=argc< at >entry=2, argv=argv< at >entry=0x23aaf0)
     at /usr/src/debug/flex-2.5.37-1/main.c:966
#1  0x000000010040b3bc in flex_main (argc=2, argv=0x23aaf0)
     at /usr/src/debug/flex-2.5.37-1/main.c:181
#2  0x0000000180047834 in _cygwin_exit_return ()
     at /usr/src/debug/cygwin-1.7.18-3/wi

[Cygwin64] Python, Tk etc.

Teemu Nätkinniemi — 2013-03-11T12:50:20

I've compiled several packages and uploaded them to Sourceforge. The 
packages include: Python, Tk, Expect, Cocom and their dependencies. For 
Python I had to compile older libffi from GCC 4.5.3 and it has been 
linked in statically.

https://sourceforge.net/projects/cyg64files/files/release/

[Cygwin64] dash segfault

Peter Rosin — 2013-03-08T22:13:15

Hi!

I doubt there is a shortage of obscure things to track down in the land
of 64-bit, but while building a package using the stuff from install/release
I noticed a segfault in dash when it ran a libtool script to generate a
dll. Retrying got the dll built correctly.

Fact is, I do see segfaults once in a while, but retrying has always helped
so far, so I haven't pursued it.

How do I set up a debugger to get more info than the below stackdump?

Cheers,
Peter

bash-4.1$ cat dash.exe.stackdump
Exception: STATUS_ACCESS_VIOLATION at rip=00180148035
rax=0000000000000000 rbx=000006FFFFF94A00 rcx=0000000000000043
rdx=00000001802B6DE8 rsi=000006FFFFF8F630 rdi=0000000000000043
r8 =0000000010454050 r9 =0000000010454040 r10=00000001800BEEC0
r11=0000000100410325 r12=0000000100419910 r13=00000000FFFFFFFB
r14=0000000000000004 r15=000006FFFFF948D0
rbp=0000000000000001 rsp=00000000002285F0
program=C:\Cygwin\opt\bin\dash.exe, pid 38688, thread main
cs=0033 ds=002B es=002B fs=0053 gs=002B ss=002B