[ANNOUNCEMENT] Updated: postgresql-9.2.4-2
Version 9.2.4-2 of packages libecpg-compat3 libecpg-devel libecpg6 libpgtypes3 libpq-devel libpq5 postgresql postgresql-client postgresql-contrib postgresql-devel postgresql-doc postgresql-plperl postgresql-plpython are available in the Cygwin distribution: CYGWIN CHANGES - Added missing import library as reported http://www.cygwin.com/ml/cygwin/2013-06/msg00107.html http://www.postgresql.org/message-id/calbh9dadggg9asbcgywys8afkx6sc6p-rj8yxsmvl-bagxu...@mail.gmail.com - Added dll versioning numbers - Completely removed dlltoo/dllwrap from build system CHANGES Full upstream changes: http://www.postgresql.org/docs/9.2/static/release-9-2-4.html http://www.postgresql.org/about/news/1456/ ADVISE for major version UPGRADE http://www.postgresql.org/support/versioning/ Major releases usually change the internal format of system tables and data files. These changes are often complex, so we do not maintain backward compatibility of all stored data. A dump/reload of the database or use of the pg_upgrade module is required for major upgrades. DESCRIPTION PostgreSQL is a powerful, open source object-relational database system. It has a proven architecture that has earned it a strong reputation for reliability, data integrity, and correctness. It is fully ACID compliant, has full support for foreign keys, joins, views, triggers, and stored procedures (in multiple languages). It includes most SQL:2008 data types HOMEPAGE http://www.postgresql.org Marco Atzeri If you have questions or comments, please send them to the cygwin mailing list at: cygwin (at) cygwin (dot) com . *** CYGWIN-ANNOUNCE UNSUBSCRIBE INFO *** If you want to unsubscribe from the cygwin-announce mailing list, look at the "List-Unsubscribe: " tag in the email header of this message. Send email to the address specified there. It will be in the format: cygwin-announce-unsubscribe-you=yourdomain@cygwin.com If you need more information on unsubscribing, start reading here: http://sourceware.org/lists.html#unsubscribe-simple Please read *all* of the information on unsubscribing that is available starting at this URL. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[64bit] Xlib.h not available in cross-compile-to-self usage
On a 32-bit cygwin I get $ uname -a CYGWIN_NT-6.1-WOW64 panamint 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin $ find /usr -name Xlib.h -print /usr/include/X11/Xlib.h /usr/x86_64-pc-cygwin/sys-root/usr/include/X11/Xlib.h /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/Tk/pTk/Xlib.h and using either gcc or x86_64-pc-cygwin-gcc I can build X apps, but if I use i686-pc-cygwin-gcc I have some of the X headers but not (eg) Xlib.h. On 64-bit cygwin despite having installed every packaged with cygwin32 in its name as per the setup serach box I get CYGWIN_NT-6.1 panamint 1.7.21(0.266/5/3) 2013-06-10 17:39 x86_64 Cygwin $ find /usr -name Xlib.h -print /usr/include/X11/Xlib.h acn1@panamint usr and so while gcc works i686-pc-cygwin-gcc will build console but not X apps. However it "wants" to: $ find /usr -name X.h -print /usr/i686-pc-cygwin/sys-root/usr/include/X11/X.h /usr/include/X11/X.h since a cygwin32 X.h is provided. My presumption is that this is just a transitory feature of the 64-bit release (which is very welcome indeed - thanks so much) getting sorted out. I had been trying using an explicit "--host=.." with a view to being able to build both 32 and 64-bit versions of my code regardless of whether I was on a 32 or 64-bit shell platform. Arthur -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building latest CVS fails
On Jun 11 17:53, Daniel Colascione wrote: > g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem > /users/dancol/software/cygwin/winsup/cygwin/include > -B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem > /users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-include -isystem > /users/dancol/software/cygwin/newlib/libc/include-o dumper.exe dumper.o > module_info.o parse_pe.o > -B/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin/ -static > -Wl,--enable-auto-import -L/usr/lib/w32api -lnetapi32 -ladvapi32 -lkernel32 > -luser32 -lbfd -lintl -liconv -liberty -lz > c++wrap -c -o cygcheck.o -fno-exceptions -fno-rtti -O2 -g > ../../.././winsup/utils/cygcheck.cc > c++wrap -c -o bloda.o -fno-exceptions -fno-rtti -O2 -g > ../../.././winsup/utils/bloda.cc > c++wrap -c -o path.o -fno-exceptions -fno-rtti -O2 -g > ../../.././winsup/utils/path.cc > c++wrap -c -o dump_setup.o -fno-exceptions -fno-rtti -O2 -g > ../../.././winsup/utils/dump_setup.cc > ../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such file > or directory Try `CCWRAP_VERBOSE=1 make' to see the full command line. > ~/software/cygwin > $ uname -a > CYGWIN_NT-6.1-WOW64 xyzzy 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin $ cygcheck -f /usr/include/zlib.h zlib-devel-1.2.8-1 Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: __cygwin_environ, __imp_environ, _cur_environ, where is 'environ' symbol?
On Jun 11 23:55, Vasyl Khalak wrote:
> I have tried to compile 0.18.2 gettext on x64 Cygwin, and got
> "undefined reference to `environ'", where is the symbol?
>
> user@host /cygdrive/c/cygwin
>
> 32 bit:
> $ nm lib/libcygwin.a
> I __impcygwin_environ
> I __nmcygwin_environ
> ...
> B _environ
>
> $ nm bin/cygwin1.dll
> 61227a44 B ___cygwin_environ
> 6102db00 T _cur_environ@0
> 6118 D _main_environ
>
> 64 bit:
> $ nm /usr/lib/libcygwin.a
> I __imp_environ
> I __nm_environ
>
> $ nm /usr/bin/cygwin1.dll
> 0001802a4778 B __cygwin_environ
environ is the exported symbol referencing the internal __cygwin_environ
variable on x86_64. Linking against and accessing it works for me:
$ uname -a
CYGWIN_NT-6.2 VMBERT864 1.7.21(0.266/5/3) 2013-06-11 21:43 x86_64 Cygwin
$ cat > envtest.c <
int
main ()
{
extern char **environ;
printf ("environ: %p first entry: <%s>\n", &environ, environ[0]);
return 0;
}
EOF
$ gcc -o envtest envtest.c
$ ./envtest
environ: 0x1802a4778 first entry:
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Caml-list] problems linking with ocamlopt 4.00.1
On 2013-06-11, at 17:27, Corinna Vinschen wrote: > Ouch! As long as gcc 4.7.2 is not the defualt compiler, that's kind > of borderline since you force people to install the test release of gcc. > > Granted, it's time we get a 4.7 or 4.8 based gcc ASAP... Another solution would be to compile OCaml with the 4.5.3-1 version of the GCC package, if there's any way to do that. OCaml 3.12.1 was compiled with that version and it didn't exhibit the bug. But I didn't find any obvious way to go back to an old package that is not in setup's list anymore. I apologize for unwittingly breaking so many things with this OCaml update. -- Damien -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
BFD library
Hello all, A long time ago, Yaakov wrote: > While you're at it, you could fix the > false negative in the bfd detection[3] by adding -lintl to the > libraries in the second hasgot test. I just tried to do that, but when I #include in any C program, I get an error: /usr/include/bfd.h:37:2: error: #error config.h must be included before this header because bfd.h contains: /* PR 14072: Ensure that config.h is included first. */ #if !defined PACKAGE && !defined PACKAGE_VERSION #error config.h must be included before this header #endif So bfd.h demands that I include a file first, but I have no idea which . I found two in /usr/include, but none of them has anything to do with BFD or binutils, and they don't define PACKAGE or PACKAGE_VERSION anyway. What am I missing? -- Damien -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: __cygwin_environ, __imp_environ, _cur_environ, where is 'environ' symbol?
ok, it seems that newlib/libc/stdlib/environ.c has not made its way
into cygwin1.dll and/or libcygwin.a; shouldn't that be included?
From: Corinna Vinschen
To: cygwin at cygwin dot com
Date: Wed, 12 Jun 2013 11:53:15 +0200
Subject: Re: __cygwin_environ, __imp_environ, _cur_environ, where is
'environ' symbol?
References:
Reply-to: cygwin at cygwin dot com
environ is the exported symbol referencing the internal __cygwin_environ
variable on x86_64. Linking against and accessing it works for me:
$ uname -a
CYGWIN_NT-6.2 VMBERT864 1.7.21(0.266/5/3) 2013-06-11 21:43 x86_64 Cygwin
$ cat > envtest.c <
int
main ()
{
extern char **environ;
printf ("environ: %p first entry: <%s>\n", &environ, environ[0]);
return 0;
}
EOF
$ gcc -o envtest envtest.c
$ ./envtest
environ: 0x1802a4778 first entry:
Corinna
--
Corinna Vinschen Please, send mails regarding Cygwin to
Cygwin Maintainer cygwin AT cygwin DOT com
Red Hat
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
--
Problem reports: http://cygwin.com/problems.html
FAQ: http://cygwin.com/faq/
Documentation: http://cygwin.com/docs.html
Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Do the runtime support the large file 2GB with fstati64 (error: undefined reference to __fstati64 )?
2013/6/10 JonY <10wa...@gmail.com>: > On 6/10/2013 09:11, Lord Flaubert Steve Ataucuri Cruz wrote: >> Folks, >> >> I did some research at mailing list, faq and I didn't seek any >> information about this error . I am trying to build an installer of >> some great tools of linux to windows, but I wanna use and Cygwin >> runtime and Mingw(please don't redirect to another list). I am going >> to explain what I did: >> > > I don't think you can use the original 3.4.x gcc to build setup anymore, > try using the i686 mingw-w64 cross compilers, they can be found in > Cygwin setup. > > Jon Y thanks I will try with mingw-w64 Steve > -- Steve Ataucuri Cruz School of Computer Science, San Pablo Catholic University - Arequipa, Peru (http://www.ucsp.edu.pe), Screen Names : stonescen...@hotmail.com (Windows Live Messenger) stonescen...@gmail.com (Google talk) stonescen...@yahoo.com (Yahoo Messenger) stonescenter (Skype) +51.972529201 (Mobile) -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [Caml-list] problems linking with ocamlopt 4.00.1
On Jun 12 13:51, Damien Doligez wrote: > On 2013-06-11, at 17:27, Corinna Vinschen wrote: > > > Ouch! As long as gcc 4.7.2 is not the defualt compiler, that's kind > > of borderline since you force people to install the test release of gcc. > > > > Granted, it's time we get a 4.7 or 4.8 based gcc ASAP... > > Another solution would be to compile OCaml with the 4.5.3-1 version > of the GCC package, if there's any way to do that. OCaml 3.12.1 was > compiled with that version and it didn't exhibit the bug. > > But I didn't find any obvious way to go back to an old package that > is not in setup's list anymore. Click on the version number of the package. It will cycle through the available versions and other options (like "keep", "reinstall", "uninstall"). > I apologize for unwittingly breaking so many things with this OCaml > update. No worries, stuff like that happens once in a while. I guess we should let this just stay as is for now and see to it that we get a new gcc version soon. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: __cygwin_environ, __imp_environ, _cur_environ, where is 'environ' symbol?
Please, don't http://cygwin.com/acronyms/#TOFU Thank you. On Jun 12 14:12, Vasiliy wrote: > ok, it seems that newlib/libc/stdlib/environ.c has not made its way > into cygwin1.dll and/or libcygwin.a; shouldn't that be included? No. Cygwin implements its own environment handling, entirely apart from newlib's. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: GCC and symlink are incompatibility on 64-bit windows
On Wed, Jun 12, 2013 at 03:13:32PM +1000, Lu Sheng wrote: >Thank you for your help. I currently using official binaries lxml, thanks. Maybe you're not getting this. You are not using an official Cygwin lxml since there is no official Cygwin lxml. If the program isn't built for Cygwin it won't understand Cygwin symlinks. If the program that you are using was built for Cygwin then you should check with the provider of the program and work together to figure out what is going wrong. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
getclip and cygutils and cygcheck
The Cygwin Search page... http://cygwin.com/cgi-bin2/package-grep.cgi?grep=getclip.exe ...indicates that getclip is in cygutils-1.4.12-1 but I've updated ... $ cygcheck -c cygutils Cygwin Package Information Package VersionStatus cygutils 1.4.12-2 OK $ That explains, maybe, why I don't have getclip anymore since my recent update: $ type getclip -bash: type: getclip: not found $ I know things got moved around w.r.t. cygutils recently, but where is getclip? Generating cygcheck output, I get an error: $ cygcheck -svr > cygcheck.out.txt cygcheck: Wrong architecture. Only ix86 executables supported. $ Attached nonetheless: cygcheck.out.txt --Ken Nellis Cygwin Configuration Diagnostics Current System Time: Wed Jun 12 15:29:04 2013 Windows XP Professional Ver 5.1 Build 2600 Service Pack 3 Path: C:\cygwin\usr\local\bin C:\cygwin\bin C:\Program Files\Business Objects\Common\3.5\bin\NOTES C:\Program Files\Business Objects\Common\3.5\bin\NOTES\DATA C:\WINDOWS\system32 C:\WINDOWS C:\WINDOWS\System32\Wbem C:\Program Files\Intel\DMIX C:\Program Files\ATI Technologies\ATI.ACE\Core-Static C:\Program Files\NTRU Cryptosystems\NTRU TCG Software Stack\bin C:\Program Files\Wave Systems Corp\Gemalto\Access Client\v5 C:\Program Files\Common Files\Roxio Shared\DLLShared C:\Program Files\Common Files\Roxio Shared\9.0\DLLShared C:\Program Files\Microsoft SQL Server\90\Tools\binn C:\WINDOWS\system32\WindowsPowerShell\v1.0 C:\Program Files\IBM\RationalSDLC\ClearCase\bin C:\Program Files\IBM\RationalSDLC\common Output from C:\cygwin\bin\id.exe UID: 12779(knellis) GID: 10513(Domain Users) 10513(Domain Users) 0(root) 544(Administrators) 545(Users) SysDir: C:\WINDOWS\system32 WinDir: C:\WINDOWS USER = 'knellis' PWD = '/home/knellis' HOME = '/home/knellis' MANPATH = '/usr/local/man:/usr/share/man:/usr/man::/usr/ssl/man' APPDATA = 'C:\Documents and Settings\knellis\Application Data' HOSTNAME = 'COBQDPPJ1' VIEWTAGFILE = 'C:\DOCUME~1\knellis\MYDOCU~1\data\viewtag' SHELL = '/bin/bash' TERM = 'xterm' PROCESSOR_IDENTIFIER = 'x86 Family 6 Model 23 Stepping 10, GenuineIntel' WINDIR = 'C:\WINDOWS' VS80COMNTOOLS = 'C:\Program Files\Microsoft Visual Studio 8\Common7\Tools\' TISDIR = 'C:\Program Files\IBM\RationalSDLC\common' CLEARQUEST_HOME = 'C:\Program Files\IBM\RationalSDLC\ClearQuest' OLDPWD = '/cygdrive/u' USERDOMAIN = 'TMS' OS = 'Windows_NT' ALLUSERSPROFILE = 'C:\Documents and Settings\All Users' JRE_HOME = 'C:\Program Files\IBM\RationalSDLC\Common\Java5.0\jre' !:: = '::\' COMMONPROGRAMFILES = 'C:\Program Files\Common Files' IBMLDAP_ALTHOME = 'C:\Program Files\IBM\RationalSDLC\common\codeset' QNX_PASSWORD = 'xyz' PROCESSOR_LEVEL = '6' PSModulePath = 'C:\WINDOWS\system32\WindowsPowerShell\v1.0\Modules\' FP_NO_HOST_CHECK = 'NO' SYSTEMDRIVE = 'C:' NGVTU_PROJECT = 'SMARTMDT_BLD16_KNELLIS_DEV' JAVA_HOME = 'C:\Program Files\Java\jre6' LANG = 'C.UTF-8' USERPROFILE = 'C:\Documents and Settings\knellis' QNX_MACHINE = 'vqnx77' TZ = 'America/New_York' QNX_USERNAME = 'knellis' PS1 = '$ ' LOGONSERVER = '\\TMSACSDC2' CLEARCASE_PRIMARY_GROUP = 'clearusers' !U: = 'U:\' PROCESSOR_ARCHITECTURE = 'x86' SHLVL = '1' USERDNSDOMAIN = 'TMS.LOCAL' PATHEXT = '.COM;.EXE;.BAT;.CMD;.VBS;.VBE;.JS;.JSE;.WSF;.WSH;.PSC1' COMSPEC = 'C:\WINDOWS\system32\cmd.exe' TMP = '/tmp' SYSTEMROOT = 'C:\WINDOWS' PRINTER = '\\tmsdc2\TMSCustomerService' PROCESSOR_REVISION = '170a' CLASSPATH = 'C:\Program Files\IBM\RationalSDLC\ClearQuest\cqjni.jar' INFOPATH = '/usr/local/info:/usr/share/info:/usr/info:' PROGRAMFILES = 'C:\Program Files' HOMESHARE = '\\tmsmain\home\n\knellis' NUMBER_OF_PROCESSORS = '2' VSEDEFLOGDIR = 'C:\Documents and Settings\All Users\Application Data\McAfee\DesktopProtection' SESSIONNAME = 'Console' _ = '/usr/bin/cygcheck' HKEY_CURRENT_USER\Console\Cygwin.bat (default) = 0x0007 PopupColors = 0x00f5 ColorTable00 = 0x ColorTable01 = 0x0080 ColorTable02 = 0x8000 ColorTable03 = 0x00808000 ColorTable04 = 0x0080 ColorTable05 = 0x00800080 ColorTable06 = 0x8080 ColorTable07 = 0x00c0c0c0 ColorTable08 = 0x00808080 ColorTable09 = 0x00ff ColorTable10 = 0xff00 ColorTable11 = 0x0000 ColorTable12 = 0x00ff ColorTable13 = 0x00ff00ff ColorTable14 = 0x ColorTable15 = 0x00ff InsertMode = 0x0001 QuickEdit = 0x FullScreen = 0x ScreenBufferSize = 0x012c0050 WindowSize = 0x00190050 FontSize = 0x FontFamily = 0x FontWeight = 0x FaceName = '' CursorSize = 0x0019 HistoryBufferSize = 0x0032 NumberOfHistoryBuffers = 0x0004 HistoryNoDup = 0x HKEY_CURRENT_USER\Software\Cygwin HKEY_CURRENT_USER\Software\Cygwin\Program Options HKEY_CURRENT_USER\Software\Cygwin\setup HKEY_CURRENT_USER\Software\Microsoft\Wind
RE: getclip and cygutils and cygcheck
(Several attempts here. Got my address blocked somehow. Sorry if duplicates appear. Not my day.) Sorry for the noise...getclip is in cygutils-extra (duh!), but the cygcheck error is still interesting maybe. --KN -Original Message- The Cygwin Search page... http://cygwin.com/cgi-bin2/package-grep.cgi?grep=getclip.exe ...indicates that getclip is in cygutils-1.4.12-1 but I've updated ... $ cygcheck -c cygutils Cygwin Package Information Package VersionStatus cygutils 1.4.12-2 OK $ That explains, maybe, why I don't have getclip anymore since my recent update: $ type getclip -bash: type: getclip: not found $ I know things got moved around w.r.t. cygutils recently, but where is getclip? Generating cygcheck output, I get an error: $ cygcheck -svr > cygcheck.out.txt cygcheck: Wrong architecture. Only ix86 executables supported. $ Attached nonetheless: cygcheck.out.txt --Ken Nellis -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: getclip and cygutils and cygcheck
On Jun 12 15:21, Nellis, Kenneth wrote: > (Several attempts here. Got my address blocked somehow. > Sorry if duplicates appear. Not my day.) > > Sorry for the noise...getclip is in cygutils-extra (duh!), > but the cygcheck error is still interesting maybe. Nothing to worry about. Cygcheck prints that when it finds a non-32 bit binary, like cyglsa64.dll. Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [64bit] Xlib.h not available in cross-compile-to-self usage
On 2013-06-12 02:37, Arthur Norman wrote: On a 32-bit cygwin I get $ uname -a CYGWIN_NT-6.1-WOW64 panamint 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin $ find /usr -name Xlib.h -print /usr/include/X11/Xlib.h /usr/x86_64-pc-cygwin/sys-root/usr/include/X11/Xlib.h /usr/lib/perl5/vendor_perl/5.14/i686-cygwin-threads-64int/Tk/pTk/Xlib.h and using either gcc or x86_64-pc-cygwin-gcc I can build X apps, but if I use i686-pc-cygwin-gcc I have some of the X headers but not (eg) Xlib.h. Correct; there is no cygwin32-libX11 for x86_64 yet. What are you trying to cross-compile, and what other libraries do you think you are going to need? Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: BFD library
On 2013-06-12 06:53, Damien Doligez wrote: A long time ago, Yaakov wrote: While you're at it, you could fix the false negative in the bfd detection[3] by adding -lintl to the libraries in the second hasgot test. http://cygwin.com/ml/cygwin/2011-12/msg00397.html Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SQLite temporary path creation broken in latest stable release
On 6/11/2013 18:19, Andrey Repin wrote: None of the SQLite core developers have responded to my charge that this looks like a bug in SQLite. It shouldn't be generating temporary file names with backslashes in them for Cygwin builds... There's no reason to ever use backslashes in paths, ever. I suspect it is an interaction between #ifdef WINDOWS == true and the cygwinTempPath() hack patched into that version. The mainline SQLite code doesn't realize we've played a bit of sleight of hand with it, so it fails when it wants to add a second level to its temporary storage hierarchy. If true, that's yet another reason to switch to 3.7.17: I removed the hack since we're building as SQLITE_OS_UNIX. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
[GOLDSTAR] Re: [PATCH] Check for existence of the path before processing '..'
Hi Fedin, On Jun 11 17:08, Fedin Pavel wrote: > Hello! > > Some time ago i reported ability to access things like > "/usr/nonexistent/..bin". I still had this problem and i tried my hands on > fixing it. > The patch works by checking the actual existence of the path before > removing the last component from it. For performance reasons, only one check > is done for things like "../..". Because, obviously, if "/foo/bar/baz" > exists, then "/foo/bar" exists too. Also, the check is done only after some > components have been added to the path. So, for example, current directory > (obtained when processing relative paths), will not be checked. > I tried to add a similar test also to normalize_win32_path() function, > however this broke things like "cd /usr/src/..". For some reason, a POSIX > version of the path (but with reversed slashes) is passed to this routine > when expanding mount points, so, consequently, test for "\usr\src" using > GetFileType() fails. > I think it's ok, at least POSIX paths now behave in POSIX way. I have > tested against performance, there is some loss (~0.2 seconds), but only for > referencing '..'. > With this patch i am able to compile the latest version of glibc with no > problems. I applied your patch with a little stretch of imagination as falling under the trivial patch rule, which doesn't require a copyright assignment. I only tweaked it slightly since I found that moving the setting of check_parent has a tiny performance advantage. Cgf and I talked privately about this patch and we're both happy you found such a simple solution to fix a long-standing problem. Sometimes, when you're working long enough on some code, you just miss to see the wood for the trees. Andrew, can you please polish one of the goldstar's in your vault and give it to Fedin? Btw., Fedin, even if I let this go in under the trivial patch rule, it would be very nice if you could fill out the Cygwin copyright assignment form http://cygwin.com/assign.txt and send it to the given address. This allows you to provide any length of patch in future. Thanks again, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: getclip and cygutils and cygcheck
On Wed, Jun 12, 2013 at 03:21:09PM +, Nellis, Kenneth wrote: >(Several attempts here. Got my address blocked somehow. You were not blocked. You were using raw email addresses in the body of your message and not reading the bounce message which apprised you of that fact. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building latest CVS fails
On 6/12/2013 2:46 AM, Corinna Vinschen wrote: > On Jun 11 17:53, Daniel Colascione wrote: >> g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem >> /users/dancol/software/cygwin/winsup/cygwin/include >> -B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem >> /users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-include -isystem >> /users/dancol/software/cygwin/newlib/libc/include-o dumper.exe dumper.o >> module_info.o parse_pe.o >> -B/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin/ -static >> -Wl,--enable-auto-import -L/usr/lib/w32api -lnetapi32 -ladvapi32 -lkernel32 >> -luser32 -lbfd -lintl -liconv -liberty -lz >> c++wrap -c -o cygcheck.o -fno-exceptions -fno-rtti -O2 -g >> ../../.././winsup/utils/cygcheck.cc >> c++wrap -c -o bloda.o -fno-exceptions -fno-rtti -O2 -g >> ../../.././winsup/utils/bloda.cc >> c++wrap -c -o path.o -fno-exceptions -fno-rtti -O2 -g >> ../../.././winsup/utils/path.cc >> c++wrap -c -o dump_setup.o -fno-exceptions -fno-rtti -O2 -g >> ../../.././winsup/utils/dump_setup.cc >> ../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such >> file >> or directory > > Try `CCWRAP_VERBOSE=1 make' to see the full command line. + i686-w64-mingw32-g++ -nostdinc++ -nostdinc -I../../.././winsup/utils -isystem /lib/gcc/i686-w64-mingw32/4.5.3/include/c++ -isystem /lib/gcc/i686-w64-mingw32/4.5.3/include/c++/i686-w64-mingw32 -isystem /lib/gcc/i686-w64-mingw32/4.5.3/include/c++/backward -isystem /lib/gcc/i686-w64-mingw32/4.5.3/include -isystem /lib/gcc/i686-w64-mingw32/4.5.3/include-fixed -isystem /usr/i686-w64-mingw32/sys-root/mingw/include -c -o dump_setup.o -fno-exceptions -fno-rtti -O2 -g ../../.././winsup/utils/dump_setup.cc ../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such file or directory > >> ~/software/cygwin >> $ uname -a >> CYGWIN_NT-6.1-WOW64 xyzzy 1.7.20(0.266/5/3) 2013-06-07 11:11 i686 Cygwin > > $ cygcheck -f /usr/include/zlib.h > zlib-devel-1.2.8-1 $ cygcheck -c zlib-devel Cygwin Package Information Package VersionStatus zlib-devel 1.2.8-1OK signature.asc Description: OpenPGP digital signature
Re: SQLite temporary path creation broken in latest stable release
Warren Young writes: > If true, that's yet another reason to switch to 3.7.17: I removed the > hack since we're building as SQLITE_OS_UNIX. I can attest that this solves the problem with temp files, as expected. I'm sorry, but I haven't been able to do much else with that test version. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ SD adaptations for KORG EX-800 and Poly-800MkII V0.9: http://Synth.Stromeko.net/Downloads.html#KorgSDada -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building latest CVS fails
On Wed, Jun 12, 2013 at 11:06:15AM -0700, Daniel Colascione wrote: >On 6/12/2013 2:46 AM, Corinna Vinschen wrote: >> On Jun 11 17:53, Daniel Colascione wrote: >>> g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem >>> /users/dancol/software/cygwin/winsup/cygwin/include >>> -B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem >>> /users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-include -isystem >>> /users/dancol/software/cygwin/newlib/libc/include-o dumper.exe dumper.o >>> module_info.o parse_pe.o >>> -B/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin/ -static >>> -Wl,--enable-auto-import -L/usr/lib/w32api -lnetapi32 -ladvapi32 -lkernel32 >>> -luser32 -lbfd -lintl -liconv -liberty -lz >>> c++wrap -c -o cygcheck.o -fno-exceptions -fno-rtti -O2 -g >>> ../../.././winsup/utils/cygcheck.cc >>> c++wrap -c -o bloda.o -fno-exceptions -fno-rtti -O2 -g >>> ../../.././winsup/utils/bloda.cc >>> c++wrap -c -o path.o -fno-exceptions -fno-rtti -O2 -g >>> ../../.././winsup/utils/path.cc >>> c++wrap -c -o dump_setup.o -fno-exceptions -fno-rtti -O2 -g >>> ../../.././winsup/utils/dump_setup.cc >>> ../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such >>> file >>> or directory >> >> Try `CCWRAP_VERBOSE=1 make' to see the full command line. > >+ i686-w64-mingw32-g++ -nostdinc++ -nostdinc -I../../.././winsup/utils -isystem >/lib/gcc/i686-w64-mingw32/4.5.3/include/c++ -isystem >/lib/gcc/i686-w64-mingw32/4.5.3/include/c++/i686-w64-mingw32 -isystem >/lib/gcc/i686-w64-mingw32/4.5.3/include/c++/backward -isystem >/lib/gcc/i686-w64-mingw32/4.5.3/include -isystem >/lib/gcc/i686-w64-mingw32/4.5.3/include-fixed -isystem >/usr/i686-w64-mingw32/sys-root/mingw/include -c -o dump_setup.o -fno-exceptions >-fno-rtti -O2 -g ../../.././winsup/utils/dump_setup.cc >../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such file >or directory Isn't this obviously a problem with you not having a mingw-version of zlib.h? Have you installed mingw64-i686-zlib? CVS *is* building and there are snapshots to prove it. cgf -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: Building latest CVS fails
On 6/12/2013 11:44 AM, Christopher Faylor wrote: > On Wed, Jun 12, 2013 at 11:06:15AM -0700, Daniel Colascione wrote: >> On 6/12/2013 2:46 AM, Corinna Vinschen wrote: >>> On Jun 11 17:53, Daniel Colascione wrote: g++ -L/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin -isystem /users/dancol/software/cygwin/winsup/cygwin/include -B/users/dancol/software/cygwin/i686-pc-cygwin/newlib/ -isystem /users/dancol/software/cygwin/i686-pc-cygwin/newlib/targ-include -isystem /users/dancol/software/cygwin/newlib/libc/include-o dumper.exe dumper.o module_info.o parse_pe.o -B/users/dancol/software/cygwin/i686-pc-cygwin/winsup/cygwin/ -static -Wl,--enable-auto-import -L/usr/lib/w32api -lnetapi32 -ladvapi32 -lkernel32 -luser32 -lbfd -lintl -liconv -liberty -lz c++wrap -c -o cygcheck.o -fno-exceptions -fno-rtti -O2 -g ../../.././winsup/utils/cygcheck.cc c++wrap -c -o bloda.o -fno-exceptions -fno-rtti -O2 -g ../../.././winsup/utils/bloda.cc c++wrap -c -o path.o -fno-exceptions -fno-rtti -O2 -g ../../.././winsup/utils/path.cc c++wrap -c -o dump_setup.o -fno-exceptions -fno-rtti -O2 -g ../../.././winsup/utils/dump_setup.cc ../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such file or directory >>> >>> Try `CCWRAP_VERBOSE=1 make' to see the full command line. >> >> + i686-w64-mingw32-g++ -nostdinc++ -nostdinc -I../../.././winsup/utils >> -isystem >> /lib/gcc/i686-w64-mingw32/4.5.3/include/c++ -isystem >> /lib/gcc/i686-w64-mingw32/4.5.3/include/c++/i686-w64-mingw32 -isystem >> /lib/gcc/i686-w64-mingw32/4.5.3/include/c++/backward -isystem >> /lib/gcc/i686-w64-mingw32/4.5.3/include -isystem >> /lib/gcc/i686-w64-mingw32/4.5.3/include-fixed -isystem >> /usr/i686-w64-mingw32/sys-root/mingw/include -c -o dump_setup.o >> -fno-exceptions >> -fno-rtti -O2 -g ../../.././winsup/utils/dump_setup.cc >> ../../.././winsup/utils/dump_setup.cc:26:18: fatal error: zlib.h: No such >> file >> or directory > > Isn't this obviously a problem with you not having a mingw-version of > zlib.h? Have you installed mingw64-i686-zlib? Oh, yes. Of course. Thanks. Installing the *mingw* zlib allows the build to progress --- it then fails with the "bad register name" error, but I'll look into refreshing my compiler packages. > > CVS *is* building and there are snapshots to prove it. I thought the snapshots were cross-compiled: I thought that the build might have been broken only on Cygwin builds. signature.asc Description: OpenPGP digital signature
cygpath problem
Hi everybody! I have a question about using cygpath. Trying to get windows paths in different locations alexey@78CE /cygdrive/c $ cygpath -w . . alexey@78CE /cygdrive/c $ cygpath -w /cygdrive/c C:\ alexey@78CE /cygdrive/c $ cd /home alexey@78CE /home $ cygpath -w . C:\Test\cross32\home\ As I see I cant properly get windows path if I try to get it on current directory that contain /cygdrive prefix. Is it feature or bug? Regards, Alexey. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: cygpath problem
On Jun 12 22:15, Алексей Павлов wrote: > Hi everybody! > > I have a question about using cygpath. > Trying to get windows paths in different locations > > alexey@78CE /cygdrive/c > $ cygpath -w . > . > alexey@78CE /cygdrive/c > $ cygpath -w /cygdrive/c > C:\ > alexey@78CE /cygdrive/c > $ cd /home > alexey@78CE /home > $ cygpath -w . > C:\Test\cross32\home\ > > As I see I cant properly get windows path if I try to get it on > current directory that contain /cygdrive prefix. > > > Is it feature or bug? Try the -a (for "absolute") flag: $ cygpath -wa . C:\cygwin64\home\corinna Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [GOLDSTAR] Re: [PATCH] Check for existence of the path before processing '..'
On Jun 12 19:46, Corinna Vinschen wrote: > Hi Fedin, > > On Jun 11 17:08, Fedin Pavel wrote: > > Hello! > > > > Some time ago i reported ability to access things like > > "/usr/nonexistent/..bin". I still had this problem and i tried my hands on > > fixing it. > > The patch works by checking the actual existence of the path before > > removing the last component from it. For performance reasons, only one check > > is done for things like "../..". Because, obviously, if "/foo/bar/baz" > > exists, then "/foo/bar" exists too. Also, the check is done only after some > > components have been added to the path. So, for example, current directory > > (obtained when processing relative paths), will not be checked. > > I tried to add a similar test also to normalize_win32_path() function, > > however this broke things like "cd /usr/src/..". For some reason, a POSIX > > version of the path (but with reversed slashes) is passed to this routine > > when expanding mount points, so, consequently, test for "\usr\src" using > > GetFileType() fails. > > I think it's ok, at least POSIX paths now behave in POSIX way. I have > > tested against performance, there is some loss (~0.2 seconds), but only for > > referencing '..'. > > With this patch i am able to compile the latest version of glibc with no > > problems. > > I applied your patch with a little stretch of imagination as falling > under the trivial patch rule, which doesn't require a copyright > assignment. I only tweaked it slightly since I found that moving the > setting of check_parent has a tiny performance advantage. FYI, I just uploaded a new 32 bit snapshot, as well as the 64 bit test package 1.7.21-2 containing this patch. Please give it a try. Thanks, Corinna -- Corinna Vinschen Please, send mails regarding Cygwin to Cygwin Maintainer cygwin AT cygwin DOT com Red Hat -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: getclip and cygutils and cygcheck
Am 12.06.2013 17:21, schrieb Nellis, Kenneth: ... where is getclip? Whereever it actually is, shouldn't it be deprecated or removed since it does not handle non-ASCII characters? I think I already suggested a replacement once before which was a simple shell script wrapper to /dev/clipboard. -- Thomas -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SQLite temporary path creation broken in latest stable release
On 6/12/2013 12:13, Achim Gratz wrote: Warren Young writes: If true, that's yet another reason to switch to 3.7.17: I removed the hack since we're building as SQLITE_OS_UNIX. I can attest that this solves the problem with temp files, as expected. Thanks for testing! I'm sorry, but I haven't been able to do much else with that test version. I'm partially waiting to push this test release to curr on your behalf. I expect that with CYGWIN_SQLITE_LOCKING=posix, you will be able to stop using your local version of sqlite3. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SQLite temporary path creation broken in latest stable release
Warren Young writes: > I'm partially waiting to push this test release to curr on your > behalf. I expect that with CYGWIN_SQLITE_LOCKING=posix, you will be > able to stop using your local version of sqlite3. I've actually built a 3.7.17 version that has been sitting around untested for a while do to other work. I'll replace it with your test version when I get around to actually do the testing. I don't really expect any problems, so if you'd rather flip the switch on the test version sooner, please go ahead. Regards, Achim. -- +<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+ Factory and User Sound Singles for Waldorf Blofeld: http://Synth.Stromeko.net/Downloads.html#WaldorfSounds -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: SQLite temporary path creation broken in latest stable release
Greetings, Warren Young! >>> None of the SQLite core developers have responded to my charge that this >>> looks like a bug in SQLite. It shouldn't be generating temporary file >>> names with backslashes in them for Cygwin builds... >> >> There's no reason to ever use backslashes in paths, ever. > I suspect it is an interaction between #ifdef WINDOWS == true and the > cygwinTempPath() hack patched into that version. The mainline SQLite > code doesn't realize we've played a bit of sleight of hand with it, so > it fails when it wants to add a second level to its temporary storage > hierarchy. > If true, that's yet another reason to switch to 3.7.17: I removed the > hack since we're building as SQLITE_OS_UNIX. I was referring to the fact, that Windows IO functions do not see a difference between forward and backward slashes. If you intend to write cross-platform application, you better off using forward slashes internally in all cases. -- WBR, Andrey Repin (anrdae...@freemail.ru) 13.06.2013, <00:28> Sorry for my terrible english... -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: pty issue causes 'screen' to hang when run from mintty as detached
If you read the response from the mintty author in the support ticket linked in the original post you'll see: "There've been various issues with pseudo terminal (pty) layer in the Cygwin 1.7.19 release, which apparently haven't been fully addressed in 1.7.20. Mintty is based on that pty layer, along with other terminals such as rxvt or xterm, whereas the Windows console window you get through cygstart is not." I've tested it with several versions of Cygwin all the way back to 1.7.7. It might be worth following up with the author through the support ticket yourself, as he seems to believe that the error lies with Cygwin's pty and cannot be fixed in mintty. On 6/10/2013 10:53 PM, Andrew Schulman wrote: $ screen -S name -d -m $ screen -S name -x Remove dead screens with 'screen -wipe'. $ Sorry, typed by hand, corrected above. -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [64bit] Xlib.h not available in cross-compile-to-self usage
Thanks. I am building the code from reduce-algebra.sourceforge.net and in particular updating the build system there so that anybody who fetches will be able to build. The part that I am mostly concerned with uses either the FOX toolkit for its GUI stuff or wxWidgets (each built from source) so in the native cygwin case that is just a bunch of X11 stuff with Xft, Xrandr, fontconfig and the like. At present I can build a 32-bit set of binaries if I am using a 32-bit cygwin shell and compile using just "gcc" (rather than trying i686-pc-cygwin-gcc which exists but its sys-root is less populated) and I can build a 64-bit one if I use a 64-bit cygwin shell. But eventually it would feel tidy to be able to build i686-cygwin, x86_64-cygwin, i686-mingw32 and x86_64-mingw binaries all using just one host machine - and at present I can do that if I do not try to build the GUI versions. So I can in fact build all I want at present - but I have to build some versions from a 32-bit cygwin shell and some from a 64-bit one, and the facility that arises using "--host=i686-pc-cygwin" on a 32-bit cygwin platform exists enough to feel tempting (to leave me a set of build scripts consistent wherever I run them) but is unexpectedly deficient compared to omitting the "--host" - and ditto in the 64-bit world. So my note here is more a note of incompleteness and a hope that eventually eveything that can be built by plain "gcc" on regugar 32-bit cygwin will be buildable using either i686-pc-cygwin-gcc or x86_64-pc-cygwin-gcc - with X11, Xft, Xranrd, fontconfig being the components I am most waiting for but not feeling a need to make my request an urgent one! Arthur -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
LDD blocking
Trying to figure out why Ruby/openssl.so are not working under Cygwin, I realized recently that cygcheck openssl.so works properly: $ cygcheck.exe /usr/lib/ruby/1.9.1/i386-cygwin/openssl.so C:\Progra~1\Cygwin\lib\ruby\1.9.1\i386-cygwin\openssl.so C:\Progra~1\Cygwin\bin\cygruby191.dll C:\Progra~1\Cygwin\bin\cygcrypt-0.dll C:\Progra~1\Cygwin\bin\cygwin1.dll C:\Windows\system32\KERNEL32.dll C:\Windows\system32\ntdll.dll C:\Progra~1\Cygwin\bin\cyggcc_s-1.dll C:\Windows\system32\USER32.dll C:\Windows\system32\GDI32.dll C:\Windows\system32\ADVAPI32.dll C:\Windows\system32\RPCRT4.dll C:\Progra~1\Cygwin\bin\cygcrypto-1.0.0.dll C:\Progra~1\Cygwin\bin\cygz.dll C:\Progra~1\Cygwin\bin\cygssl-1.0.0.dll **HOWEVER** ldd never returns: $ ldd /usr/lib/ruby/1.9.1/i386-cygwin/openssl.so The only differences I can see between the two machines are: 1) The non-working machine is accessed by ssh; and 2) The non-working machine was originally built about a year ago (my dev machine, where it works, was built a few weeks ago). What would cause ldd to block and not return? How can I figure out where the dependency chain is breaking, or if there is a revision conflict with one of the libraries? TIA! Lee -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [GOLDSTAR] Re: [PATCH] Check for existence of the path before processing '..'
> Cgf and I talked privately about this patch and we're both happy you > found such a simple solution to fix a long-standing problem. Sometimes, > when you're working long enough on some code, you just miss to see the > wood for the trees. > > Andrew, can you please polish one of the goldstar's in your vault and > give it to Fedin? Awarded! http://cygwin.com/goldstars/#FP -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [ANNOUNCEMENT] [TEST] sqlite3-3.7.17-3
On 2013-06-11 09:59, Warren Young wrote: If you have had problems in the past with SQLite interoperability with native Windows programs, please test with this new release. You shouldn't have to do anything to test its interoperability with native Windows programs. If your interop problems were with other Cygwin programs, then you want to set the new CYGWIN_SQLITE_LOCKING environment variable to "posix". (Case doesn't matter.) This will suppress Cygwin SQLite's call to the new Cygwin API, so it behaves like a stock Unix mode build. FYI, 3.7.13-3 fixes mtn clone without having to set CYGWIN_SQLITE_LOCKING. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
Re: [64bit] Xlib.h not available in cross-compile-to-self usage
On 2013-06-12 17:51, Arthur Norman wrote: Thanks. I am building the code from reduce-algebra.sourceforge.net and in particular updating the build system there so that anybody who fetches will be able to build. The part that I am mostly concerned with uses either the FOX toolkit for its GUI stuff or wxWidgets (each built from source) FYI, both of these are available in Ports for i686-cygwin and *-mingw; I haven't got that far yet for x86_64-cygwin. If there is interest, I would be willing to move any of these into the distro. So my note here is more a note of incompleteness and a hope that eventually eveything that can be built by plain "gcc" on regugar 32-bit cygwin will be buildable using either i686-pc-cygwin-gcc or x86_64-pc-cygwin-gcc - with X11, Xft, Xranrd, fontconfig being the components I am most waiting for but not feeling a need to make my request an urgent one! Not that everything can be cross-compiled, but I understand that those with 64-bit machines are going to want to use x64 as much as possible. How far we go with the cygwin32-* and cygwin64-* packages will depend on demand, but is it entirely feasible to do at some point. Yaakov -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
RE: [PATCH] Check for existence of the path before processing '..'
Hello! Sorry for delayed replies, at home i'm not subscribed to Cygwin ML, and in Russia we had a holiday yesterday. > Thanks for the patch. The idea sounds good, and I think it's the right > thing to do *not* to add this to normalize_win32_path, because the .. > semantics on WINdows are so that a .. is allowed even if the parent > doesn't exist. Yes, i agree. After all, POSIX rules apply to POSIX paths. And having Win32 paths in POSIX environment is kind of supernatural. :) > I didn't test your patch so far, but I'm a bit puzzled about your > performance claim: ~0.2 secs compared to what? What's your test case? I don't remember exactly, but i've done something like 'time ls -l ../bin' after cd'ing to /usr/src. > I mean, this tiny code snippet can't take 0.2 secs per single call, Yes, but: 1. From strace it seems that 'ls -l' fstat()s every file with file name appended to the given path. And each file gets '..' in its path. 2. Path conversion implies reading mount tables, symlinks, etc. I tried to imagine how this could be optimized, but found no simple solution. Because in general case this should also work for things like '/mnt/drive1/../symlink2/../drive3', across all mounts and symlinks. So, this solution is kind of balance between performance and simplicity. Actually, this even can be optimized by implementing a part-by-part path conversion, for example (imagine we get /usr/src/../bin as argument): 1. Start conversion until we meet '..'. Remember this place. 2. Convert '/usr/src' to Windows format, get 'C:\cygwin64\usr\src'. 3. Check for existence. 4. Step one component back in Win32 path, get 'C:\cygwin64\usr'. 5. Proceed with conversion from the point remembered in (1), the part of path is already converted and checked, we don't need to re-convert it. But this approach would really require total overhaul of all the path handling which is difficult. Kind regards, Pavel Fedin Expert Engineer Samsung Electronics Research center Russia -- Problem reports: http://cygwin.com/problems.html FAQ: http://cygwin.com/faq/ Documentation: http://cygwin.com/docs.html Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple
