Re: [RFU] ocaml-4.00.1-1
Hi Damien, On Jun 9 16:42, Damien Doligez wrote: On 2013-06-07, at 16:19, Corinna Vinschen wrote: Done. Any chance to try building a 64 bit version of ocaml, Damien? I'll be working on that, yes. On 2013-06-07, at 20:00, Yaakov (Cygwin/X) wrote: Ouch. Because of the fickle nature of OCaml's ABI, all OCaml libraries have to be rebuilt for every version bump. While there not be much OCaml code in the distro, I have dozens of libraries in Ports which need to be rebuilt. Next time, could you please give me some rebuild time before stabilizing a new version of OCaml? Ah, sorry. I didn't realize there would be so many dependencies. Next time I'll warn you in advance. Did you see http://cygwin.com/ml/cygwin/2013-06/msg00160.html ? Given what Yaakov said, wouldn't it make sense to provide the former ocaml libs and start using a versioned runtime lib approach? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64bit] python3 vs. threads
Hi Jason, On Jun 7 19:07, Jason Tishler wrote: Yaakov, On Mon, Jun 03, 2013 at 11:30:28PM -0500, Yaakov (Cygwin/X) wrote: As part of the 64bit bootstrap process, I packaged python3, but had to configure it --without-threads due to a runtime error. However, I am finding now that this is not a regularly used configuration; several major Python modules use PyGILState_*() APIs unconditionally, which aren't exported when so configured. Are you able to take a look at the runtime failure and track it down? Unfortunately, I don't have access to 64-bit Windows. You can download a Windows 2012 Evaluation ISO for free from the MSDN homepage: http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx Windows 2012 is always 64 bit, and the evaluation versions works for 180 days for, well, evaluation. It runs fine in VMs. Does that help? Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64bit] openldap compilation doesn't produce shared libraries
On Jun 10 11:11, Dr. Volker Zell wrote: Volker Zell writes: Yaakov writes: Following up on this, I noticed that slapd's build process is quite broken, resulting in an invalidly formatted executable. The working method to create a linkable EXE is to just link it with -Wl,--export-all-symbols,--out-implib,libfoo.a, then link other modules with -Wl,path/to/libfoo.a. (Relying on -L flags for in-tree paths isn't always a good idea with libtool.) I took the liberty of fixing up the build of slapd both with and without modular backends/overlays. The patch and modified cygport(3) are in Ports git: http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/openldap You made my day. I am struggling with this since more than a week. I actually managed to get a working slapd executable but the openldap test suite still doesn't run. ldapsearch always core dumps. I will check out your .cygport approach and see if it makes any difference. I'll try to do it on monday... Building with your cygport file also results in ldapsearch core dumping :-( Running with strace gives: ldapsearch.exe.stackdump: Exception: STATUS_ACCESS_VIOLATION at rip=004091D184A [...] Stack trace: FrameFunctionArgs 0229D70 004091D184A (0229DC0, 36E, 006000424CD, 374) 0229D70 004091D22F2 (000, 0229F70, 0229F40, 0229E18) These addresses are in some DLL. Check the installed DLLs with `rebase -i /bin/*.dll' and the not-installed DLLs with objdump -h for their addresses to find out which one this is. 0229F40 005205B287C (00600040E60, 000, 001800C0C93, 0229F40) Another DLL. 00600042160 00100401DDB (038F194, 001802DFFDD, 000, 0010040F4ED) 000 0010040BD69 (022AB80, 000, 000, 000) The executable itself, probably main and another function called from main. 022AB80 001800483AE (000, 000, 000, 000) 000 0018004618B (000, 000, 000, 000) 000 0018004634F (000, 000, 000, 000) Cygwin DLL, probably the normal startup via dll_crt0_1. 000 0010040A4C1 (000, 000, 000, 000) 000 00100401010 (000, 000, 000, 000) 000 0007740652D (000, 000, 000, 00077489300) 000 00077AFC521 (000, 000, 000, 00077489300) This is the normal start up of the executable. As for the addresses, I'd like to point out my mail from February again: http://cygwin.com/ml/cygwin-developers/2013-02/msg00027.html Maybe that should go into the user's guide at one point. The strace output is attached. See below. Running under gdb doesn't work either. What am I doing wrong here ? Did you build the entire stuff, including the libs, without optimization? That helps a lot when debugging. vzell@leila /cygdrive/d/misc/src/release64/openldap-2.4.35-1/build/tests 10:40 AM [519] PATH=../../inst/usr/lib/debug/usr/bin:$PATH gdb ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg You cannot start the *.dbg file. It's just the file containing the debug symbols, not the actual binary. What you should do is starting the real binary: $ gdb ./ldapsearch.exe and then, if gdb complains that it can't find the debug symbols: (gdb) symbol-file ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg [...] 43 89818 [main] ldapsearch 5512 fhandler_base::fstat_helper: 0 = fstat (\??\D:\misc\src\release64\openldap-2.4.35-1\build\tests\STARCE, 0x229C20) st_size=137414, st_mode=0x81A4, st_ino=15199648742446005st_atim=51B5931C.1BF62654 st_ctim=51B5931C.1BF62654 st_mtim=51B5931C.1BF62654 st_birthtim=51B5931C.1BF62654 24 89842 [main] ldapsearch 5512 fstat64: 0 = fstat(1, 0x229C20) --- Process 1028, exception c005 at 0004091D184A I don't know what's causing this, but this very certainly occurs inside of the DLL located at or around 0x4:091d, after a call to fstat for the file STARCE. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64bit] python3 vs. threads
On Jun 10 10:32, Corinna Vinschen wrote: Hi Jason, On Jun 7 19:07, Jason Tishler wrote: Yaakov, On Mon, Jun 03, 2013 at 11:30:28PM -0500, Yaakov (Cygwin/X) wrote: As part of the 64bit bootstrap process, I packaged python3, but had to configure it --without-threads due to a runtime error. However, I am finding now that this is not a regularly used configuration; several major Python modules use PyGILState_*() APIs unconditionally, which aren't exported when so configured. Are you able to take a look at the runtime failure and track it down? Unfortunately, I don't have access to 64-bit Windows. You can download a Windows 2012 Evaluation ISO for free from the MSDN homepage: http://msdn.microsoft.com/en-us/evalcenter/hh708764.aspx Windows 2012 is always 64 bit, and the evaluation versions works for 180 days for, well, evaluation. It runs fine in VMs. Does that help? There's also a shorter running (90 days) evaluation version of Windows 8 available, btw: http://technet.microsoft.com/en-US/evalcenter/hh699156.aspx but usually it's enough to check on the server system. The differences between client and server usually(*) don't affect Cygwin. Corinna (*) Except they did when Vista was new. Some difference in exception handling on 32 bit foiled Cygwin's exception handling on 2008, but not on Vista. But that's the only one I remember. -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: [64bit] openldap compilation doesn't produce shared libraries
Corinna Vinschen writes:
On Jun 10 11:11, Dr. Volker Zell wrote:
Volker Zell writes:
Yaakov writes:
Following up on this, I noticed that slapd's build process is quite
broken,
resulting in an invalidly formatted executable. The working method
to create a
linkable EXE is to just link it with
-Wl,--export-all-symbols,--out-implib,libfoo.a, then link other
modules with
-Wl,path/to/libfoo.a. (Relying on -L flags for in-tree paths isn't
always a
good idea with libtool.)
I took the liberty of fixing up the build of slapd both with and
without modular
backends/overlays. The patch and modified cygport(3) are in Ports
git:
http://cygwin-ports.git.sourceforge.net/git/gitweb.cgi?p=cygwin-ports/openldap
You made my day. I am struggling with this since more than a week. I
actually managed to get a working slapd executable but the openldap
test
suite still doesn't run. ldapsearch always core dumps. I will check out
your .cygport approach and see if it makes any difference. I'll try to
do it on monday...
Building with your cygport file also results in ldapsearch core dumping
:-(
Running with strace gives:
ldapsearch.exe.stackdump:
Exception: STATUS_ACCESS_VIOLATION at rip=004091D184A
[...]
Stack trace:
FrameFunctionArgs
0229D70 004091D184A (0229DC0, 36E, 006000424CD,
374)
0229D70 004091D22F2 (000, 0229F70, 0229F40,
0229E18)
These addresses are in some DLL. Check the installed DLLs with
`rebase -i /bin/*.dll' and the not-installed DLLs with objdump -h for
their
addresses to find out which one this is.
0229F40 005205B287C (00600040E60, 000, 001800C0C93,
0229F40)
Another DLL.
00600042160 00100401DDB (038F194, 001802DFFDD, 000,
0010040F4ED)
000 0010040BD69 (022AB80, 000, 000,
000)
The executable itself, probably main and another function called from
main.
022AB80 001800483AE (000, 000, 000,
000)
000 0018004618B (000, 000, 000,
000)
000 0018004634F (000, 000, 000,
000)
Cygwin DLL, probably the normal startup via dll_crt0_1.
000 0010040A4C1 (000, 000, 000,
000)
000 00100401010 (000, 000, 000,
000)
000 0007740652D (000, 000, 000,
00077489300)
000 00077AFC521 (000, 000, 000,
00077489300)
This is the normal start up of the executable.
As for the addresses, I'd like to point out my mail from February again:
http://cygwin.com/ml/cygwin-developers/2013-02/msg00027.html
Maybe that should go into the user's guide at one point.
The strace output is attached.
See below.
Running under gdb doesn't work either. What am I doing wrong here ?
Did you build the entire stuff, including the libs, without optimization?
That helps a lot when debugging.
vzell@leila /cygdrive/d/misc/src/release64/openldap-2.4.35-1/build/tests
10:40 AM [519] PATH=../../inst/usr/lib/debug/usr/bin:$PATH gdb
../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg
You cannot start the *.dbg file. It's just the file containing the
debug symbols, not the actual binary. What you should do is starting
the real binary:
$ gdb ./ldapsearch.exe
and then, if gdb complains that it can't find the debug symbols:
(gdb) symbol-file ../../inst/usr/lib/debug/usr/bin/ldapsearch.exe.dbg
[...]
43 89818 [main] ldapsearch 5512 fhandler_base::fstat_helper: 0 = fstat
(\??\D:\misc\src\release64\openldap-2.4.35-1\build\tests\STARCE, 0x229C20)
st_size=137414, st_mode=0x81A4,
st_ino=15199648742446005st_atim=51B5931C.1BF62654 st_ctim=51B5931C.1BF62654
st_mtim=51B5931C.1BF62654 st_birthtim=51B5931C.1BF62654
24 89842 [main] ldapsearch 5512 fstat64: 0 = fstat(1, 0x229C20)
--- Process 1028, exception c005 at 0004091D184A
I don't know what's causing this, but this very certainly occurs
inside of the DLL located at or around 0x4:091d, after a call
to fstat for the file STARCE.
Via similar calls (see one line below) to ldapsearch.exe and the not yet
installed openldap libraries
awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e
../libraries/liblber/.libs/cyglber-2-4-2.dll
awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e
../libraries/libldap/.libs/cygldap-2-4-2.dll
awk '/^[0-9]/{print $2}' ldapsearch.exe.stackdump | addr2line -f -e
../clients/tools/.libs/ldapsearch.exe
I think the stack trace
Stack
[64bit] Cygwin 1.7.21-1
Just the latest from CVS. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat
Re: Cygwin libtool update
On 6/9/2013 7:01 AM, JonY wrote: Care to put up 2.4.2? It's been out for some time now. It will take some time, but yes. That'll be on the queue right after run2 and libXpm-noX (and perhaps another 'run' b/c...well, JobQueues. See upcoming post on main list). -- Chuck
[64bit RFU] keepassx-0.4.3-1
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=6 \
${BASEURL}/gMetoiuG3_/64bit/release/KDE/keepassx/keepassx-0.4.3-1-src.tar.bz2
\
${BASEURL}/faOgOyuoYS/64bit/release/KDE/keepassx/keepassx-0.4.3-1.tar.bz2 \
${BASEURL}/xaqPOGFz3J/64bit/release/KDE/keepassx/setup.hint \
${BASEURL}/U82Dz9jF1S/64bit/release/KDE/keepassx/keepassx-debuginfo/keepassx-debuginfo-0.4.3-1.tar.bz2
\
${BASEURL}/J4n6_izWKV/64bit/release/KDE/keepassx/keepassx-debuginfo/setup.hint
Please note: If you intend to use the 64-bit build of keepassx with a
native Windows web browser, you should run the 32-bit version of
Cygwin/X. This is because there is no integration between the X and
Windows clipboards in 64-bit Cygwin/X.
See http://www.cygwin.com/ml/cygwin-xfree/2013-06/msg6.html
Other maintainers may encounter the same problem in X applications that
use the clipboard. Presumably, this will be fixed at some point in the
future.
Many thanks in advance for uploading,
Dave.
Re: [ITA] shutdown 1.10-1
On Jun 7 13:14, Frank Fesevur wrote: Hi, As invited by Corinna to take over maintenance of the Cygwin shutdown package[1]. Looks good. Uploaded. Thanks for taking over! Please send an announcement to the cygwin-announce list. Gold star awarded: http://cygwin.com/goldstars/#FF
[RFU] sqlite3-3.7.17-3
Leave 3.7.16.2-1 as curr, and make this test only for now. (I am hoping to be able to promote it to curr later, but it changes too much to risk that without more testing. The only reason I'm RFU'ing it is because there seems to be some resistance to installing test versions from raw tarballs.) From within release/sqlite3: wget -e robots=off --cut-dirs=2 -np -nH -A'*3.7.17-3*' -A'*.hint' \ -r http://etr-usa.com/cygwin/sqlite3/
Re: [64bit RFU] keepassx-0.4.3-1
Il 6/10/2013 7:43 PM, David Stacey ha scritto:
BASEURL=http://dl.dropbox.com/sh/7y1yn4whbyho9a7
wget --no-check-certificate --no-host-directories --force-directories
--cut-dirs=6 \
${BASEURL}/gMetoiuG3_/64bit/release/KDE/keepassx/keepassx-0.4.3-1-src.tar.bz2
\
${BASEURL}/faOgOyuoYS/64bit/release/KDE/keepassx/keepassx-0.4.3-1.tar.bz2 \
${BASEURL}/xaqPOGFz3J/64bit/release/KDE/keepassx/setup.hint \
${BASEURL}/U82Dz9jF1S/64bit/release/KDE/keepassx/keepassx-debuginfo/keepassx-debuginfo-0.4.3-1.tar.bz2
\
${BASEURL}/J4n6_izWKV/64bit/release/KDE/keepassx/keepassx-debuginfo/setup.hint
uploaded
