perl update?
Reini, This is a followup to http://cygwin.com/ml/cygwin-apps/2013-06/msg00152.html Are you planning a perl update in the near future? I'm starting to work on TeX Live 2014, and it would be nice to be able to include the current version of biber (and biblatex). With perl-5.14, I have to ship biber-1.5. Upstream biber is now three releases later, at 1.8. Thanks. Ken
SSH key for upload access
Name: Michael Wild Package: tmux BEGIN SSH2 PUBLIC KEY B3NzaC1yc2EDAQABAAACAQDXSw+vo3bC3xBiXB+q1csKoosY29+t1Rcs1Lu4mp DmZ2gYRqSHkGeFTXtCeAsC+QfwoNzQwvU3/IHUyxZQxREZbBkaNdYM86Ys7+kpcOAUABOo +aFersL24CcmirhyWorjfI13bLmviu52XUqKd5VKjNAV5J00iQSUVr+xhcVprpeNg9/wWn NIuHPB/kmj/tAnK+Ssqx1MWpE+EicXam9FS9/8DGTuW6aTI4mm2aMDj3tdZmS+QO9L/RaU 9S9X+aHxzD101DgrtJjCHBA/aJ7Lv9NSNXdhGasSkIRMESVqyCw6+fXl3Xqb5qIKuLijs0 AvYCO5Iwx3xjlOwWrxIsDElumrDvNaSRomgb0q7Czwx2KBLWrc0qTR3GuJBCdbB7BTtUK1 fn3S3lu5+g40cfYCTekBAhoJrR3beOH9v/LYZNphfzRwXRmOcoldvChMKzqW+VJ+chi0/C qY9TCo9nc1sKcTnyHpAwKuAm3tzo+4WktQ93OeezcwvPWNWoh16K4BYkG6OBkGaSsSc+3O LV0a1kvEquMDcYBWj7j1FUeWI2U28Ns/HBnb/NluK59hFHC8PoJ2zkViRgYVlpkWb9+0KW uSKEX6pHz144juVvs5tCFXBJl1RJ5WokxXbAjwKy9fNk8pEFNZ1bz3j1RhB0O0coO5uzz+ TPbyVOvT6Zwraw== END SSH2 PUBLIC KEY
Re: Unpacking 7z archives on Cygwin64
On 02/03/14 07:26, Tony Kelman wrote: I'm still not clear, do 64 bit packages have their own independent set of patches, or is it necessary to write patches that work for both 32 bit and 64 bit? This is really up to the package maintainer. Personally, I prefer to have one cygport file and patch set that builds both sources. I test uname(1) if I need something specific for one architecture. This means that I can keep my cygport files and patches in version control and have two instances checked out, one for each architecture. It also means that the source tarball is generic. The downside is that I can't cross-compile. However, I'm sure that there are a number of maintainers who will do things differently. On the subject of maintainers, p7zip does have one; it is really up to Mr. Wilson to prepare a 64-bit version whenever he is ready to do so. I'm sure he'll appreciate the work that you've done in getting this far. That said, we have precedent for some 'non-maintainer uploads' for 64-bit, just to make up the numbers and fill some important gaps. Cheers, Dave. -- 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: Unpacking 7z archives on Cygwin64
Tony Kelman wrote: it would be nice to remove p7zip from http://cygwin.com/cygwin-64bit-missing regardless. Indeed! There is another nice package like atool which needs p7zip... I reported the inquiry about the 64 bit assembly upstream [...] Your work is very useful. Thanks for doing this. Ciao, Angelo. -- 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: Help with shortcuts
Greetings, Mike Rushton! Well thanks I will have to try that. My only other option was to create a menu and execute in from my profile ... and instead of shortcuts ... they would be options off a menu. I also found out you can create symbolic links under Win 7, WIn XP (you must download this Junction Program) You can create native symlinks under WinXP, but they are not usable. and also do this under various Unix/Linux versions. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 14:40 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
Unable to update svn to 1.8.8.1
Hi All, I am using setup-x86_64.exe and choosing the latest SVN clients: http://i.imgur.com/TUyRyAq.png But after installing (and a reboot), SVN still shows up as the old version. Sun Mar 02 - 10:26 PM svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 It doesn't appear to be aliases anywhere else.. Sun Mar 02 - 10:30 PM type svn svn is hashed (/usr/bin/svn) Sun Mar 02 - 10:30 PM which svn /usr/bin/svn Any idea what I am doing wrong? Rob :) -- 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: Unable to update svn to 1.8.8.1
Greetings, Robert Mark! I am using setup-x86_64.exe and choosing the latest SVN clients: http://i.imgur.com/TUyRyAq.png But after installing (and a reboot), SVN still shows up as the old version. Sun Mar 02 - 10:26 PM svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 It doesn't appear to be aliases anywhere else.. Sun Mar 02 - 10:30 PM type svn svn is hashed (/usr/bin/svn) Sun Mar 02 - 10:30 PM which svn /usr/bin/svn Any idea what I am doing wrong? Should be /bin/svn There's no separate /usr/bin in Cygwn. Most likely, you're looking at the wrong place. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 15:54 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: Unable to update svn to 1.8.8.1
/bin/svn is the old version too... Sun Mar 02 - 11:43 PM /bin/svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 On Sun, Mar 2, 2014 at 10:55 PM, Andrey Repin anrdae...@yandex.ru wrote: Greetings, Robert Mark! I am using setup-x86_64.exe and choosing the latest SVN clients: http://i.imgur.com/TUyRyAq.png But after installing (and a reboot), SVN still shows up as the old version. Sun Mar 02 - 10:26 PM svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 It doesn't appear to be aliases anywhere else.. Sun Mar 02 - 10:30 PM type svn svn is hashed (/usr/bin/svn) Sun Mar 02 - 10:30 PM which svn /usr/bin/svn Any idea what I am doing wrong? Should be /bin/svn There's no separate /usr/bin in Cygwn. Most likely, you're looking at the wrong place. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 15:54 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: Unable to update svn to 1.8.8.1
Oh, I think I see what I have done - I seem to have both C:\cygwin64 and C:\cygwin installed. :/ On Sun, Mar 2, 2014 at 11:44 PM, Robert Mark robertmarkbram.li...@gmail.com wrote: /bin/svn is the old version too... Sun Mar 02 - 11:43 PM /bin/svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 On Sun, Mar 2, 2014 at 10:55 PM, Andrey Repin anrdae...@yandex.ru wrote: Greetings, Robert Mark! I am using setup-x86_64.exe and choosing the latest SVN clients: http://i.imgur.com/TUyRyAq.png But after installing (and a reboot), SVN still shows up as the old version. Sun Mar 02 - 10:26 PM svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 It doesn't appear to be aliases anywhere else.. Sun Mar 02 - 10:30 PM type svn svn is hashed (/usr/bin/svn) Sun Mar 02 - 10:30 PM which svn /usr/bin/svn Any idea what I am doing wrong? Should be /bin/svn There's no separate /usr/bin in Cygwn. Most likely, you're looking at the wrong place. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 15:54 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: Unable to update svn to 1.8.8.1
Greetings, Robert Mark! I am using setup-x86_64.exe and choosing the latest SVN clients: http://i.imgur.com/TUyRyAq.png But after installing (and a reboot), SVN still shows up as the old version. Sun Mar 02 - 10:26 PM svn --version svn, version 1.7.6 (r1370777) compiled Aug 22 2012, 15:38:04 It doesn't appear to be aliases anywhere else.. Sun Mar 02 - 10:30 PM type svn svn is hashed (/usr/bin/svn) Sun Mar 02 - 10:30 PM which svn /usr/bin/svn Any idea what I am doing wrong? Should be /bin/svn There's no separate /usr/bin in Cygwn. Oh, I think I see what I have done - I seem to have both C:\cygwin64 and C:\cygwin installed. :/ Most likely, you're looking at the wrong place. ^ Also, please don't http://cygwin.com/acronyms/#TOFU -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 17:05 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: Testers needed: New passwd/group handling in Cygwin
2014-02-28 22:08 GMT+01:00 Corinna Vinschen: That's not really a problem but a case of it is as it is. To get the user and group info, Cygwin has to contact the DC and/or GC and then runs into a timeout. Right now, the LDAP timeout is set to 3 seconds. I don't know yet if it's such a bright idea to lower this timeout value. I understand why it happens. And three seconds are not the problem. It is just a bit confusing to activate the shortcut and for 3 seconds nothing seems to happen. First time I double-clicked again because I though it wasn't working at all. Obviously a bit later two terminal showed up. If mintty would should up empty and wait those three seconds before something happens it is more clear it just takes some startup time. But maybe that is more a mintty problem. Regards, Frank -- 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
Cygrunsrv crashes when setting STDERR to /dev/null
Hi group, I have Apache running via cygrunsrv on a WinXP system. It works fine. Apache can even do a setuid on startup, so a 'ps -ef' looks like this: UID PIDPPID TTYSTIME COMMAND httpd16041308 ?14:26:47 /usr/local/apache/bin/httpd SYSTEM13081400 ?14:26:47 /usr/local/apache/bin/httpd httpd 8961308 ?14:26:47 /usr/local/apache/bin/httpd httpd 5361308 ?14:26:47 /usr/local/apache/bin/httpd httpd 6121308 ?14:26:47 /usr/local/apache/bin/httpd httpd 5601308 ?14:26:47 /usr/local/apache/bin/httpd As you can see, I have it running as 'httpd', an unprivileged user, which I created without password and removed from the 'Users' group, so it cannot login. Unfortunately, this doesn't work on a Win7 system. If I try the same configuration in a Win7 system, the following message is logged in logs/error_log and the Service won't start: [alert] (1)Operation not permitted: setuid: unable to change to uid: 1006 So, I set a password for the 'httpd' user and configured the Service to log on as that user. This works, but now I cannot use cygrunsrv's -1 or -2 switches for redirecting STDOUT and STDERR anymore. cygrunsrv crashes if I set either one of them to /dev/null. If I unset them, it works. Can anybody help? Daniel -- 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: Help with shortcuts
I found this on a Cygwin Facebook Users Group, it shows how to create Symbolic links : http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ It is interesting, but i don't know why anyone would do this. Maybe you could make an Index folder and organize certain types of files in it, like music or video. They say you could use mlink to create an alias to a Cygwin shell script or command So you could create a windows executable that links to a Cygqin command. This might have a use though. (mlink is a command a Windows 7) On 3/2/2014 5:50 AM, Andrey Repin wrote: Greetings, Mike Rushton! Well thanks I will have to try that. My only other option was to create a menu and execute in from my profile ... and instead of shortcuts ... they would be options off a menu. I also found out you can create symbolic links under Win 7, WIn XP (you must download this Junction Program) You can create native symlinks under WinXP, but they are not usable. and also do this under various Unix/Linux versions. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 14:40 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: Building libsigsegv on Cygwin64
On 2/21/2014 10:32 AM, Angelo Graziosi wrote:
Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball and
its .cygport file from x86 distribution), fails as follows
[...]
libtool: compile: gcc -DHAVE_CONFIG_H -I.
-I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src -I.. -I.
-I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src -ggdb -O2 -pipe
-Wimplicit-function-declaration
-fdebug-prefix-map=/works/tmp/libsigsegv-2.10-1/build=/usr/src/debug/libsigsegv-2.10-1
-fdebug-prefix-map=/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10=/usr/src/debug/libsigsegv-2.10-1
-c /works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler.c
-DDLL_EXPORT -DPIC -o .libs/handler.o
In file included from
/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler.c:20:0:
/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler-win32.c: In
function 'main_exception_filter':
/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler-win32.c:218:43:
error: 'struct _CONTEXT' has no member named 'Esp'
ExceptionInfo-ContextRecord-Esp = new_safe_esp;
^
/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler-win32.c:220:43:
error: 'struct _CONTEXT' has no member named 'Eip'
ExceptionInfo-ContextRecord-Eip = (unsigned
long)stack_overflow_handler;
^
Makefile:399: set di istruzioni per l'obiettivo handler.lo non riuscito
make[1]: *** [handler.lo] Errore 1
make[1]: uscita dalla directory /works/tmp/libsigsegv-2.10-1/build/src
Makefile:344: set di istruzioni per l'obiettivo install-recursive non
riuscito
make: *** [install-recursive] Errore 1
Since my Cygwin64 is a fesh installation, I wonder if I missed to
installe some needed packages... or is that error to be expected on
Cygwin64?
I found the problem (or at least I found *a* problem): There's a
configure test checking whether a fault handler according to POSIX
works, which passes on 32-bit Cygwin but fails on 64-bit Cygwin. I'm
attaching a file containing the configure test. Here's what happens in
the 64-bit case:
$ gcc -o fault fault.c
$ ./fault.exe
$ echo $?
1
In the 32-bit case, the exit code is 0.
I don't know if this indicates a Cygwin bug or something wrong with the
test.
Ken
#include stdlib.h
#include signal.h
#include sys/signal.h
#include sys/types.h
#include sys/mman.h
# include fcntl.h
# define zero_fd -1
# define map_flags MAP_ANON | MAP_PRIVATE
# define SIGSEGV_FAULT_ADDRESS_ROUNDOFF_BITS 0UL
unsigned long page;
int handler_called = 0;
void sigsegv_handler (int sig, siginfo_t *sip, void *ucp)
{
void *fault_address = (void *) (sip-si_addr);
handler_called++;
if (handler_called == 10)
exit (4);
if (fault_address
!= (void*)((page + 0x678) ~SIGSEGV_FAULT_ADDRESS_ROUNDOFF_BITS))
exit (3);
if (mprotect ((void *) page, 0x1, PROT_READ | PROT_WRITE) 0)
exit (2);
}
void crasher (unsigned long p)
{
*(int *) (p + 0x678) = 42;
}
int main ()
{
void *p;
struct sigaction action;
/* Preparations. */
/* Setup some mmaped memory. */
p = mmap ((void *) 0x1234, 0x1, PROT_READ | PROT_WRITE, map_flags,
zero_fd, 0);
if (p == (void *)(-1))
exit (2);
page = (unsigned long) p;
/* Make it read-only. */
if (mprotect ((void *) page, 0x1, PROT_READ) 0)
exit (2);
/* Install the SIGSEGV handler. */
sigemptyset(action.sa_mask);
action.sa_sigaction = sigsegv_handler;
action.sa_flags = SA_SIGINFO;
sigaction (SIGSEGV, action, (struct sigaction *) NULL);
sigaction (SIGBUS, action, (struct sigaction *) NULL);
/* The first write access should invoke the handler and then complete. */
crasher (page);
/* The second write access should not invoke the handler. */
crasher (page);
/* Check that the handler was called only once. */
if (handler_called != 1)
exit (1);
/* Test passed! */
return 0;
}
--
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 libsigsegv on Cygwin64
On 3/2/2014 12:20 PM, Ken Brown wrote: On 2/21/2014 10:32 AM, Angelo Graziosi wrote: Trying to build libsigsegv-2.10 on Cygwin64 (using the src tarball and its .cygport file from x86 distribution), fails as follows [...] libtool: compile: gcc -DHAVE_CONFIG_H -I. -I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src -I.. -I. -I/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src -ggdb -O2 -pipe -Wimplicit-function-declaration -fdebug-prefix-map=/works/tmp/libsigsegv-2.10-1/build=/usr/src/debug/libsigsegv-2.10-1 -fdebug-prefix-map=/works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10=/usr/src/debug/libsigsegv-2.10-1 -c /works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler.c -DDLL_EXPORT -DPIC -o .libs/handler.o In file included from /works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler.c:20:0: /works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler-win32.c: In function 'main_exception_filter': /works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler-win32.c:218:43: error: 'struct _CONTEXT' has no member named 'Esp' ExceptionInfo-ContextRecord-Esp = new_safe_esp; ^ /works/tmp/libsigsegv-2.10-1/src/libsigsegv-2.10/src/handler-win32.c:220:43: error: 'struct _CONTEXT' has no member named 'Eip' ExceptionInfo-ContextRecord-Eip = (unsigned long)stack_overflow_handler; ^ Makefile:399: set di istruzioni per l'obiettivo handler.lo non riuscito make[1]: *** [handler.lo] Errore 1 make[1]: uscita dalla directory /works/tmp/libsigsegv-2.10-1/build/src Makefile:344: set di istruzioni per l'obiettivo install-recursive non riuscito make: *** [install-recursive] Errore 1 Since my Cygwin64 is a fesh installation, I wonder if I missed to installe some needed packages... or is that error to be expected on Cygwin64? I found the problem (or at least I found *a* problem): There's a Sorry, this is obviously not *the* problem. The problem I found needs to be addressed, but the problem Angelo encountered is exactly what Corinna said: The code in handler-win32.c needs to be extended to work in the x86_64 case, as is done on other platforms in handler-unix.c. Ken -- 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: Help with shortcuts
Greetings, Mike Rushton! I found this on a Cygwin Facebook Users Group, it shows how to create Symbolic links : http://www.howtogeek.com/howto/16226/complete-guide-to-symbolic-links-symlinks-on-windows-or-linux/ You can create native symlinks under WinXP, but they are not usable. ^ LinkShellExt tool mentioned in the article will only allow to create hard links (for files and folders) or junction points (for folders) under WinXP. Using system API calls directly, it is possible to create symbolic link under WinXP, but access to the created link will be denied by system. Also, I would really appreciate, if you don't top-post. -- WBR, Andrey Repin (anrdae...@yandex.ru) 02.03.2014, 23:41 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: va_list and char* are ambiguous
On Sun, Mar 2, 2014 at 6:58 PM, Irfan Adilovic wrote:
irfan@irfy:~$ cat x.cc
#include cstdarg
#include iostream
using namespace std;
void foo (...){ cout varargs\n; }
void foo (va_list ap) { cout va_list\n; }
int main () {
foo ((const char *)NULL);
foo ((char *)NULL);
}
irfan@irfy:~$ make x
g++ x.cc -o x
irfan@irfy:~$ ./x
varargs
va_list
$ uname -a
CYGWIN_NT-6.2 irfy 1.7.29(0.271/5/3) 2014-02-21 23:45 x86_64 Cygwin
I would expect the varargs version of foo to be called both times --
and it does on my linux machine -- but I get the above output under
Cygwin. It looks like va_list is defined in terms of char*.
Can anyone confirm this behavior on their Cygwin installations?
Is this behavior legal? (in terms of whatever standards apply)
Is there a way to fix this? (i.e. typedef va_list as a pointer to a
struct defined just for the purpose of defining the va_list type)
-- Irfan
I forgot to mention that calling `foo ();` will produce:
x.cc:7:12: warning: deprecated conversion from string constant to
'char*' [-Wwrite-strings]
foo ();
^
at compile time and will end up calling va_list at runtime.
-- Irfan
--
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: va_list and char* are ambiguous
On 03/02/2014 10:45 PM, Irfan Adilovic wrote:
On Sun, Mar 2, 2014 at 6:58 PM, Irfan Adilovic wrote:
irfan@irfy:~$ cat x.cc
#include cstdarg
#include iostream
using namespace std;
void foo (...){ cout varargs\n; }
void foo (va_list ap) { cout va_list\n; }
int main () {
foo ((const char *)NULL);
foo ((char *)NULL);
}
irfan@irfy:~$ make x
g++ x.cc -o x
irfan@irfy:~$ ./x
varargs
va_list
$ uname -a
CYGWIN_NT-6.2 irfy 1.7.29(0.271/5/3) 2014-02-21 23:45 x86_64 Cygwin
I would expect the varargs version of foo to be called both times --
and it does on my linux machine -- but I get the above output under
Cygwin. It looks like va_list is defined in terms of char*.
Can anyone confirm this behavior on their Cygwin installations?
Is this behavior legal? (in terms of whatever standards apply)
Is there a way to fix this? (i.e. typedef va_list as a pointer to a
struct defined just for the purpose of defining the va_list type)
-- Irfan
I forgot to mention that calling `foo ();` will produce:
x.cc:7:12: warning: deprecated conversion from string constant to
'char*' [-Wwrite-strings]
foo ();
^
at compile time and will end up calling va_list at runtime.
I suspect this is due to compatibility with MS compiler on 32 bit
windows, where va_list is also char*.
Does it fail for AMD64 as well? I suspect it should not and it should
work. IIRC the AMD64 MS compiler uses different definition than the 32
bit one. (I cannot check right now.)
I do not think there is much that can be done about it. You will simply
have to rename one of the functions.
--
VZ
signature.asc
Description: OpenPGP digital signature
Re: va_list and char* are ambiguous
On Sun, Mar 2, 2014 at 10:50 PM, Václav Zeman wrote:
On 03/02/2014 10:45 PM, Irfan Adilovic wrote:
On Sun, Mar 2, 2014 at 6:58 PM, Irfan Adilovic wrote:
irfan@irfy:~$ cat x.cc
#include cstdarg
#include iostream
using namespace std;
void foo (...){ cout varargs\n; }
void foo (va_list ap) { cout va_list\n; }
int main () {
foo ((const char *)NULL);
foo ((char *)NULL);
}
irfan@irfy:~$ make x
g++ x.cc -o x
irfan@irfy:~$ ./x
varargs
va_list
$ uname -a
CYGWIN_NT-6.2 irfy 1.7.29(0.271/5/3) 2014-02-21 23:45 x86_64 Cygwin
I would expect the varargs version of foo to be called both times --
and it does on my linux machine -- but I get the above output under
Cygwin. It looks like va_list is defined in terms of char*.
Can anyone confirm this behavior on their Cygwin installations?
Is this behavior legal? (in terms of whatever standards apply)
Is there a way to fix this? (i.e. typedef va_list as a pointer to a
struct defined just for the purpose of defining the va_list type)
-- Irfan
I forgot to mention that calling `foo ();` will produce:
x.cc:7:12: warning: deprecated conversion from string constant to
'char*' [-Wwrite-strings]
foo ();
^
at compile time and will end up calling va_list at runtime.
I suspect this is due to compatibility with MS compiler on 32 bit
windows, where va_list is also char*.
Does it fail for AMD64 as well? I suspect it should not and it should
work. IIRC the AMD64 MS compiler uses different definition than the 32
bit one. (I cannot check right now.)
I do not think there is much that can be done about it. You will simply
have to rename one of the functions.
--
VZ
I am on a 64-bit Windows 8 running 64-bit Cygwin, so no, it doesn't work.
I'm not sure how stuff works behind the scenes when I compile my
program under Cygwin, but I do not use anything from Windows
explicitly -- in other words, I'm working with purely Linux code.
Would recompiling gcc be an option? Or is va_list somehow hard-wired
to the Windows version of it?
-- Irfan
--
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
