Re: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
ChangeLog entry: 2010-08-19 Pedro Izecksohn * endian.h [_BSD_SOURCE || ! _POSIX_SOURCE] (htobe16, htobe32) (htobe64, be16toh, be32toh, be64toh, htole16, htole32, htole64) (le16toh, le32toh, le64toh): Macros defined. I modified endian.h again: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 19 19:03:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,86 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE + + #include + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #endif /*__BYTE_ORDER == __LITTLE_ENDIAN*/ + + #if __BYTE_ORDER == __BIG_ENDIAN + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif /*__BYTE_ORDER == __BIG_ENDIAN*/ + + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Corinna Vinschen wrote: > > For this patch, given that it is just a bunch of rather obvious > defines, I don't think we have to treat the patch as significant. I do not think that these macros are obvious. I think that I was there when these macros were first implemented at 1987: I talked with the programmer who was paid by the Correios to port everything from the mainframe to the Apple II. I was a stenchy kid with his father, that asked the employee what he was doing. When I asked about other possibilities of endianness, the programmer answered about the PDP. The programmer explained about BSD being a flavor of Unix. That talk changed my life. > However, please don't use _BSD_SOURCE. The newlib/Cygwin headers are > not set up like the Linux headers and the big bunch of definitions from > /usr/include/features.h are not available so far. The _BSD_SOURCE > define is not honored or set anywhere right now. > > What you can do is to use _POSIX_SOURCE. So, if you're going to use > #ifndef _POSIX_SOURCE instead, and if you're creating a ChangeLog entry > in the correct ChangeLog entry format (see the ChangeLog file), then > I guess we can check it in. Would you agree with: #if defined _BSD_SOURCE || ! defined _POSIX_SOURCE ? -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
As this thread went nowhere, I searched for the BSD code: http://svn.freebsd.org/viewvc/base/stable/8/sys/sys/endian.h?revision=199583&view=markup It uses x to represent the variable as I did; but it also casts the variable. I think that casting is not desirable because I like to see warnings. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- I wrote: >> The x glyph represents the different ways to represent the same number: >> ... >> I thought to use (i) of integer, but its glyph does not remember the >> proverb about Rome. --- Corinna Vinschen asked: > You mean "What have the Romans ever done for us?" "All roads lead to Rome." Answering the question asked by Eric Blake: Why do you need these macros? Binary endianness conversion is faster than ASCII conversion. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
> Umm - did you copy straight from glibc's endian.h? That's a no-no; > cygwin generally doesn't want to borrow LGPL sources to avoid any > licensing questions (borrowing from BSD is okay, on the other hand). > You would have to implement things from scratch from a documentation > page, or copy from a less-questionable source, rather than using glibc's > implementation. > > I'm stopping right here, so I don't risk tainting myself. How about you > instead describe which macros you are missing, so someone can do a > clean-room implementation of those macros. After sleep I remembered the error that I posted first, that proves that I did not copy from glibc: + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include If I would have copied from glibc this out-of-order code would be as it must be. And regarding the many (x) I can explain them: I could use any acceptable character, but I chose x for 2 reasons: 1) I, and probably most of you, learned equations at school using x and y, to draw the points along the axes; 2) The x glyph represents the different ways to represent the same number: As a child, I once asked an Unix sysadmin that used a real TTY: "-You are telling me that are two different ways to order the 4 bytes of a number. But I can imagine many more ways to represent the same number. For example: 1324 or 1423. ?" I thought to use (i) of integer, but its glyph does not remember the proverb about Rome. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Eric Blake wrote: > > Umm - did you copy straight from glibc's endian.h? That's a no-no; > cygwin generally doesn't want to borrow LGPL sources to avoid any > licensing questions (borrowing from BSD is okay, on the other hand). > You would have to implement things from scratch from a documentation > page, or copy from a less-questionable source, rather than using glibc's > implementation. > > I'm stopping right here, so I don't risk tainting myself. How about you > instead describe which macros you are missing, so someone can do a > clean-room implementation of those macros. I did not copy my code from glibc's endian.h: I wrote my code yesterday, while on Windows Vista for 32 bits using joe on Cygwin and notepad. Now I'm using Ubuntu for x86-64. I'm also surprised that glibc's code is similar to mine: glibc's folks wrote: #ifdef __USE_BSD /* Conversion interfaces. */ # include I wrote: #ifdef _BSD_SOURCE #include The man 3 page, from Linux and from the web, does not tell about __USE_BSD. The next line is equal, probably because the glibc's guy who wrote it also was using x86-32. If I would be using Ubuntu for x86-64 yesterday I would have written the opposite. #if __BYTE_ORDER == __LITTLE_ENDIAN If you want, to swap the order of my macros is very easy. Then glibc continues, interleaving be with le, and a pair of hto with another pair of toh: # define htobe16(x) __bswap_16 (x) # define htole16(x) (x) # define be16toh(x) __bswap_16 (x) # define le16toh(x) (x) It is very different from what I wrote. I interleaved the types: #define htobe16(x) bswap_16(x) #define htobe32(x) bswap_32(x) #define htobe64(x) bswap_64(x) To use bswap to implement hto and toh macros is the most intelligent approach. Fortunately, glibc's __bswap_16 differs from Cygwin's bswap_16. Also: glibc's style is different from mine: They use a space between the # and the define. After writing this message I'm proud that I'm as smart as the glibc's coder. I need the 64 bits macros only. I wrote the other macros for completeness. In my project, that can not be disclosed now, I use the arpa/inet.h macros for the smaller types. -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- I wrote: > Defines macros for to convert the endianness of 16, 32 and 64 bits > integer types. > > diff -c /usr/include/endian.orig.h /usr/include/endian.h My previous diff is wrong. The right one follows: *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 21:28:01 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,83 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + + #include + + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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: diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
--- Eric Blake wrote: > Christopher Faylor wrote: >> I wrote: >>> I hope this list accepts attachments. >> >> It does but the list mind-reading gizmo is on the fritz. > > Translation - a ChangeLog entry justifying your changes, a diff in > unified or context format (-u or -c) rather than the default ed format, > and attaching the patch inline with a text/plain MIME type instead of > base64 encoded, are all necessary before anyone is likely to act on your > proposed patch. Defines macros for to convert the endianness of 16, 32 and 64 bits integer types. diff -c /usr/include/endian.orig.h /usr/include/endian.h *** /usr/include/endian.orig.h Mon Apr 12 14:09:58 2010 --- /usr/include/endian.h Thu Aug 12 19:40:20 2010 *** *** 36,40 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif - #endif /*_ENDIAN_H_*/ --- 36,82 #elif __BYTE_ORDER == __BIG_ENDIAN # define __LONG_LONG_PAIR(HI, LO) HI, LO #endif + #ifdef _BSD_SOURCE + #if __BYTE_ORDER == __LITTLE_ENDIAN + + #include + + #define htobe16(x) bswap_16(x) + #define htobe32(x) bswap_32(x) + #define htobe64(x) bswap_64(x) + + #define be16toh(x) bswap_16(x) + #define be32toh(x) bswap_32(x) + #define be64toh(x) bswap_64(x) + + #define htole16(x) (x) + #define htole32(x) (x) + #define htole64(x) (x) + + #define le16toh(x) (x) + #define le32toh(x) (x) + #define le64toh(x) (x) + + #else /* __BYTE_ORDER == __BIG_ENDIAN */ + + #define htobe16(x) (x) + #define htobe32(x) (x) + #define htobe64(x) (x) + + #define be16toh(x) (x) + #define be32toh(x) (x) + #define be64toh(x) (x) + + #define htole16(x) bswap_16(x) + #define htole32(x) bswap_32(x) + #define htole64(x) bswap_64(x) + + #define le16toh(x) bswap_16(x) + #define le32toh(x) bswap_32(x) + #define le64toh(x) bswap_64(x) + + #endif + #endif /*_BSD_SOURCE*/ + + #endif /*_ENDIAN_H_*/ -- 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
diff /usr/include/endian.orig.h /usr/include/endian.h > endian.h.diff
I hope this list accepts attachments. endian.h.diff Description: Binary data -- 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: FTW_PHYS
--- Larry Hall wrote: > > Type "mount" and hit return. Does that answer your question? > Just a little harmless redirection. $ mount C:/cygwin-1.7/bin on /usr/bin type ntfs (binary,auto) C:/cygwin-1.7/lib on /usr/lib type ntfs (binary,auto) C:/cygwin-1.7 on / type ntfs (binary,auto) C: on /cygdrive/c type ntfs (binary,posix=0,user,noumount,auto) D: on /cygdrive/d type ntfs (binary,posix=0,user,noumount,auto) --- Nellis, Kenneth wrote: > > But FTW_PHYS only inhibits symbolic links from being > followed. You have no symbolic links in those paths, > so FTW_PHYS is irrelevant to your problem. You two answered my question. Now I know that I need to check st_dev and st_ino . -- 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
FTW_PHYS
I wrote a small C++ application: http://www.izecksohn.com/pedro/c++/biggest/ that exhibits an unwanted behavior on Cygwin: ./biggest.exe -m -n -1 -d / > Cygwin\ files head Cygwin\ files 822 /lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe 822 /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1plus.exe 7667214 /lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe 7667214 /usr/lib/gcc/i686-pc-cygwin/4.3.4/cc1.exe 7527198 /lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.a 7527198 /usr/lib/gcc/i686-pc-cygwin/4.3.4/libstdc++.a But biggest.c++ uses FTW_PHYS in flags to call nftw. So, why the duplicated entries shown above? P.S.: I know that I promised to contribute some code and I did not. My project took another way. -- 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: SIGINT default behavior
I, Pedro Izecksohn wrote: > Robert Pendell wrote: >> >> I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4 >> on 1.7.0-62. Gave exit code 130 every time. I used your test case to >> do the test. > > May be I did not express myself well: > > When ctrl c is pressed, it always give exit code 130. The > inconsistencies are ferror (stdin) and perror behaviors. What I understand as a bug is: fgets should not return after SIG_DFL caught SIGINT. -- 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: SIGINT default behavior
Robert Pendell wrote: > > I was unable to reproduce this bug on 1.7. Compiled using GCC 4.3.4 > on 1.7.0-62. Gave exit code 130 every time. I used your test case to > do the test. May be I did not express myself well: When ctrl c is pressed, it always give exit code 130. The inconsistencies are ferror (stdin) and perror behaviors. I'll not be on Cygwin before noon. -- 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: SIGINT default behavior
Larry Hall wrote: > I, Pedro Izecksohn, wrote: >> >> The default behavior is not always the same. I also got: >> ferror (stdin): >> and >> ferror (stdin): Interrupted system call >> and the expected behavior of just the exit code 130. >> > > Try Cygwin 1.7 <http://cygwin.com/#beta-test>. $ cat /proc/version CYGWIN_NT-6.0 1.7.0(0.214/5/3) 2009-10-03 14:33 The beta version gives the same inconsistent results. -- 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
SIGINT default behavior
r...@turion ~/programming/c/sigint
$ cat test.c
#include
#include
int main ()
{
printf ("Press Control c\n");
char buffer [3];
char *fgets_returned = fgets (buffer, sizeof buffer, stdin);
if (!fgets_returned)
{
if (ferror (stdin))
{
perror ("ferror (stdin)");
return EXIT_FAILURE;
}
if (feof (stdin)) printf ("EOF\n");
return EXIT_SUCCESS;
}
printf ("You did not press Control c .\n");
return EXIT_SUCCESS;
}
r...@turion ~/programming/c/sigint
$ gcc -Wall test.c -o test_cygwin.exe
r...@turion ~/programming/c/sigint
$ ./test_cygwin.exe
Press Control c
ferror (stdin)
r...@turion ~/programming/c/sigint
$ cat /proc/version
CYGWIN_NT-6.0 1.5.25(0.156/4/2) 2008-06-12 19:34
The default behavior is not always the same. I also got:
ferror (stdin):
and
ferror (stdin): Interrupted system call
and the expected behavior of just the exit code 130.
--
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: bug in mbrtowc?
To initialize wchar_t wc=(wchar_t)0; may also help. On Tue, Jul 28, 2009 at 6:56 AM, Andy Koppe wrote: > 2009/7/28 Pedro Izecksohn: >> The bug is in O.P.'s code as &s is not being passed to mbrtowc. > > From http://www.opengroup.org/onlinepubs/009695399/functions/mbrtowc.html: > "If ps is a null pointer, the mbrtowc() function shall use its own > internal mbstate_t object, which shall be initialized at program > start-up to the initial conversion state." > > The test also fails when passing &s instead. (I'd accidentally left in > the local mb_state.) > > Andy -- 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: bug in mbrtowc?
The bug is in O.P.'s code as &s is not being passed to mbrtowc.
I'm on Ubuntu. I do not have Cygwin here.
I should consume some calories before trying to debug anything.
On Tue, Jul 28, 2009 at 6:14 AM, Corinna
Vinschen wrote:
> On Jul 27 22:56, Andy Koppe wrote:
>> I've encountered what looks like a bug in mbrtowc's handling of UTF-8.
>> Here's an example:
>>
>> #include
>> #include
>> #include
>> #include
>>
>> int main(void) {
>> wchar_t wc;
>> size_t ret;
>> mbstate_t s = { 0 };
>> puts(setlocale(LC_CTYPE, "en_GB.UTF-8"));
>> printf("%i\n", mbrtowc(&wc, "\xe2", 1, 0));
>> printf("%i\n", mbrtowc(&wc, "\x94", 1, 0));
>> printf("%i\n", mbrtowc(&wc, "\x84", 1, 0));
>> printf("%x\n", wc);
>> return 0;
>> }
>>
>> The sequence E2 94 84 should translate to U+2514. Instead, the second
>> and third calls to mbrtowc report encoding errors. It does work
>> correctly if the three bytes are passed to mbrtowc() in one go:
>>
>> printf("%i\n", mbrtowc(&wc, "\xe2\x94\x84", 3, 0));
>
> That's a bug in the newlib function __utf8_mbtowc. I'm really surprised
> that this bug has never been reported before since it's in the code for
> years, probably since it has been introduced in 2002.
>
> I'll follow up on the newlib list.
>
>
> Thanks for the report and especially thanks for the testcase,
> Corinna
--
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: bug in mbrtowc?
From the "Linux Programmer’s Manual" (release 3.15 of the Linux man-pages):
"If the n bytes starting at s do not contain a complete multibyte
character, mbrtowc() returns (size_t) -2."
On Mon, Jul 27, 2009 at 6:56 PM, Andy Koppe wrote:
> I've encountered what looks like a bug in mbrtowc's handling of UTF-8.
> Here's an example:
>
> #include
> #include
> #include
> #include
>
> int main(void) {
> wchar_t wc;
> size_t ret;
> mbstate_t s = { 0 };
> puts(setlocale(LC_CTYPE, "en_GB.UTF-8"));
> printf("%i\n", mbrtowc(&wc, "\xe2", 1, 0));
> printf("%i\n", mbrtowc(&wc, "\x94", 1, 0));
> printf("%i\n", mbrtowc(&wc, "\x84", 1, 0));
> printf("%x\n", wc);
> return 0;
> }
>
> The sequence E2 94 84 should translate to U+2514. Instead, the second
> and third calls to mbrtowc report encoding errors. It does work
> correctly if the three bytes are passed to mbrtowc() in one go:
>
> printf("%i\n", mbrtowc(&wc, "\xe2\x94\x84", 3, 0));
>
> Andy
--
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
build/i686-pc-cygwin/winsup make check
Just to point out (as probably I'll solve it myself later): $ tail make_check_outerr make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/cygwin' make[1]: Nothing to be done for `all'. make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/cygwin' make[1]: Entering directory `/opt/build/i686-pc-cygwin/winsup/testsuite' gcc -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/i686-pc-cygwin/winsup/testsu ite -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isystem /opt/src/winsup/inclu de -isystem /opt/src/winsup/testsuite/include -isystem /opt/src/winsup/w32api/in clude -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/build/i686-pc-cygwin/new lib/targ-include -isystem /opt/src/newlib/libc/include-I/usr/lib/gcc/i686-pc -cygwin/4.3.2/include -mno-cygwin -I/opt/src/winsup/w32api/include -o cygrun.o -c /opt/src/winsup/testsuite/cygrun.c gcc: The -mno-cygwin flag has been removed; use a mingw-targeted cross-compiler. make[1]: *** [cygrun.o] Error 1 make[1]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/testsuite' make: *** [check] Error 2 -- 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: Any solution to this build problem?
--- Jacob Jacobson wrote: > Perhaps this went unnoticed. Reposting it. I am still having > problems building cygwin dll. Has anyone seen this error? > >> > Getting close here. Apparently gets to the linking phase. Please help >> > with error below. >> > >> > [build$:618] (../src/configure --prefix=/c/home/wrk/cygwin/install -v; >> > make) >>> >>& make.out >> > [build$:619] tail make.out >> > >> > /c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/cygwin/lib/pseudo-reloc.c:33: >> > undefined reference to `___RUNTIME_PSEUDO_RELOC_LIST_END__' >> > collect2: ld returned 1 exit status >> > >> > make[3]: *** [cygwin0.dll] Error 1 >> > make[3]: Leaving directory >> > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin' >> > make[2]: *** [cygwin] Error 1 >> > make[2]: Leaving directory >> > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup' >> > make[1]: *** [all-target-winsup] Error 2 >> > make[1]: Leaving directory `/c/home/wrk/cygwin/build' >> > make: *** [all] Error 2 >> > [build$:620] Try to remove the build directory to configure and make again from the beginning. -- 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 Build Error
Jacob Jacobson wrote: > > Getting close here. Apparently gets to the linking phase. Please help > with error below. > > > [build$:618] (../src/configure --prefix=/c/home/wrk/cygwin/install -v; make) >>& make.out > [build$:619] tail make.out > /c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin/../../../../src/winsup/cygwin/lib/pseudo-reloc.c:33: > undefined reference to `___RUNTIME_PSEUDO_RELOC_LIST_END__' > collect2: ld returned 1 exit status > > make[3]: *** [cygwin0.dll] Error 1 > make[3]: Leaving directory > `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup/cygwin' > make[2]: *** [cygwin] Error 1 > make[2]: Leaving directory `/c/home/wrk/cygwin/build/i686-pc-cygwin/winsup' > make[1]: *** [all-target-winsup] Error 2 > make[1]: Leaving directory `/c/home/wrk/cygwin/build' > make: *** [all] Error 2 > [build$:620] I did not have this problem. I had a problem similar, but different, to the one described at: http://www.cygwin.com/ml/cygwin/2008-07/msg00148.html -- 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 Build Error
--- Christopher Faylor wrote: > Just remove the mingw directory. --- I, Pedro, posted: > $ tail make.out > /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup > -L/opt/build/ > i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib > -isys > tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem > /op > t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem > /opt/bu > ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include > -I/opt/src/winsup -c -o ./bloda.o -g -O2 -fno-exceptions -fno-rtti > -DHAVE_DECL_G > ETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include > /opt/src/winsup/utils/blod > a.cc > /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup > -L/opt/build/ > i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib > -isys > tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem > /op > t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem > /opt/bu > ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include > -I/opt/src/winsup -c -o ./path.o -g -O2 -fno-exceptions -fno-rtti > -DHAVE_DECL_GE > TOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include > /opt/src/winsup/utils/path. > cc > /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup > -L/opt/build/ > i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib > -isys > tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem > /op > t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem > /opt/bu > ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include > -I/opt/src/winsup -c -o ./dump_setup.o -g -O2 -fno-exceptions -fno-rtti > -DHAVE_D > ECL_GETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include > /opt/src/winsup/utils > /dump_setup.cc > make[3]: *** No rule to make target > `/opt/build/i686-pc-cygwin/winsup/mingw/Make > file', needed by `/opt/build/i686-pc-cygwin/winsup/mingw/libmingw32.a'. Stop. > make[3]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/utils' > make[2]: *** [utils] Error 1 > make[2]: Leaving directory `/opt/build/i686-pc-cygwin/winsup' > make[1]: *** [all-target-winsup] Error 2 > make[1]: Leaving directory `/opt/build' > make: *** [all] Error 2 The solution: $ diff src/winsup/utils/Makefile.in~ src/winsup/utils/Makefile.in 108c108,109 < all: Makefile $(CYGWIN_BINS) $(MINGW_BINS) --- > #all: Makefile $(CYGWIN_BINS) $(MINGW_BINS) > all: Makefile $(CYGWIN_BINS) And the next problem: $ tail make.out xmlto html -o faq -m /opt/src/winsup/doc/cygwin.dsl /opt/src/winsup/doc/faq.xml Writing faq-nochunks.html for article(faq-nochunks) sed -i 's;;;g' faq/faq-nochunks.html xmlto --extension -v pdf -o cygwin-ug-net/ -m /opt/src/winsup/doc/cygwin.dsl cyg win-ug-net.sgml Format script: /usr/share/xmlto/format/docbook/pdf I don't know how to convert docbook into pdf. make[3]: [cygwin-ug-net/cygwin-ug-net.pdf] Error 1 (ignored) make[3]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/doc' make[2]: Leaving directory `/opt/build/i686-pc-cygwin/winsup' make[1]: Leaving directory `/opt/build' I need to log off now. -- 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 Build Error
--- Christopher Faylor wrote: > Just remove the mingw directory. $ tail make.out /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/ i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem /op t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/bu ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include -I/opt/src/winsup -c -o ./bloda.o -g -O2 -fno-exceptions -fno-rtti -DHAVE_DECL_G ETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include /opt/src/winsup/utils/blod a.cc /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/ i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem /op t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/bu ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include -I/opt/src/winsup -c -o ./path.o -g -O2 -fno-exceptions -fno-rtti -DHAVE_DECL_GE TOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include /opt/src/winsup/utils/path. cc /opt/src/winsup/utils/mingw g++ -L/opt/build/i686-pc-cygwin/winsup -L/opt/build/ i686-pc-cygwin/winsup/cygwin -L/opt/build/i686-pc-cygwin/winsup/w32api/lib -isys tem /opt/src/winsup/include -isystem /opt/src/winsup/cygwin/include -isystem /op t/src/winsup/w32api/include -B/opt/build/i686-pc-cygwin/newlib/ -isystem /opt/bu ild/i686-pc-cygwin/newlib/targ-include -isystem /opt/src/newlib/libc/include -I/opt/src/winsup -c -o ./dump_setup.o -g -O2 -fno-exceptions -fno-rtti -DHAVE_D ECL_GETOPT=0 -mno-cygwin -I/opt/src/winsup/w32api/include /opt/src/winsup/utils /dump_setup.cc make[3]: *** No rule to make target `/opt/build/i686-pc-cygwin/winsup/mingw/Make file', needed by `/opt/build/i686-pc-cygwin/winsup/mingw/libmingw32.a'. Stop. make[3]: Leaving directory `/opt/build/i686-pc-cygwin/winsup/utils' make[2]: *** [utils] Error 1 make[2]: Leaving directory `/opt/build/i686-pc-cygwin/winsup' make[1]: *** [all-target-winsup] Error 2 make[1]: Leaving directory `/opt/build' make: *** [all] Error 2 -- 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: "setrlimit(RLIMIT_CPU) isn't implemented in Cygwin.", Corinna Vinschen
I'm, slowly, implementing it. I plan to post the papers tomorrow, after my implementation work fine. -- 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: "setrlimit(RLIMIT_CPU) isn't implemented in Cygwin.", Corinna Vinschen
--- I asked: >>> Will it be implemented in Cygwin someday? --- Dave Korn replied: >> Otherwise, http://cygwin.com/acronyms#SHTDI and >> http://cygwin.com/acronyms#PTC apply here. I imagine it should be possible >> to >> use a windows job object to implement it. --- Corinna Vinschen replied: > There are no plans to implement it in the near future. Are contributors asked to sign any paper? If I contribute it, will my name appear in the .cc file? Must my e-mail appear with my name? -- 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
"setrlimit(RLIMIT_CPU) isn't implemented in Cygwin.", Corinna Vinschen
Will it be implemented in Cygwin someday? -- 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: 1.7.0 sem_open
--- I wrote: >>> For me, using the unpatched version, (not the CVS version), the >>> persistence works some times only. At other times the semaphore >>> disappears with the Control c. It is not reproducible. I'm sorry from wasting your time. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 sem_open
>> The persistence of the semaphore also works for you? >> >> For me, using the unpatched version, (not the CVS version), the >> persistence works some times only. At other times the semaphore >> disappears with the Control c. > > The semaphore is backed by a file on disk. If you don't call > sem_unlink one way or the other, the semaphore persists. Nice to say, but why it is not always this way? I should create an example to run my code some times and always kill it until that the semaphore does not persist. It is a nice task for tonight. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: 1.7.0 sem_open
Corinna Vinschen read my mind. > What is semtool? semtool - A utility for tinkering with semaphores USAGE: semtool (c)reate (l)ock (u)nlock (d)elete (m)ode It comes in some package available through the Cygwin's installer. I do not understand how to use it. >> I wrote an example that works on Jaunty on x86-64 but not on Cygwin: >> http://www.izecksohn.com/pedro/c/semaphores/semaphores.tar.gz > > Works for me. The persistence of the semaphore also works for you? For me, using the unpatched version, (not the CVS version), the persistence works some times only. At other times the semaphore disappears with the Control c. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
1.7.0 sem_open
Does the function sem_open work for anyone using Cygwin 1.7.0 ? How to use semtool ? I wrote an example that works on Jaunty on x86-64 but not on Cygwin: http://www.izecksohn.com/pedro/c/semaphores/semaphores.tar.gz Also: gcc4 does not understand the option "-lrt" so it must be removed. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Incomplete environ when running MinGW apps?
> From: Christopher Faylor >> I wrote: >> Reference: http://sourceware.org/ml/cygwin/2008-02/msg00181.html >> ... >> >> "SHELL The full pathname to the shell is kept in this environment variable." >> >> It may also be read from: >>http://www.gnu.org/software/bash/manual/bashref.html > > Why are you responding to this email 5+ months after it was sent? Because I found this in the documentation just now; and I hope that someone fix something. I lament this feature is not POSIX. -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Re: Incomplete environ when running MinGW apps?
Reference: http://sourceware.org/ml/cygwin/2008-02/msg00181.html "Are you sure SHELL was exported to the environment, and not just in the bash shell variable namespace?" It is a documentation problem, from man bash: "SHELL The full pathname to the shell is kept in this environment variable." It may also be read from: http://www.gnu.org/software/bash/manual/bashref.html -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Cygwin on Vista
I'm becoming an idiot. Every day I understand less: bash-3.2$ file AWTPlayer.java AWTPlayer.java: ASCII Java program text bash-3.2$ unix2dos.exe AWTPlayer.java AWTPlayer.java: unix2dos processing AWTPlayer.java: Permission denied bash-3.2$ unix2dos.exe < AWTPlayer.java > AWTPlayer2.java bash-3.2$ file AWTPlayer2.java AWTPlayer2.java: ASCII Java program text, with CRLF line terminators bash-3.2$ icacls AWTPlayer.java AWTPlayer.java TURION\Pedro:(I)(F) Successfully processed 1 files; Failed processing 0 files bash-3.2$ icacls AWTPlayer2.java AWTPlayer2.java TURION\Pedro:(R,W,D,WDAC,WO) TURION\None:(R,W) Everyone:(R,W) Successfully processed 1 files; Failed processing 0 files bash-3.2$ groups mkgroup bash-3.2$ 1) Why unix2dos failed the first time? bash-3.2$ ls testing ls: cannot access testing: No such file or directory bash-3.2$ touch testing bash-3.2$ icacls testing testing TURION\Pedro:(R,W,D,WDAC,WO) TURION\None:(R,W) Everyone:(R,W) Successfully processed 1 files; Failed processing 0 files bash-3.2$ 2) Why every file I create is created with the None and Everyone permissions? P.S.: The last month I've being thinking about: Am I the only world dumb sysadmin that short circuited a LAN? Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
Function stat bug when dealing with symlinks.
struct stat member st_mode is wrongly being set by the stat function to regular file instead of to symlink. I packed a test for download: http://www.izecksohn.com/pedro/c/statbug/statbug.tar.gz To use it: tar -xzvf statbug.tar.gz make My configuration: bash-3.2$ uname -a CYGWIN_NT-6.0 turion 1.5.25(0.156/4/2) 2007-12-14 19:21 i686 Cygwin I'm using Windows Vista with NTFS. Abra sua conta no Yahoo! Mail, o único sem limite de espaço para armazenamento! http://br.mail.yahoo.com/ -- Unsubscribe info: http://cygwin.com/ml/#unsubscribe-simple Problem reports: http://cygwin.com/problems.html Documentation: http://cygwin.com/docs.html FAQ: http://cygwin.com/faq/
