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
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 -- -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
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
Hi Václav, On Apr 2 12:25, Václav Zeman wrote: > Hi. > > I have tried to compile the log4cplus library on Cygwin64. Compilation > goes fine but linking ends with error. > [...] > src/.libs/liblog4cplus_la-cygwin-win32.o: In function `VarCmp': > /usr/include/w32api/oleauto.h:487: undefined reference to `VarCmp' > /usr/include/w32api/oleauto.h:487:(.text+0x34f): relocation truncated > to fit: R_X86_64_PC32 against undefined symbol `VarCmp' > src/.libs/liblog4cplus_la-cygwin-win32.o: In function `_InterlockedAdd': > /usr/include/w32api/winnt.h:1452: undefined reference to > `_InterlockedExchangeAdd' > [...] Thanks for the report. That's apparently a bug in the Cygwin w32api implementation of the mingw libs. On 64 bit, a lot of simple functions of the w32api, or functions used under the hood of inline functions, are implemented as compiler intrinsics in the Microsoft Visual compilers. These compiler intrinsics don't exist in gcc, therefore they are implemented as library functions in Mingw-w64. Unfortunately they are implemented in libmingwex.a right now, which is not included in the Cygwin w32api. I'm going to fix that today, so that the intrinsics will be exported by libkernel32.a instead. This allows Cygwin applications to access them as well.(Continue reading)
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-hierarchylocker.o src/.libs/liblog4cplus_la-layout.o src/.libs/liblog4cplus_la-log4judpappender.o src/.libs/liblog4cplus_la-lockfile.o(Continue reading)
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
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:(Continue reading)
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(Continue reading)
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 number, the other a pointer. I have not the faintest idea what that was good for. The Cygwin code duplicating the content to make it available across fork didn't take that into account, so it crashed instead. Should be fixed now. I appreciate testing and bug reports and... PATCHES! Have fun, Corinna(Continue reading)
$ 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
RSS Feed39 | |
|---|---|
78 | |
130 | |
177 | |
2 | |
58 | |
6 | |
19 | |
7 | |
62 | |
4 | |
26 | |
46 | |
4 | |
9 | |
20 | |
1 | |
66 | |
60 | |
125 | |
63 | |
37 | |
63 | |
31 | |
12 | |
8 | |
4 |
