Re: Error line 30, E 117...

[Václav Haisman]

On 07. 09. 22 0:31, Kevin M. Wilson via Cygwin wrote:
> Question if Cygwin isn't 'installed' by Windows 10, then how is it installed, 
> and how can it be uninstalled??
> 
> 
> Good sense makes one slow to anger, and it is his glory tooverlook an offense.
> 
> Proverbs 19:11
> 
> 
See the FAQ link: https://cygwin.com/faq/faq.html#faq.setup.setup

-- 
VH

-- 
Problem reports:  https://cygwin.com/problems.html
FAQ:  https://cygwin.com/faq/
Documentation:https://cygwin.com/docs.html
Unsubscribe info: https://cygwin.com/ml/#unsubscribe-simple

Re: Function call difference between cygwin and Windows

[Václav Haisman]

On Fri, 19 Jul 2019 at 10:23, Biswapriyo Nath wrote:
>
> If a function calls both cygwin and Windows functions the binary creates
> extra subroutine (in assembly) for cygwin ones. Example:
>
> * Windows function:
>
>call cs:CreatePipe
>
> * cygwin function:
>
>call ioctl
>
>ioctl proc near
>jmp cs:__imp_ioctl
>endp
>
> The binary is statically compiled. Why there are extra subroutines? Is this
> "by-design"? Or am I missing something?

This is how Windows DLLs work. See also
.

-- 
VH

--
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: problem with mmap and fork()

[Václav Haisman]

On 23. 02. 19 1:02, Glyn Gowing wrote:
> Hello everyone,
> 
> I have a program (attached) that works correctly on my mac but does
> not work with Cygwin on Windows 10. I'm running the latest version of
> Cygwin (downloaded the updates two days ago) and using gcc as the c
> compiler.
> 
> What happens in the buggy execution is that the child obtains a lock
> before the parent releases it. I'm using mmap and a pthread_mutex_t
> object along with fork(). Again, this exact code works correctly on my
> Mac running Mojave.
> 
> I've looked at the archives and online and I can't find any hints as
> to what I may be doing incorrectly here
> 

You cannot fork() and keep using threading primitives in the child. The
child has only one thread and the mutexes are usually in a state that
can be inconsistent. Basically, the only safe thing to do in
multithreaded process after fork is to exec() and reinitialize your
application.

-- 
VH



signature.asc
Description: OpenPGP digital signature

Mercurial package falling behind

[Václav Haisman]

Hi.

I am using Mercurial in both Cygwin and plain Windows with the same
repository. It would be nice to be able to use the same version for both
but Cygwin's Mercurial package is falling behind a lot now.

-- 
VH



signature.asc
Description: OpenPGP digital signature

unexpected high-bit set characters in $USER variable

[Václav Haisman]

Hi.

I have updated Cygwin after a while and now my prompt looks like
this: \ufeffUSER@MACHINE. There appears to be some sort of UNICODE
character at position 0 in $USER environment variable. Running `echo -n
$USER | od -t x1` prints `000 ef bb bf 68 61 69 76 61 30 31`. Does
anyone else observe this as well?

-- 
VH

--
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

Keychain package refresh

[Václav Haisman]

Hi.

Cygwin's version of keychain package has issues with new OpenSSL keys
which manifests with this message:

 * Warning: Can't determine fingerprint from the following line,
falling back to filename

This appears to have been fixed in newer versions. Please, refresh the
Cygwin's version of the pacakge.

-- 
VH

--
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: Subversion segfaulting

[Václav Haisman]

On 21 June 2017 at 09:42, Václav Haisman wrote:
> After quote a long time I needed to use Subversion and I found it
> segfaulting, reproducibly, when I try checkout. I have tried `svn
> help` but that does not segfault. I have tried to run `svn checkout
> http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.10.4
> maven-javadoc-plugin`. The crashing thread does not seem to have any
> decodable call stack. The best I could do is this bit of `strace` log:
>
>75 1078125 [main] svn 22460 select_stuff::wait: wait_ret 2, m = 4.  
> verifying
>68 1078193 [main] svn 22460 select_stuff::wait: res after verify 0
>54 1078247 [main] svn 22460 select_stuff::wait: returning 0
>54 1078301 [main] svn 22460 select: sel.wait returns 0
>51 1078352 [main] svn 22460 peek_socket: read_ready: 1,
> write_ready: 1, except_ready: 0
>39 1078391 [main] svn 22460 set_bits: me 0x60007D880, testing fd 3 ()
>62 1078453 [main] svn 22460 set_bits: ready 2
>39 1078492 [main] svn 22460 select_stuff::cleanup: calling cleanup routines
>33 1078525 [main] svn 22460 socket_cleanup: si 0x60007D410
> si->thread 0x1801FF798
>56 1078581 [main] svn 22460 socket_cleanup: returning
>25 1078606 [main] svn 22460 select_stuff::destroy: deleting select records
>36 1078642 [main] svn 22460 select_stuff::cleanup: calling cleanup routines
>25 1078667 [main] svn 22460 select_stuff::destroy: deleting select records
>26 1078693 [main] svn 22460 pselect: 2 = select (4, 0xBDC0,
> 0xBDA0, 0xBD80, 0xBD30)
>53 1078746 [main] svn 22460 read: read(3, 0x6000DBEA4, 8000) nonblocking
>35 1078781 [main] svn 22460 __set_errno: void
> __set_winsock_errno(const char*, int):224 setting errno 11
>31 1078812 [main] svn 22460 __set_winsock_errno: recv_internal:1604
> - winsock error 10035 -> errno 11
>51 1078863 [main] svn 22460 read: -1 = read(3, 0x6000DBEA4, -1), errno 11
> --- Process 22460, exception c005 at 
>
> Cygcheck does not show anything unusual. This is with Cygwin
> 2.8.0(0.309/5/3) on AMD64.
>

Possibly false alarm. I have deleted `~/.subversion` and it stopped crashing.

-- 
VH

--
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

Subversion segfaulting

[Václav Haisman]

After quote a long time I needed to use Subversion and I found it
segfaulting, reproducibly, when I try checkout. I have tried `svn
help` but that does not segfault. I have tried to run `svn checkout
http://svn.apache.org/repos/asf/maven/plugins/tags/maven-javadoc-plugin-2.10.4
maven-javadoc-plugin`. The crashing thread does not seem to have any
decodable call stack. The best I could do is this bit of `strace` log:

   75 1078125 [main] svn 22460 select_stuff::wait: wait_ret 2, m = 4.  verifying
   68 1078193 [main] svn 22460 select_stuff::wait: res after verify 0
   54 1078247 [main] svn 22460 select_stuff::wait: returning 0
   54 1078301 [main] svn 22460 select: sel.wait returns 0
   51 1078352 [main] svn 22460 peek_socket: read_ready: 1,
write_ready: 1, except_ready: 0
   39 1078391 [main] svn 22460 set_bits: me 0x60007D880, testing fd 3 ()
   62 1078453 [main] svn 22460 set_bits: ready 2
   39 1078492 [main] svn 22460 select_stuff::cleanup: calling cleanup routines
   33 1078525 [main] svn 22460 socket_cleanup: si 0x60007D410
si->thread 0x1801FF798
   56 1078581 [main] svn 22460 socket_cleanup: returning
   25 1078606 [main] svn 22460 select_stuff::destroy: deleting select records
   36 1078642 [main] svn 22460 select_stuff::cleanup: calling cleanup routines
   25 1078667 [main] svn 22460 select_stuff::destroy: deleting select records
   26 1078693 [main] svn 22460 pselect: 2 = select (4, 0xBDC0,
0xBDA0, 0xBD80, 0xBD30)
   53 1078746 [main] svn 22460 read: read(3, 0x6000DBEA4, 8000) nonblocking
   35 1078781 [main] svn 22460 __set_errno: void
__set_winsock_errno(const char*, int):224 setting errno 11
   31 1078812 [main] svn 22460 __set_winsock_errno: recv_internal:1604
- winsock error 10035 -> errno 11
   51 1078863 [main] svn 22460 read: -1 = read(3, 0x6000DBEA4, -1), errno 11
--- Process 22460, exception c005 at 

Cygcheck does not show anything unusual. This is with Cygwin
2.8.0(0.309/5/3) on AMD64.

-- 
VH

--
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: Sometimes Emacs sticks on forking...

[Václav Haisman]

On 12 June 2017 at 23:30, Oleksandr Gavenko  wrote:
> I use latest Cygwin Emacs W32 under Windows 10 x64 and Emacs spawns external
> processes like hg/git when it open file.
>
> Sometimes it freezes and in procexp I see spawned Emacs fork.
>
> Usual build-in Emacs C-g key binding doesn't help much (it work with lots of
> key press and long delay). It is faster to find Emacs fork in procexp and kill
> it.
>
> I've read
>
>   https://www.cygwin.com/faq.html#faq.using.fixing-fork-failures
>
> and some suggestion to debug is:
>
>   CYGWIN=detect_bloda
>
> How can I get messages from GUI program? Emacs W32 open conhost terminal
> buffer. Is that a place where I should expect warn message?
>
> What if problem occur in temporary spawned processes from Emacs? Do they
> attached to conhost terminal buffer?
>
> I have one BLODA, Windows Defender (win10 x64). How can I disable it? I see
> tricks like:
>
>   Windows Registry Editor Version 5.00
>
>   [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows Defender]
>   "DisableAntiSpyware"=dword:0001
>   "DisableRoutinelyTakingAction"=dword:0001
>
> I have Home license and have no access to Group Policy editor...
>

We do not use Windows Defender and I am seeing this occasionally as
well. We use McAfee though.

-- 
VH

--
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

Python2 "narrow" build, Unicode issue in regex package

[Václav Haisman]

Hi.

I have recently hit an issue ([1]) with Python 2.7 and regex package
for it on Cygwin. It appears that Cygwin's Python 2.7 is so called
narrow build. This causes issues when working with Unicode code point
outside BMP, like the emoji code points in my issue.

Is there a chance Cygwin's Python could be rebuilt as a wide build?

[1] 
https://bitbucket.org/mrabarnett/mrab-regex/issues/241/issues-matching-unicode-code-ranges-with-p


-- 
VH

--
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: find / without traversing /proc

[Václav Haisman]

On 27 April 2017 at 10:49, wrote:
> The command "find /" takes forever, if it completes at all, because of the
> need to traverse the induced directory /proc. Is this directory often
> needed by users? Can it be skipped by setting up "export CYGWIN=something",
> or even by default, with the requirement on the user to induce it if needed?
> There seems to be no switch to the command find that would easily allow
> "but not this subdirectory": if there was, I wouldn't be asking. Quite a
> lot of surfing led me to
> $ find / \( -wholename /proc -o -wholename /dev \) -prune -o -print
> which is really heavyweight syntax for a simple requirement. I am pretty
> certain it leads to the behaviour required "do not traverse" though various
> posters seem to think it just leads to "traverse but do not report" saving
> almost nothing.
> Assuming the syntax is correct, I have not been able to incorporate any
> qualifiers such as -type d or -type f or -type l. Any ideas where to slot
> these so that they work?

Doesn't the -xdev switch help with this?

--VH

--
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: Maintaining expect (the broken pipe errors)

[Václav Haisman]

On 10 April 2017 at 01:06, Daniel Santos  wrote:
> I should probably import this onto my github account.  There doesn't appear
> to be an actual repository for expect at the moment.  There are many
> terrible coding practices employed, potential use of uninitialized locals,
> etc.  I'm going to do some basic cleanup before I dig back into trying to
> find the cause of the child processes unexpectedly terminating (while
> calling an ioctl to change the terminal windows size), which is what's
> causing the broken pipe.

What is the exit code of the process? Could it be somehow mishandled SIGWINCH?


-- 
VH

--
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

Guile update? Missing `scandir`

[Václav Haisman]

Hi.

My project is using Autogen to generate makefiles but it used
`scandir` function which appears to be missing from the version of
Guile that Cygwin package provides. Would it be possible to update
Guile to something more recent which does contain the `scandir`
function implementation? See also
https://www.gnu.org/software/guile/manual/html_node/File-Tree-Walk.html.

-- 
VH

--
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: C++11 thread_local implementation issue on Cygwin/AMD64

[Václav Haisman]

On 9 February 2016 at 15:23, Václav Haisman  wrote:
> On 19 May 2015 at 10:52, Václav Haisman  wrote:
>> On 19 January 2015 at 15:42, Václav Haisman wrote:
>>>
>>> Hi.
>>>
>>> I have hit an issue with thread-local storage variables on
>>> Cygwin/AMD64, I do not see it with Cygwin/i686.
>>>
>>> I am having linking issues when using `thread_local` keyword in Cygwin
>>> with its GCC 4.8.3 and GCC 4.9.2. This is derived from log4cplus. The
>>> test case is split into three files:
>>>
>>> File def.hxx:
>>>
>>> 
>>> #include 
>>>
>>> namespace N
>>> {
>>>   struct S { std::string str; };
>>>   // extern declaration in a header
>>>   extern thread_local S * ptd;
>>>
>>>   // accessing the extern declared ptd here
>>>   inline
>>>   S * get_ptd ()
>>>   {
>>> if (! ptd)
>>>   ptd = new S;
>>> return ptd;
>>>   }
>>> } // namespace N
>>> 
>>>
>>> File def.cxx:
>>>
>>> 
>>> #include "def.hxx"
>>>
>>> namespace N
>>> {
>>>   // definition of ptd
>>>   thread_local S * ptd = nullptr;
>>> } // namespace N
>>> ~~~
>>>
>>> File use.cxx:
>>>
>>> 
>>> #include "def.hxx"
>>>
>>> namespace N
>>> {
>>>   __declspec(dllexport)
>>>   void * foo ()
>>>   {
>>> // invoking inline get_ptd() function to get the value in ptd
>>> return get_ptd ();
>>>   }
>>> }
>>> 
>>>
>>> Now, when I compile each .cxx with `g++ -std=gnu++11
>>> -fvisibility=hidden -c use.cxx def.cxx` and then try to link with `g++
>>> -shared -o cygtest.dll use.o def.o`, I get the following error from
>>> linker:
>>>
>>> 
>>> use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation
>>> truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
>>> function for N::ptd'
>>> collect2: error: ld returned 1 exit status
>>> 
>>>
>>> The nm -C ./def.o output confirms that:
>>>
>>> 
>>> `--> nm -C ./def.o
>>>  b .bss
>>>  d .data
>>>  r .rdata
>>>  r .rdata$zzz
>>>  t .text
>>> 0008 r __emutls_t._ZN1N3ptdE
>>>  D __emutls_v._ZN1N3ptdE
>>>  r std::piecewise_construct
>>> 
>>>
>>> As you can see, the ptd thread-local variable initialization function
>>> is not defined anywhere. The use.o references this initialization
>>> function (see bottom of the listing):
>>>
>>> 
>>> `--> nm -C ./use.o
>>>  b .bss
>>>  d .data
>>>  i .drectve
>>>  p .pdata
>>>  p .pdata$_ZN1N1SC1Ev
>>>  p .pdata$_ZN1N7get_ptdEv
>>>  p .pdata$_ZTWN1N3ptdE
>>>  r .rdata
>>>  r .rdata$.refptr.__emutls_v._ZN1N3ptdE
>>>  r .rdata$.refptr._ZTHN1N3ptdE
>>>  r .rdata$zzz
>>>  R .refptr.__emutls_v._ZN1N3ptdE
>>>  R .refptr._ZTHN1N3ptdE
>>>  t .text
>>>  t .text$_ZN1N1SC1Ev
>>>  t .text$_ZN1N7get_ptdEv
>>>  t .text$_ZTWN1N3ptdE
>>>  A .weak._ZTHN1N3ptdE._ZN1N1SC1Ev
>>>  r .xdata
>>>  r .xdata$_ZN1N1SC1Ev
>>>  r .xdata$_ZN1N7get_ptdEv
>>>  r .xdata$_ZTWN1N3ptdE
>>>  U __emutls_get_address
>>>  U __emutls_v._ZN1N3ptdE
>>>  U __gxx_personality_seh0
>>>  U __real__ZdlPv
>>>  U __real__Znwm
>>>  U _Unwind_Resume
>>>  U operator delete(void*)
>>>  T N::S::S()
>>>  T N::foo()
>>>  T N::get_ptd()
>>>  U std::basic_string,
>>> std::allocator >::basic_string()
>>>  U operator new(unsigned long)
>>>  r std::piecewise_construct
>>>  w TLS init function for N::ptd
>>>  T TLS wrapper function for N::ptd
>>> 
>>>
>>> Now, this code seems to work well on Linux with both GCC and Clang.
>>>
>>> Is this a GCC problem on Cygwin?
>>> Am I using extern thread_local wrong?
>>>
>>> My experiments show that not using the extern keyword seems to fix the
>>> issue. But I am not sure if that does not introduce two ptd
>>> thread-local variables in two TUs.
>>>
>>> See also http://stackoverflow.com/q/28023728/341065
>>
>>
>> This is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697.
>
> Annual ping. :)

Annual ping for 2017. :)

-- 
VH

--
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: zp_fontconfig_cache_1.sh exit code 2

[Václav Haisman]

On 13 June 2016 at 01:35, Ken Brown  wrote:
> On 6/12/2016 7:26 PM, Mark McGregor wrote:
>>
>> Ken wrote:
>>>
>>> I obtained the output in the attachment, which looks good. Are you saying
>>> that the message is bogus and no action is needed?
>>
>>
>> Yes.
>> 
>>
>> Ok, thanks! It is nice to know than nothing is broken in this respect. But
>> it would be also nice to get less bogus messages.
>
>
> Agreed.  I took a brief look at the fontconfig code at one point to see if I
> could figure out why this was happening, but I didn't succeed and didn't
> feel like spending a lot of time on it.
>
> Ken

I have recently experienced this as well. Some sources
(https://bugs.archlinux.org/task/6024 and
http://www.mail-archive.com/debian-bugs-dist@lists.debian.org/msg266900.html)
suggest that it is some sort of time stamp related issue?

-- 
VH

--
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: libav or ffmpeg and associated tools

[Václav Haisman]

On 19 June 2016 at 23:51, Brian Mathis wrote:
> Is there any reason not to use the native Windows build instead?  What
> does the cygwin port gain you over that?

I know I could use Windows native tools. That is not the point, however. I
want Cygwin tools because I use Cygwin and I want the tools to understand
POSIX paths.

>
>
> On Thu, Jun 16, 2016 at 12:02 PM, David Stacey  wrote:
>> On 16/06/16 13:49, Marco Atzeri wrote:
>>>
>>> On 16/06/2016 14:44, Václav Haisman wrote:
>>>>
>>>> Hi.
>>>>
>>>> I have noticed a lack of ffmpeg and/or libav and associated tools on
>>>> Cygwin. It would be nice to have them.
>>>>
>>>> But I am not going to try and package them, sorry. :)
>>>>
>>>
>>> same reason as fedora...
>>>
>>>
>>> http://rpmfusion.org/FAQ#Why_doesn.27t_the_Fedora_project_ship_the_Software_that_RPM_Fusion_offers.3F
>>
>>
>>
>> ffmpeg-2.6.3 is available in CygwinPorts.
>> http://cygwinports.org/
>>
>> Dave.


-- 
VH

--
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

libav or ffmpeg and associated tools

[Václav Haisman]

Hi.

I have noticed a lack of ffmpeg and/or libav and associated tools on
Cygwin. It would be nice to have them.

But I am not going to try and package them, sorry. :)

-- 
VH

--
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: pthread_attr_init() returning errors

[Václav Haisman]

On 19.4.2016 21:49, Canham, Timothy K (348C) wrote:
> I have some code to start a task that suddenly started failing. This is 
> pretty mature code. Here is the code fragment with my added printf()
> 
> pthread_attr_t att;
> int stat = pthread_attr_init(&att);
> if (stat != 0) {
> printf("pthread_attr_init: (%d)(%d): 
> %s\n",stat,errno,strerror(stat));
> // return
> }
> 
> Here is the output:
> 
> pthread_attr_init: (16)(0): Device or resource busy
> 
> If I don't return in the if statement, the subsequent pthread_create() seems 
> to work just fine.

Does it work if you do `memset(&att, 0, sizeof(att));` before the
`pthread_attr_init(&att)`?

-- 
VH



signature.asc
Description: OpenPGP digital signature

Re: C++11 thread_local implementation issue on Cygwin/AMD64

[Václav Haisman]

On 19 May 2015 at 10:52, Václav Haisman  wrote:
> On 19 January 2015 at 15:42, Václav Haisman wrote:
>>
>> Hi.
>>
>> I have hit an issue with thread-local storage variables on
>> Cygwin/AMD64, I do not see it with Cygwin/i686.
>>
>> I am having linking issues when using `thread_local` keyword in Cygwin
>> with its GCC 4.8.3 and GCC 4.9.2. This is derived from log4cplus. The
>> test case is split into three files:
>>
>> File def.hxx:
>>
>> 
>> #include 
>>
>> namespace N
>> {
>>   struct S { std::string str; };
>>   // extern declaration in a header
>>   extern thread_local S * ptd;
>>
>>   // accessing the extern declared ptd here
>>   inline
>>   S * get_ptd ()
>>   {
>> if (! ptd)
>>   ptd = new S;
>> return ptd;
>>   }
>> } // namespace N
>> 
>>
>> File def.cxx:
>>
>> 
>> #include "def.hxx"
>>
>> namespace N
>> {
>>   // definition of ptd
>>   thread_local S * ptd = nullptr;
>> } // namespace N
>> ~~~
>>
>> File use.cxx:
>>
>> 
>> #include "def.hxx"
>>
>> namespace N
>> {
>>   __declspec(dllexport)
>>   void * foo ()
>>   {
>> // invoking inline get_ptd() function to get the value in ptd
>> return get_ptd ();
>>   }
>> }
>> 
>>
>> Now, when I compile each .cxx with `g++ -std=gnu++11
>> -fvisibility=hidden -c use.cxx def.cxx` and then try to link with `g++
>> -shared -o cygtest.dll use.o def.o`, I get the following error from
>> linker:
>>
>> 
>> use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation
>> truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
>> function for N::ptd'
>> collect2: error: ld returned 1 exit status
>> 
>>
>> The nm -C ./def.o output confirms that:
>>
>> 
>> `--> nm -C ./def.o
>>  b .bss
>>  d .data
>>  r .rdata
>>  r .rdata$zzz
>>  t .text
>> 0008 r __emutls_t._ZN1N3ptdE
>>  D __emutls_v._ZN1N3ptdE
>>  r std::piecewise_construct
>> 
>>
>> As you can see, the ptd thread-local variable initialization function
>> is not defined anywhere. The use.o references this initialization
>> function (see bottom of the listing):
>>
>> 
>> `--> nm -C ./use.o
>>  b .bss
>>  d .data
>>  i .drectve
>>  p .pdata
>>  p .pdata$_ZN1N1SC1Ev
>>  p .pdata$_ZN1N7get_ptdEv
>>  p .pdata$_ZTWN1N3ptdE
>>  r .rdata
>>  r .rdata$.refptr.__emutls_v._ZN1N3ptdE
>>  r .rdata$.refptr._ZTHN1N3ptdE
>>  r .rdata$zzz
>>  R .refptr.__emutls_v._ZN1N3ptdE
>>  R .refptr._ZTHN1N3ptdE
>>  t .text
>>  t .text$_ZN1N1SC1Ev
>>  t .text$_ZN1N7get_ptdEv
>>  t .text$_ZTWN1N3ptdE
>>  A .weak._ZTHN1N3ptdE._ZN1N1SC1Ev
>>  r .xdata
>>  r .xdata$_ZN1N1SC1Ev
>>  r .xdata$_ZN1N7get_ptdEv
>>  r .xdata$_ZTWN1N3ptdE
>>  U __emutls_get_address
>>  U __emutls_v._ZN1N3ptdE
>>  U __gxx_personality_seh0
>>  U __real__ZdlPv
>>  U __real__Znwm
>>  U _Unwind_Resume
>>  U operator delete(void*)
>>  T N::S::S()
>>  T N::foo()
>>  T N::get_ptd()
>>  U std::basic_string,
>> std::allocator >::basic_string()
>>  U operator new(unsigned long)
>>  r std::piecewise_construct
>>  w TLS init function for N::ptd
>>  T TLS wrapper function for N::ptd
>> 
>>
>> Now, this code seems to work well on Linux with both GCC and Clang.
>>
>> Is this a GCC problem on Cygwin?
>> Am I using extern thread_local wrong?
>>
>> My experiments show that not using the extern keyword seems to fix the
>> issue. But I am not sure if that does not introduce two ptd
>> thread-local variables in two TUs.
>>
>> See also http://stackoverflow.com/q/28023728/341065
>
>
> This is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697.

Annual ping. :)

-- 
VH

--
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 32bit: Can't use gcc -mfpmath=sse

[Václav Haisman]

On 10 September 2015 at 01:30, HK wrote:
> I've just run across this strange behavior on a recent 32bit installation:
>
>  vega> cat hello.c
> #include 
> int main(int argc, char** argv){
> printf("hello world\n");
> }
>  vega> gcc -mfpmath=sse hello.c
> hello.c:1:0: warning: SSE instruction set disabled, using 387 arithmetics

Does it help to use `-march=native`? My hunch is that this is because
the default CPU type is set to such that does not have SSE.

>  #include 
>  ^
>
> Why is this? I am pretty sure this used to work in the past.  On the 64bit
> installtion it works just fine.
>
> For reference:
>
>  vega> gcc -v
> Using built-in specs.
> COLLECT_GCC=gcc
> COLLECT_LTO_WRAPPER=/usr/lib/gcc/i686-pc-cygwin/4.9.3/lto-wrapper.exe
> Target: i686-pc-cygwin
> Configured with:
> /cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3/configure
> --srcdir=/cygdrive/i/szsz/tmpp/gcc/gcc-4.9.3-1.i686/src/gcc-4.9.3
> --prefix=/usr --exec-prefix=/usr --localstatedir=/var --sysconfdir=/etc
> --docdir=/usr/share/doc/gcc --htmldir=/usr/share/doc/gcc/html -C
> --build=i686-pc-cygwin --host=i686-pc-cygwin --target=i686-pc-cygwin
> --without-libiconv-prefix --without-libintl-prefix --libexecdir=/usr/lib
> --enable-shared --enable-shared-libgcc --enable-static
> --enable-version-specific-runtime-libs --enable-bootstrap
> --enable-__cxa_atexit --with-dwarf2 --with-arch=i686 --with-tune=generic
> --disable-sjlj-exceptions
> --enable-languages=ada,c,c++,fortran,java,lto,objc,obj-c++ --enable-graphite
> --enable-threads=posix --enable-libatomic --enable-libgomp --disable-libitm
> --enable-libquadmath --enable-libquadmath-support --enable-libssp
> --enable-libada --enable-libjava --enable-libgcj-sublibs --disable-java-awt
> --disable-symvers --with-ecj-jar=/usr/share/java/ecj.jar --with-gnu-ld
> --with-gnu-as --with-cloog-include=/usr/include/cloog-isl
> --without-libiconv-prefix --without-libintl-prefix --with-system-zlib
> --enable-linker-build-id
> Thread model: posix
> gcc version 4.9.3 (GCC)
>  vega>


-- 
VH

--
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] sys/signal.h: include sys/ucontext.h on Cygwin per POSIX.1-2008

[Václav Haisman]

On 18 August 2015 at 11:10, Corinna Vinschen wrote:
> On Aug 17 21:46, Yaakov Selkowitz wrote:
>> * libc/include/sys/signal.h [__CYGWIN__]: include 
>> if compiling for POSIX.1-2008.
>>
>> Signed-off-by: Yaakov Selkowitz 
>> ---
>> How about this?  Other places I tried didn't compile.
>>
>>  newlib/libc/include/sys/signal.h | 6 ++
>>  1 file changed, 6 insertions(+)
>>
>> diff --git a/newlib/libc/include/sys/signal.h 
>> b/newlib/libc/include/sys/signal.h
>> index af5a489..e9aba7c 100644
>> --- a/newlib/libc/include/sys/signal.h
>> +++ b/newlib/libc/include/sys/signal.h
>> @@ -352,6 +352,12 @@ int _EXFUN(sigqueue, (pid_t pid, int signo, const union 
>> sigval value));
>>  }
>>  #endif
>>
>> +#if defined(__CYGWIN__)
>> +#if __POSIX_VISIBLE >= 200809
>> +#include 
>> +#endif
>> +#endif
>> +
>>  #ifndef _SIGNAL_H_
>>  /* Some applications take advantage of the fact that 
>>   * and  are equivalent in glibc.  Allow for that here.  */
>> --
>> 2.4.3
>
> Looks good, I applied the patch.

Thank you both.

-- 
VH

--
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

si_band member of struct siginfo_t is not available

[Václav Haisman]

Hi.

One more thing that I have noticed, the `si_band` member of `struct
siginfo_t` is not available. See
.

-- 
VH

--
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

ucontext_t is not available from signal.h

[Václav Haisman]

Hi.

I have just noticed, while porting my stuff from Linux to Cygwin, that
signal.h does not provide `ucontext_t`. It should be available from
signal.h. From 
:

> The ucontext_t and mcontext_t structures are added here from the obsolescent 
>  header.

-- 
VH

--
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 version detection at run time

[Václav Haisman]

On 14 August 2015 at 17:44, Corinna Vinschen wrote:
> On Aug 14 17:08, Václav Haisman wrote:
>> On 14 August 2015 at 16:11, Eliot Moss wrote:
>> > On 8/14/2015 9:56 AM, Václav Haisman wrote:
>> >>
>> >> Hi.
>> >>
>> >> I am trying to find out Cygwin version at run time.
>> >>
>> >> I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API
>> >> for this. However, it seems that the `cygwin_version_info` structure
>> >> this call is supposed to fill in is not publicly available and is only
>> >> declared internally in `winsup/cygwin/cygwin_version.h`.
>> >>
>> >> Am I right that my only option is either to copy the internal
>> >> declaration of the structure or to use `/proc/version` and parse the
>> >> version string out of that?
>> >
>> >
>> > There's uname, whose options allow getting various parts of what
>> > /proc/version gives you.  uname is also somewhat portable across
>> > different flavors of linux ...
>>
>> Never mind, I have figured it out. The  `cygwin_internal
>> (CW_GETVERSIONINFO)`  actually returns a pointer to string which can
>> be parsed reliably. I have used it.
>
> cygwin_internal(CW_GETVERSIONINFO) is an API for non-Cygwin tools like
> cygcheck, not for general consumption.  For a Cygwin executable, better
> use uname(2) instead.

Thanks. Uname call's utsname structure is much easier to parse.

-- 
VH

--
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 version detection at run time

[Václav Haisman]

On 14 August 2015 at 16:11, Eliot Moss  wrote:
> On 8/14/2015 9:56 AM, Václav Haisman wrote:
>>
>> Hi.
>>
>> I am trying to find out Cygwin version at run time.
>>
>> I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API
>> for this. However, it seems that the `cygwin_version_info` structure
>> this call is supposed to fill in is not publicly available and is only
>> declared internally in `winsup/cygwin/cygwin_version.h`.
>>
>> Am I right that my only option is either to copy the internal
>> declaration of the structure or to use `/proc/version` and parse the
>> version string out of that?
>
>
> There's uname, whose options allow getting various parts of what
> /proc/version gives you.  uname is also somewhat portable across
> different flavors of linux ...

Never mind, I have figured it out. The  `cygwin_internal
(CW_GETVERSIONINFO)`  actually returns a pointer to string which can
be parsed reliably. I have used it.

-- 
VH

--
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

Cygwin version detection at run time

[Václav Haisman]

Hi.

I am trying to find out Cygwin version at run time.

I have noticed that there is `cygwin_internal (CW_GETVERSIONINFO)` API
for this. However, it seems that the `cygwin_version_info` structure
this call is supposed to fill in is not publicly available and is only
declared internally in `winsup/cygwin/cygwin_version.h`.

Am I right that my only option is either to copy the internal
declaration of the structure or to use `/proc/version` and parse the
version string out of that?

-- 
VH

--
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: C++11 thread_local implementation issue on Cygwin/AMD64

[Václav Haisman]

On 19 January 2015 at 15:42, Václav Haisman wrote:
>
> Hi.
>
> I have hit an issue with thread-local storage variables on
> Cygwin/AMD64, I do not see it with Cygwin/i686.
>
> I am having linking issues when using `thread_local` keyword in Cygwin
> with its GCC 4.8.3 and GCC 4.9.2. This is derived from log4cplus. The
> test case is split into three files:
>
> File def.hxx:
>
> 
> #include 
>
> namespace N
> {
>   struct S { std::string str; };
>   // extern declaration in a header
>   extern thread_local S * ptd;
>
>   // accessing the extern declared ptd here
>   inline
>   S * get_ptd ()
>   {
> if (! ptd)
>   ptd = new S;
> return ptd;
>   }
> } // namespace N
> 
>
> File def.cxx:
>
> 
> #include "def.hxx"
>
> namespace N
> {
>   // definition of ptd
>   thread_local S * ptd = nullptr;
> } // namespace N
> ~~~
>
> File use.cxx:
>
> 
> #include "def.hxx"
>
> namespace N
> {
>   __declspec(dllexport)
>   void * foo ()
>   {
> // invoking inline get_ptd() function to get the value in ptd
> return get_ptd ();
>   }
> }
> 
>
> Now, when I compile each .cxx with `g++ -std=gnu++11
> -fvisibility=hidden -c use.cxx def.cxx` and then try to link with `g++
> -shared -o cygtest.dll use.o def.o`, I get the following error from
> linker:
>
> 
> use.o:use.cxx:(.text$_ZTWN1N3ptdE[_ZTWN1N3ptdE]+0x15): relocation
> truncated to fit: R_X86_64_PC32 against undefined symbol `TLS init
> function for N::ptd'
> collect2: error: ld returned 1 exit status
> 
>
> The nm -C ./def.o output confirms that:
>
> 
> `--> nm -C ./def.o
>  b .bss
>  d .data
>  r .rdata
>  r .rdata$zzz
>  t .text
> 0008 r __emutls_t._ZN1N3ptdE
>  D __emutls_v._ZN1N3ptdE
>  r std::piecewise_construct
> 
>
> As you can see, the ptd thread-local variable initialization function
> is not defined anywhere. The use.o references this initialization
> function (see bottom of the listing):
>
> 
> `--> nm -C ./use.o
>  b .bss
>  d .data
>  i .drectve
>  p .pdata
>  p .pdata$_ZN1N1SC1Ev
>  p .pdata$_ZN1N7get_ptdEv
>  p .pdata$_ZTWN1N3ptdE
>  r .rdata
>  r .rdata$.refptr.__emutls_v._ZN1N3ptdE
>  r .rdata$.refptr._ZTHN1N3ptdE
>  r .rdata$zzz
>  R .refptr.__emutls_v._ZN1N3ptdE
>  R .refptr._ZTHN1N3ptdE
>  t .text
>  t .text$_ZN1N1SC1Ev
>  t .text$_ZN1N7get_ptdEv
>  t .text$_ZTWN1N3ptdE
>  A .weak._ZTHN1N3ptdE._ZN1N1SC1Ev
>  r .xdata
>  r .xdata$_ZN1N1SC1Ev
>  r .xdata$_ZN1N7get_ptdEv
>  r .xdata$_ZTWN1N3ptdE
>  U __emutls_get_address
>  U __emutls_v._ZN1N3ptdE
>  U __gxx_personality_seh0
>  U __real__ZdlPv
>  U __real__Znwm
>  U _Unwind_Resume
>  U operator delete(void*)
>  T N::S::S()
>  T N::foo()
>  T N::get_ptd()
>  U std::basic_string,
> std::allocator >::basic_string()
>  U operator new(unsigned long)
>  r std::piecewise_construct
>  w TLS init function for N::ptd
>  T TLS wrapper function for N::ptd
> 
>
> Now, this code seems to work well on Linux with both GCC and Clang.
>
> Is this a GCC problem on Cygwin?
> Am I using extern thread_local wrong?
>
> My experiments show that not using the extern keyword seems to fix the
> issue. But I am not sure if that does not introduce two ptd
> thread-local variables in two TUs.
>
> See also http://stackoverflow.com/q/28023728/341065


This is also https://gcc.gnu.org/bugzilla/show_bug.cgi?id=64697.

-- 
VH

--
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: Grepping Unicode files?

[Václav Haisman]

On 14.5.2015 17:42, Vince Rice wrote:
> uname says "CYGWIN_NT-6.1 machinename 1.7.35(0.287/5/3) 2015-03-04
> 12:07 i686 Cygwin”. I’m running grep 2.21.2, which cygcheck -c says
> is OK.
> 
> Does Cygwin’s grep support Unicode files? The output from a SQL
> Server SQL Agent job is a Unicode file, i.e. if you look at it in a
> hex editor every other character is 00 because each character is
> taking up two bytes. The filename itself is fine, it’s the contents
> that is Unicode. I can’t get grep to work on it, either with or
> without -a.

That sounds like UTF-16. Have you tried funneling it through `iconv` first?

> 
> This may not be a Cygwin-specific question, but I haven’t been able
> to find anything after several Google searches, including the
> archives, and neither --help nor the man page for grep references
> Unicode.
> 
> By default I have neither LC_ALL nor LC_COLLATE set.
> 
> A pointer to a better search or a website that explains this would be
> great, or if it can’t currently be done, that’s OK, too.
> 

-- 
VH



signature.asc
Description: OpenPGP digital signature

Re: unknown command diff

[Václav Haisman]

retrodans wrote, On 9.5.2011 13:26:
> 
> I am trying to run what is a basic diff of 2 tags in a repo, to see what
> changes have occurred between the 2.  But whenever I attempt to in cygwin I
> get the below error.  Is this a known issue, or do I need to set something
> up specially to get this working. Sorry I am newish to cygwin as use Ubuntu
> normally.
> 
> $ svn diff --summarize http://svn./tags/x/public
> http://svn./tags/y/public
> Unknown command: 'diff'
> Type 'svn help' for usage.
My guess is that you have not installed the diffutils package. I would know
for sure had you followed problem reporting procedure at
.

-- 
VH

--
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: The same assembly code but different result on cygwin and Centos

[Václav Haisman]

matthew chao wrote, On 26.4.2011 4:52:
> The code below assigns an integer number 20 to %ebx,  which  can be
> CORRECTLY assembled on both cygwin and CentOS,
> 
> ###code begin###
> .section .data
> items:
> .long  20
> 
> .section .text
> .globl _start
> _start:
>   movl $0,%edi
>   movl items(,%edi,4),%eax
>   movl %eax,%ebx
> 
>   movl $1,%eax
>   int $0x80
>[...]
Cygwin is Linux emulation DLL, it runs on top of Win32 API. It does not
emulate Linux' syscalls; it cannot emulate that.

-- 
VH

--
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: python select() is limited to fds < 64

[Václav Haisman]

Jon TURNEY wrote, On 22.3.2011 20:29:
> 
> python seems to be built with the default value of FD_SETSIZE, which is only
> 64 on cygwin.
Is this not because of the inherent limitation of WaitForMultipleObjects() call?

> [...]

-- 
VH

--
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: How do I make a COM port in windows accessible using cygwin?

[Václav Haisman]

Vinod Pillai wrote, On 15.3.2011 21:03:
> 
> Im sorry but Im a complete novice at this. I cd-ed into the /dev folder. But
> I could not find a ttyS1. If you could elaborate what exactly I must do, it
> would be helpful. Thank you.
Read the page I have linked: "These devices cannot be seen with the command
ls /dev/ although commands such as ls /dev/tty work fine."

-- 
VH

> 
> Vinod
> 
> 
> Vaclav Haisman wrote:
>>
>>  On Tue, 15 Mar 2011 06:18:00 -0700 (PDT), Vinod Pillai wrote:
>>> I have a virtual serial port set up on my COM2 port. I am trying to 
>>> run a
>>> program on cygwin which will require the use of this serial port on 
>>> COM2. I
>>> was wondering how I could connect to the COM port using cygwin?
>>  See 
>>
>> .
>>  
>>  You probably want /dev/ttyS1 for COM2.
>>
>> -- 
>>  VH
>>
>>
>> --
>> 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: How do I make a COM port in windows accessible using cygwin?

[Václav Haisman]

On Tue, 15 Mar 2011 06:18:00 -0700 (PDT), Vinod Pillai wrote:
I have a virtual serial port set up on my COM2 port. I am trying to 
run a
program on cygwin which will require the use of this serial port on 
COM2. I

was wondering how I could connect to the COM port using cygwin?
See 
. 
You probably want /dev/ttyS1 for COM2.


--
VH


--
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: err.h declarations not marked noreturn.

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eric Blake wrote, On 2.2.2011 0:45:
> On 02/01/2011 03:41 PM, Rusty Russell wrote:
>> OK, your /usr/include/err.h doesn't have the annotations to tell gcc that it
>> doesn't return.
> 
> I'm a bit surprised that cygwin provides the BSD interface err() but
> lacks the glibc interface error() from "error.h", even though both
> interfaces are equally non-standard, and cygwin strives more for Linux
> compatibility.  But that's besides the point.
It should not be surprising. Cygwin strives to be Linux compatbile using
source code from *BSD systems. Implementation of err() can just be copied
from *BSD. The GNU stuff has to be implemented from scratch, if I understand
the lincense correctly.

>[...]

- -- 
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk1JFikACgkQeqrf2dJjGj46tgD/XjOchRFz1bs2SdBFSvLsASmD
Mgg9KNnBqLTtclj1i/8A/i3puCnHek6RtDiMBi2otJk+bP0wBsjx0nKwyaz+mYEF
=xYk0
-END PGP SIGNATURE-

--
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: Installing dillo

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

jwzumwalt wrote, On 17.12.2010 7:19:
> 
> I am attempting to install dillo
> I successfully installed fltk-2.0.x-r7725 and Fluid runs OK.
> When I attempt to install Dillo, the ./configure and make run OK
> after quite a bit of opperation make install reports
> 
> /usr/local/lib/libfltk2.a(run.o):run.cxx:(.text$_ZN12FlDropTarget14QueryInterfac
> eERK5_GUIDPPv+0x15): undefined reference to `_IID_IUnknown'
_IID_IDropSource looks like it is trying also use Windows OLE/COM. Is that
even supported by Cygwin/X applications? Are you sure that you are trying to
compile Cygwin application and not Windows/Mingw application? You try to get
support from Dillo guys, not Cygwin, I think. Either way, you should provide
enough information, like how you have configured it.

Adding -lole32 at the end of the command that is linking it might fix it.


> /usr/local/lib/libfltk2.a(run.o):run.cxx:(.text$_ZN12FlDropTarget14QueryInterfac
> eERK5_GUIDPPv+0x44): undefined reference to `_IID_IDropTarget'
> /usr/local/lib/libfltk2.a(dnd.o):dnd.cxx:(.text$_ZN12FLDataObject14QueryInterfac
> eERK5_GUIDPPv+0x15): undefined reference to `_IID_IUnknown'
> /usr/local/lib/libfltk2.a(dnd.o):dnd.cxx:(.text$_ZN12FLDataObject14QueryInterfac
> eERK5_GUIDPPv+0x44): undefined reference to `_IID_IDataObject'
> /usr/local/lib/libfltk2.a(dnd.o):dnd.cxx:(.text$_ZN12FLDropSource14QueryInterfac
> eERK5_GUIDPPv+0x15): undefined reference to `_IID_IUnknown'
> /usr/local/lib/libfltk2.a(dnd.o):dnd.cxx:(.text$_ZN12FLDropSource14QueryInterfac
> eERK5_GUIDPPv+0x44): undefined reference to `_IID_IDropSource'

>[...]

- -- 
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAk0LC3EACgkQeqrf2dJjGj62JwEAoll4zDhIj+4f9IOvgtF2hQun
DWBrNODatUforhhHyX0BAMCmZHo3/2yPD/MSTmixcIdWCNEdwIAhpIwzgZN5LHOk
=3wfI
-END PGP SIGNATURE-

--
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: copy cygwin installation to a different location and preserving all "cygwin" rights

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Thomas Jung wrote, On 10.11.2010 14:40:
> Hello,
> 
> I would like to "move" my cygwin installation to
> a different location, but preserving the usual paths to
> all the apps by using a junction point to that moved/copied
> subtree of cygwin.
> 
> The 1st main problem ist that copy/move with the windows
> explorer (xcopy) doesn't preserve all the rights.
> 
> How can I copy the whole cygwin subtree to a new location
> an preserving all the "cgwin/unix-styled" rights (I don't mean the
> windows rights)
The Cygwin file permissions are ultimatelly mapped to ACLs on NTFS. What
about trying some native Windows backup utility? It should let you extract
the backup into directory of your choice and it should also transfer all the
ACLs.

- -- 
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkza+/QACgkQeqrf2dJjGj5BaQD/f93YmuZiCoCfhcxZxl3Pz8ty
pj1H4724RnmB1RB2JJkA/Amb8FSZAnoSYFdtU+mEuT7ZWghiYD0jCEL0CTF/i2Sl
=wpFm
-END PGP SIGNATURE-

--
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: rand() was not declared in this scope, please help‏

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

eric lin wrote, On 8.9.2010 19:35:
> dear cygwin/gcc users:
>  
>   I compile a simple code which i copied from a book, "The Complete Reference 
> of C++"  Fourth Edition by Herbert Schildt in page 575, rand()
> which is clearly not be included in
> #include 
>  
> I tried 
> #inlcude 
>  
> it still not compile, i.e. same compile error
>  
> please help(see which lib I should include)
> /* I tried in ubuntu linux on my laptop, it also not compile by same reason */
You need to #include  and use std::rand().

- -- 
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iF4EAREIAAYFAkyHyhoACgkQeqrf2dJjGj4mMwD+L7zWAHf7L34vlph03R5TY4Rw
pizg2rsAWzelNkZHYGoBAMMSTJU7BF65E84+U5SAn2avkW/ZNGnGsj/aHeRnZHex
=4x2u
-END PGP SIGNATURE-

--
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: boxes.sh grep: Unmatched [ or [^ at egrep '[[:space]]'

[Václav Haisman]

On Mon, 9 Aug 2010 11:05:12 +0200, Reini Urban wrote:
> Jaro,
> 
> Our nice new setup found a problem in the boxes postinstall script:
> Package: boxes
>   boxes.sh exit code 2
> Package: No package
>   boxes.sh exit code 2
> 
> cd /etc/postinstall
> $ ./boxes.sh
> grep: Unmatched [ or [^
> 
> in grep -E '^[^#]*/|^[[:space]]*$'
/etc/preremove/boxes-manifest-from.lst
> and it is the [[:space]] part, which is broken. Per man grep it should
> work, but I don't know those specialities too well.
Should that not be '[[:space:]]'? Without the single quotes.

-- 
VH


--
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: Interesting discovery in the C library that Cygwin uses

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gregg Levine wrote, On 9.7.2010 1:34:
> Hello!
> I made this discovery whilst building the urjtag program from its SVN trunk:
> make[3]: Entering directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap'
>  CC tap.lo
>  CC register.lo
>  CC state.lo
>  CC chain.lo
>  CC detect.lo
> detect.c: In function `find_record':
> detect.c:89: warning: array subscript has type `char'
> detect.c:96: warning: array subscript has type `char'
> detect.c:107: warning: array subscript has type `char'
> detect.c:125: warning: array subscript has type `char'
> detect.c:134: warning: array subscript has type `char'
> detect.c:150: warning: array subscript has type `char'
> make[3]: *** [detect.lo] Error 1
> make[3]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src/tap'
> make[2]: *** [all-recursive] Error 1
> make[2]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag/src'
> make[1]: *** [all-recursive] Error 1
> make[1]: Leaving directory `/usr/local/urjtag/urjtag/trunk/urjtag'
> make: *** [all] Error 2
> The fix, temporarily as it happens was to add to the configure script
> this one: --disable-werror . The chap who suggested it also suggested
> that I complain here. It was described as  an isspace() has an issue,
> I won't use the term he used.
> 
> The code can be found at http://urjtag.sf.net as it happens.
> 
> Basically the program supporter there wants the people here for Cygwin
> to, ah, fix their C library. I'm not convinced that's necessary, but
> which C library is used here? And what could be fixed?
- From the ctype.h:

/* These macros are intentionally written in a manner that will trigger
   a gcc -Wall warning if the user mistakenly passes a 'char' instead
   of an int containing an 'unsigned char'.  Note that the sizeof will
   always be 1, which is what we want for mapping EOF to __ctype_ptr__[0];
   the use of a raw index inside the sizeof triggers the gcc warning if
   __c was of type char, and sizeof masks side effects of the extra __c.
   Meanwhile, the real index to __ctype_ptr__+1 must be cast to int,
   since isalpha(0x10001LL) must equal isalpha(1), rather than being
   an out-of-bounds reference on a 64-bit machine.  */
#define __ctype_lookup(__c) ((__ctype_ptr__+sizeof(""[__c]))[(int)(__c)])

The interesting part: "These macros are intentionally written in a manner
that will trigger a gcc -Wall warning if the user mistakenly passes a 'char'
instead of an int containing an 'unsigned char'."

And this is from SUSv3: "The c argument is an int, the value of which the
application shall ensure is a character representable as an unsigned char or
equal to the value of the macro EOF. If the argument has any other value, the
behavior is undefined."

His code invokes undefined behaviour in case the char value is negative. The
warning is a good thing. He IMHO needs to fix his code.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.7 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iD8DBQFMNqTjr2CghdezFMkRCOKcAKDAjf97aQkCOMnChHklmF1h0P777gCfSfCo
7iVQdH4YBv9uPhyW0xNfAZo=
=smu3
-END PGP SIGNATURE-

--
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: gcc4: throwing exception from signal handler

[Václav Haisman]

On Thu, 8 Jul 2010 09:01:41 -0400, "Don Ward" wrote:
> I would like to be able to catch certain signals (SIGSEGV and SIGSYS)
and 
> throw a C++ exception (to be caught in a try/catch construct).  As a
> simple 
> example:
>[...] 
> Am I misunderstanding how this should work or doing something wrong?  Or
> is 
> this a problem with Cygwin or gcc?
I do not think that handling SIGSEGV with an exception is a good idea.
Unless you get SIGSEGV as a result of some well thought through memory
management games, at the point you get SIGSEGV your state is probably so
foobar'd that trying to execute more code can only make it worse. It is
pretty much unrecoverable condition. From diagnostic POV, getting a core
dump with the error state seems better than anything you could do with the
exception.

I am not sure but I do not think that throwing exceptions from signal
handlers is generally supported. Somebody will certainly correct me if I am
wrong.

--
VH


--
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: Rebaseall fails with error 6 on cygcrypt-0.dll

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Alex Leigh wrote, On 4.7.2010 9:20:
> On Sun, Jul 4, 2010 at 1:07 AM, Larry Hall (Cygwin) wrote:
>> On 7/4/2010 1:01 AM, Alex Leigh wrote:
>>>
>>> Hi,
>>>
>>> I've been getting some STATUS_ACCESS_VIOLATION errors when running
>>> bash and some xwin programs, and after some searching I'm trying to
>>> run rebaseall to see if that would fix the problem. However, when
>>> running rebaseall from ash, I get the following error: "ReBaseImage
>>> (/usr/bin/cygcrypt-0.dll) failed with last error = 6". Searching
>>> around it seems error code 6 comes from the DLL being in use. However
>>> I made sure to close all running cygwin programs, and I went through
>>> each of my running programs to see if any of them loads that
>>> particular DLL, which none of them do. Could there be anything else
>>> that would cause rebaseall to fail on that particular DLL? Thanks.
>>> I've attached an output from cygcheck.
>>
>> Make sure you stopped all services and then reboot.
> 
> I rebooted, then shut down all non-essential programs and services,
> and still get the same error. This is baffling...is there anything
> else that could cause this error?
Download the Process Explorer and find out who is holding the file open.

- --
VH

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAkwwYV8ACgkQr2CghdezFMl1DQCglBWOA0A0mJYaFDBOKK5MTn01
K+MAoNuLRRu3sQFPUQe+F6XFQT/cgfTU
=krDb
-END PGP SIGNATURE-

--
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: svn do nothing

[Václav Haisman]

On Tue, 22 Jun 2010 18:14:38 +0800, Steven Woody wrote:
> Hi,
> 
> After I upgrade my cygwin to the latest version. the 'svn' program
> always returns nothing for me for any svn commands including the very
> simple 'svn --version' command.  It just simply return to the next
> command prompt without any output or an error.  What's wrong with it?
> Problem reports:   http://cygwin.com/problems.html
Use this:^^^

> FAQ:   http://cygwin.com/faq/
> Documentation: http://cygwin.com/docs.html
> Unsubscribe info:  http://cygwin.com/ml/#unsubscribe-simple

--
VH


--
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: Windows Server 2008 64-bit setup.exe/bash problem

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Ernest Mueller wrote, On 16.6.2010 22:55:
> 
> Hey all.  I was installing cygwin+openSSH on a couple systems and came
> across an issue.  I was installing on the stock Amazon EC2 Windows 2008
> Server builds.  The 32-bit one works perfectly.  On 64-bit, however, bash
> and all don't come in right.  Setup scripts don't run and bash segfaults.
> I'm installing as Administrator using the exact same procedure as I did 15
> minutes before on 2008 32-bit.  Ideas welcome!
> 
> Stack trace from bash crash during install:
> Exception: STATUS_ACCESS_VIOLATION at eip=774F930A
> eax= ebx=FF8A ecx= edx= esi=
> edi=0027C6E8
> ebp=61226084 esp=0027C69C program=C:\cygwin\bin\bash.exe, pid 1768, thread
> main
> cs=0023 ds=002B es=002B fs=0053 gs=002B ss=002B
> Stack trace:
> Frame Function  Args
> End of stack trace
Try turning on Vista compatibility for the setup.exe. And later for MinTTY or
any terminal, if you use it.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.10 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAkwZspMACgkQr2CghdezFMnb0ACfX08hYb4EmokVMWUyKzrQUg+D
XOgAnA3VoWcpiyot/V2GzxlnHblLYEwd
=ajwr
-END PGP SIGNATURE-

--
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: getlong()/getshort()/ns_get16()/ns_get32()

[Václav Haisman]

Dennis Yurichev wrote, On 16.5.2010 8:19:
> Hi.
> 
> I have a software using getlong()/getshort() functions which are also
> synonyms to ns_get32()/ns_get16().
> But they are removed from cygwin?
> Why and what to use instead of?
Wow. Having so badly named functions in public name space...

You cold reimplement the missing functions like this:

unsigned short
_getshort(unsigned char *ptr)
{
unsigned short x;
memcpy (&x, ptr, sizeof (x));
return x; // or return ntohs (x); if the data are in network byte order.
}

...

Actually, if you do grep over header files you will find that arpa/nameser.h
contains ns_get32() etc.

--
VH

--
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: vfork always fail problem

[Václav Haisman]

Huang Bambo wrote, On 14.5.2010 6:29:
> [ba...@bambo-notebook 4.4.4]$ cat tvfork.c
> #include 
> #include 
> #include 
> 
> int main(void)
> {
> pid_t pid = vfork();
> if ( pid > 0 )
> {
> printf("I'm chield.\n");
> _exit(0);
> }
> else if ( pid == 0 )
> {
> printf("I'm parent");
> }
> else
> {
> perror("vfork failed.");
> }
> }
> [ba...@bambo-notebook 4.4.4]$ make tvfork
> cc tvfork.c   -o tvfork
> [ba...@bambo-notebook 4.4.4]$ ./tvfork.exe
>   4 [main] tvfork 4136 fork: child -1 - CreateProcessW failed, errno 2
> vfork failed.: No such file or directory
> [ba...@bambo-notebook 4.4.4]$ ./tvfork
>   3 [main] tvfork 2956 fork: child -1 - CreateProcessW failed, errno 2
> vfork failed.: No such file or directory
> 
> I think maybe the wrong parameters were sent while calling CreateProcessW.
> 
> --
> 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
> 

--
VH

--
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: UTF-8 in ftp client.

[Václav Haisman]

On Tue, 06 Apr 2010 15:58:18 +0300, Oleksandr Gavenko <> wrote:
> On 2010.04.06 12:50, Oleksandr Gavenko wrote:
>> I use filezilla to host file server. As explain article:
>>
>> http://wiki.filezilla-project.org/Character_Set
>>
>> for multilang environment need use UTF-8.
>>
>> How can I force Cygwin ftp client use UTF-8?
>>
>> ftp> ls
>> 200 Port command successful
>> 150 Opening data channel for directory list.
>> drwxr-xr-x 1 ftp ftp 0 Oct 16 2009 music
>> drwxr-xr-x 1 ftp ftp 0 Sep 11 2009 pub
>> drwxr-xr-x 1 ftp ftp 0 Apr 06 09:28 VERSUS. Хруст без
>> правил
>> -r--r--r-- 1 ftp ftp 9994240 Apr 05 13:15 Хрень.
>> Сенсанционный документальный фильм.mp4
>>
>>
> I read http://www.ietf.org/rfc/rfc2640.txt
> Standard say that server can report UTF-8 support by FEAT command but
> Cygwin ftp client dont understand it:
> 
> ftp> rhelp feat
> 214 Command FEAT is supported by FileZilla Server
> ftp> feat
> ?Invalid command
> ftp> help feat
> ?Invalid help command feat
> 
> rfc2640 dated by 1999, so long time left.
There is no such thing (AFAIK) as "Cygwin ftp client." You are most likely
running the Windows FTP client from WINDOWS/SYSTEM32 directory. Install
lftp or other FTP client using setup.exe.

--
VH


--
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

Time for new Binutils release?

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
could the responsible packager release recent/latest Binutils into the wild,
please? I am having problems using log4cplus library on Cygwin with stock
Cygwin ld. It has something to do with the pseudo relocations and such, IIRC.
Do Cygwin package maintainers not have the same issues with their packages?

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEAREIAAYFAkuQCKQACgkQr2CghdezFMmQpwCgrXhyb5HWvfKnfRBIX6sIBgGj
b7EAn39Lp2rgRtTgYWURu8ILRV1/0dov
=uUQM
-END PGP SIGNATURE-

--
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: Where is std::copy_n?

[Václav Haisman]

Roman Werpachowski wrote, On 17.1.2010 15:22:
> Hi,
> 
> The cygwin C++ library does not seem to implement std::copy_n
> (http://www.sgi.com/tech/stl/copy_n.html) Why?
"This function is an SGI extension; it is not part of the C++ standard."

You should not expect it to exist if you want portable code.

--
VH

--
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: home page problem

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

On 14.12.2009 13:39, msa...@itu.edu.tr wrote:
> I cannot get acces to cygwin home page from home. It says that "Access
> is forbiden".
> What should l do?
Wait.

It is a scheduled outage: .

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEYEAREIAAYFAksmQZYACgkQjksRtmO2spd3vQCeIEdcD7NFXK4Q37RS+ZHqXTdl
RkcAnRFoad4DVrs8xCgTAOGWgKG1M9Zv
=gu+s
-END PGP SIGNATURE-

--
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 1.7 still uses Boost 1.33 packages

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Joel Eidsath wrote, On 21.9.2009 21:35:
> Boost has had a good number of libraries added between 1.33 and 1.40. Is
> there any chance we will get a version upgrade?
> 
The Cygwin Boost package is currently unmaintained. Feel free to grab it,
prepare a package, either based on the old build script or on Cygports, and
submit it.

- --
VH

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEAREIAAYFAkq4ZKgACgkQr2CghdezFMmMvwCg1X9gNH2kYosBEKK37kebUsfl
xk0Amwf5+su5XtxnKpJ/q+p266j7rZqa
=XiMs
-END PGP SIGNATURE-

--
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: Prefix like cyg and lib of DLLs ?

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Torsten Giebl wrote, On 1.8.2009 23:09:
> Hello !
> 
> 
> Where does the prefix of DLLs for example
> cyg* and lib* come from ? Is it something that
> is internal fixed or can i change that ?
> 
> That a library has the cyg prefix for example
> cygpng is okay to me, as it shows it was compiled for
> the special usage with CYGWIN, but i would like to get
> rid of the lib prefix when compiling with -mno-cygwin.
Learn not to use this switch. Use Mingw instead. It is going away with 1.7.

> 
> When creating DLLs by hand with gcc -shared -o  i can name the
> DLL as i want, but what is for example with libpng, where is defined
> that the DLL it creates, is called libpng... ?
See .

> 
> DLLs created with Visual C++, usually don't come with the lib prefix
> and i am trying to go with the same name.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEAREIAAYFAkp1ShsACgkQr2CghdezFMnDFgCffh1qzl0fISDrLC6NoRBkEfOi
T4UAoNnAZUYKo27Xr8ZSYesf3e7wPFwf
=HLs9
-END PGP SIGNATURE-

--
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: Creation of a shared module (gcc -shared) , undefined references

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Martine Carannante wrote, On 30.7.2009 15:43:
> Hi
> 
> I try to port on CYGWIN an open source which runs correctly  on Linux.
> In this open source, a shared module (linked with option -shared) is
> created and after it's loaded by the main program with lt_dlopen()
> function.
> 
> On CYGWIN, I have a problem when I create the module (gcc option
> -shared). I have always some undefined references to functions which
> belongs to the main program. On Linux it's not a problem, there are no
> errors.
> I try to add the option -Wl,-allow-shlib-undefined. I have always the
> problem.
> 
> I don't know what to do. Are there other options to add to the gcc
> command ?I tried several..or do I have to modify the source code of the
> module?
> I'm not very familiar with shared modules.
Basically, you will have to fix the source of the application so that it does
not try to provide symbols for the modules from the main executable. Windows
DLLs cannot have undefined symbols like Linux in its shared objects.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iEYEAREIAAYFAkpx28gACgkQr2CghdezFMl+SwCdFFXvm9DAXyuma25eCMP4Os3I
5dkAn0RMNF1ydVNIxGP2XOlxDKCSNPTP
=u5pm
-END PGP SIGNATURE-

--
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: Commoncpp make error

[Václav Haisman]

faiz2009 wrote, On 5.7.2009 17:26:
> Hello, 
> 
> I try to install commoncpp2-1.7.0 under cygwin, then I proceed as follows:
> 
> 1) . / configure (takes place without any problem).
> 2) make. but during the compilation I receives the following error:
> 
> timer.cpp:131: error:'::clock_nanosleep' has not been declared
> make[2]: ***[timer.lo] Error 1
> make[2]: Leaving directory '/usr/local/commoncpp2-1.7.0/src'
> make[1]: ***[All-recursive] Error 1
> make[1]: Leaving directory '/usr/local/commoncpp2-1.7.0'
> make: *** [all] Error 2
> 
> 
>   So I have two questions:
> 1. To what is exactly of use commoncpp2 
Ask the library vendor.

> 2. How to solve this problem 
Ask the library vendor.

> 
> I' am waiting for a response
> 
> Thanks for you all

--
VH

--
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: To boost maintainer

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eray Ozkural wrote, On 1.7.2009 21:50:
>[diatribe removed]
In your previous Boost thread, subject "More info on boost and gcc-4", you
have missed one fine point. You have to build the whole Boost with
- --enable-auto-import, not just your own executables. IIRC adding
-Wl,--enable-auto-import was enough. It does work for me, at least
for Boost.Filesystem library.

- --
VH

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkpL47IACgkQhQBMvHf/WHmwRgDcCxAip+F8WPz/YkDIXJP1Q56n
awy1W16EOCgMjADffw66IzI/aEC0lph41Y+Yf1y5sz3QNGEV7soWTg==
=wFOG
-END PGP SIGNATURE-

--
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: More info on boost and gcc-4

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Eray Ozkural wrote, On 25.6.2009 0:08:
> Hi there,
> 
> Thanks for all the replies.
> 
> I'm not subscribed to the list (not yet) so please CC your replies to
> me. I am going to try to give as much information as I can.
> 
> Here is what's happening. If I use a *vanilla* gcc 4.x that I
> compiled, everything just works fine with boost.
> 
> Here is the version that I'm using successfully at the present. It's
> been some time since I compiled this one:
> $ g++ --version
> g++ (GCC) 4.3.1
> Copyright (C) 2008 Free Software Foundation, Inc.
> This is free software; see the source for copying conditions.  There is NO
> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
> 
> Otherwise, unfortunately, everything collapses, and it is highly
> unlikely that the fault lies with the boost library as the package
> maintainer suggested. Boost is a portable library that's being tested
> on many platforms regularly and I have never seen a major crash like
> this on any other system (linux and mac tested myself).
> 
> It is not just my idea that boost is essential. What do you believe
> the next C++ standard library be?
> 
> How did I build boost? Well, I followed the standard build procedure
> of course. In my first attempts, having been frustrated by my apparent
> inability to make a shared library, I had built a static library. I
> used the following procedure for boost-1.38:
> 
> Uninstall all boost include files /usr/include/boost* and libraries 
> /usr/local/l
> ib/*boost* as well.
> tar -xzf boost-1_38.tar.gz
> cd boost-1_38_0
> ./configure --with-libraries=filesystem,graph,program_options,regex,system
> 
> In the file "Makefile", change the line
> #BJAM_CONFIG= -sICU_PATH=/usr
> to
> #BJAM_CONFIG=-d2 release link=static runtime-link=static 
> cxxflags=-DBOOST_POSIX_
> API=1 optimization=speed
> (Boost apparently does not work with vanilla autotools on cygwin except when
> libraries are static).
> 
> make
> make install
> cd /usr/local/include
> ln -s boost-1_38/boost boost
> 
> Just to make sure we're on the same page, and I'm doing nothing funny.
> The boost-1.39 build proceeds similarly. However, as the package
> maintainer might have noticed, the build procedure changed
> considerably so there is no more a configure or Makefile. You give the
> --with-libraries option to bootstrap.sh and you can also give a
> --disable-icu IIRC. (You can't use ICU with static linking so it must
> be disabled) Then, you must change the gcc configuration so that the
> cygwin gcc-4 is used instead of gcc. (user-config.jam). Jam is a
> terrible tool but unfortunately with the current boost we have to
> stick to it. I don't think it honors environment variables like CXX
> and has some of the worst documentation (and design) I ever saw in a
> system tool :(
> 
> I made the following change in ./tools/build/v2/user-config.jam
> # Configure specific gcc version, giving alternative name to use.
> using gcc : 4.3 : g++-4 ;
> 
> Afterwards you give the bjam options directly like this:
> $ bjam -d2 release link=static runtime-link=static
> cxxflags=-DBOOST_POSIX_API=1 optimization=speed install
> 
> And it blows up. You can see that by running the test suites of
> program_options or regex libs as I suggested or write your little
> program_options test program if you feel like it.
> 
> What I noticed was that, although I didn't build any shared libs, the
> auto-import messages were still being displayed when I used the cygwin
> gcc-4 (when linking against boost for my project). But when I switched
> to the vanilla gcc 4.x that I had built myself, I saw no such messages
> naturally, and everything worked as it should.
> 
> That's why I thought this freeze might be related to the auto-import
> feature (even though I'm using only static libraries) As I said, if
> you give the --enable-auto-import option it only causes a more
> dramatic crash, please read my previous post in which I had requested
> help with boost-1.39 on cygwin-1.7, to which absolutely no replies
> came:
> http://cygwin.com/ml/cygwin/2009-06/msg00799.html
> 
>  The same problems occur exactly on cygwin-1.5. I was at first
> suspicious that I might be doing something wrong, but having seen that
> the vanilla gcc works, it is likely that the patches are causing the
> problem so I thought I should bring this to your attention since the
> importance of boost is only going to increase.
> 
> I did notice that the auto-import feature makes some assumptions about
> the code. Those assumptions may be contradicted by the boost code, but
> of course you cannot expect any library to conform to a cygwin
> standard rather than the ISO standard.
> 
> At any rate, it seems rather strange that linking static libraries fails.
> 
> May I humbly suggest to the package maintainer that he tries the
> myriad test suite programs included in boost-1.39 library against
> gcc-4?
> 
> And then against a vanilla gcc-4?
> 
> I'm sor

Re: GCC --enable-auto-import problem

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Huang Bambo wrote, On 5.6.2009 3:02:
> In cygwin 1.7:
> 
> 1. download db-4.7.25 from oracle at
> http://www.oracle.com/database/berkeley-db/index.html (havn't tested
> on other version)
> 2. configure like : ../dist/configure --prefix=/home/Bambo/db-for-1.7
> --enable-cxx --enable-pthread_api
> 3. make, it will take you a few minutes
> 4. write a program like :
> #include 
> 
> int main( void )
> {
>Db db( NULL, 0 );
>return 0;
> }
> 
> 5.compile like :g++ -o t test.cpp -L/home/Bambo/db-for-1.7/lib
> -ldb_cxx -I/home/Bambo/db-for-1.7/include
> will compile and link ok with information:
> Info: resolving typeinfo for std::exception by linking to
> __imp___ZTISt9exception (auto-import)
> /usr/lib/gcc/i686-pc-cygwin/4.3.2/../../../../i686-pc-cygwin/bin/ld:
> warning: auto-importing has been activated without
> --enable-auto-import specified on the command line.
> This should work unless it involves constant data structures
> referencing symbols from auto-imported DLLs.
> 
> and the file t.exe can't run, direct run in windows command shell will
> report "can't load" with error code 0x0005.
> ( use:"ldd t.exe" to find dlls used by the file will hung ldd)
> 
> 6.compile like:g++ -o t test.cpp -L/home/Bambo/db-for-1.7/lib -ldb_cxx
> -I/home/Bambo/db-for-1.7/include -Wl,--enable-auto-import
> Then everything goes fine.
> ldd t.exe will report:
> 
> $ ldd t.exe
>ntdll.dll => /cygdrive/c/WINDOWS/system32/ntdll.dll (0x7c92)
>kernel32.dll => /cygdrive/c/WINDOWS/system32/kernel32.dll (0x7c80)
>cygwin1.dll => /usr/bin/cygwin1.dll (0x6100)
>ADVAPI32.DLL => /cygdrive/c/WINDOWS/system32/ADVAPI32.DLL (0x77da)
>RPCRT4.dll => /cygdrive/c/WINDOWS/system32/RPCRT4.dll (0x77e5)
>Secur32.dll => /cygdrive/c/WINDOWS/system32/Secur32.dll (0x77fc)
>cyggcc_s-1.dll => /usr/bin/cyggcc_s-1.dll (0x67f0)
>cygstdc++-6.dll => /usr/bin/cygstdc++-6.dll (0x6c48)
> 
> 
> Who can tell me why??? Everything goes fine under cygwin 1.5 with
> gcc3(gcc4 not tested), even
> without "-Wl,--enable-auto-import"
This is a known problem. The explanation is rather technical and long, IIRC.
Just use -Wl,--enable-auto-import for all GCC 4.3 compiled code and you are 
fine.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkopTLkACgkQhQBMvHf/WHn+QADfZdJ2NcGAByHR0/ci1VPbHV4T
4hk3rxUlHl6ObADg2K6ViJnTxXfC+n5PhGR24BB9SkN4sJgv47fmjg==
=1zce
-END PGP SIGNATURE-

--
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: Pyhton script to call another program

[Václav Haisman]

mcbenus wrote, On 6.5.2009 17:01:
> Hi,
> 
> I am trying to write a simple python script to manipulate files and call
> other programs.  I have a program installed (rocs) which I run using cygwin
> (but is not in python).  How can I run a python script and then call the
> other program? 
> 
> For example:
> Python Code  # this line opens a file
> Python Code  # this line splits the file into 4 different files
> rocs  # this line calls the program 'rocs' to run on the newly formed files
> Python Code # this line renames rocs output files and saves them in the
> right place. 
> 
> I am relatively new to python and don't know a lot about cygwin.  Please
> remember that if you try to answer me :) Thanks!
This is not really something you should ask here. Try some Python related
mailing list/news group/IRC channel.

--
VH


--
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: problem with pthread.h

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dana wrote, On 25.3.2009 20:58:
> I have been trying to compile a program that needs to use the pthread
> library under cygwin. I have installed the newest versions of all of the
> tools. The file pthread.h is there in /usr/include, but the types used
> in it, like pthread_attr_t for example, are normally defined in
> sys/types.h. Except that for cygwin, they are not there. Trying to
> compile it with an older version of the file types.h that had these
> types defined resulted in incompatibilities for other types, like
> time_t, for example.
The types are there. Your installation is broken somehow.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAknKhdYACgkQhQBMvHf/WHk8BwDggFemvxOg9P8b4jILT5xFnIqf
7ilC+qJY3AZwZQDfSrpmB7fEiVaYwAeS9OOeozXPEs62JOHMDGsuIw==
=26FK
-END PGP SIGNATURE-

--
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: Porting to GCC 4.3.2

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave Korn wrote, On 16.3.2009 20:52:
> Václav Haisman wrote:
> 
>>> I am using Windows XP and Cygwin 1.5.
>> I have added -Wl,--enable-auto-import to the compiler command line and it has
>> fixed the resulting executable for me.
> 
>   You should have received a warning message during compilation telling you
> that you might need to do that.  Did it turn up in your earlier builds before
> you added the flag?
Yes, the warning is there. I did not notice it in the oodles of other
auto-import info messages.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkm+whYACgkQhQBMvHf/WHkE5gDggc2YysuHFVEEeeqmOV2oOX5U
JJtkRFsuI021WgDgjI9FiO8ei2DmyTyYIMRg2JjbEPqYUmppaJB8ZQ==
=M6qU
-END PGP SIGNATURE-

--
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: Porting to GCC 4.3.2

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Václav Haisman wrote, On 15.3.2009 12:19:
> Hi,
> I am trying to use GCC 4.3.2 to compile log4cplus 1.0.3 source. Compilation
> works but test cases that are using the resulting DLL do not work. The $?
> shell variable ends up with value 5. I used depends.exe on the test case
> executable and it finds all dependencies except DWMAPI.DLL. After some
> digging
> (<http://social.msdn.microsoft.com/Forums/en-US/vclanguage/thread/bc7a7414-6564-40bb-b8d2-af86345f2bc2/>
> and
> <http://stackoverflow.com/questions/173433/how-to-fix-dwmapidll-delay-load-dependency-under-winxp>)
> my question is: Does the GCC 4.3.2 change how delay loaded DLLs are handled
> or is this problem unrelated to mine?
The problem is apparently not this.

> 
> I am using Windows XP and Cygwin 1.5.

I have added -Wl,--enable-auto-import to the compiler command line and it has
fixed the resulting executable for me.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkm+qQQACgkQhQBMvHf/WHmY+QDdHxljq4x6A8jcYG1l/d4sJqUl
gTXCj7NJW6Z+RADfRGhd9Yau71GpDdacmlAV/tzhwfXSUoN7ppje1A==
=0sYD
-END PGP SIGNATURE-

--
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: Porting to GCC 4.3.2

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Dave Korn wrote, On 15.3.2009 15:40:
>[...]
> 
>   Not as far as I know.  Perhaps what you need is to add "-shared-libgcc" to
> the command line, as in Marco's earlier post?
I tried before I posted, it didn't help anything.

> 
> http://cygwin.com/ml/cygwin/2009-03/msg00494.html

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkm9HEoACgkQhQBMvHf/WHmozQDg2BTnJFS4Hnh4xMUWFQBAdntq
ZYvJ7r8raDCPiADg0qbtle4brD4wP92LRkRWQOKjj8y+q/D0ibt9AA==
=dm3N
-END PGP SIGNATURE-

--
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/

Porting to GCC 4.3.2

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
I am trying to use GCC 4.3.2 to compile log4cplus 1.0.3 source. Compilation
works but test cases that are using the resulting DLL do not work. The $?
shell variable ends up with value 5. I used depends.exe on the test case
executable and it finds all dependencies except DWMAPI.DLL. After some
digging
(
and
)
my question is: Does the GCC 4.3.2 change how delay loaded DLLs are handled
or is this problem unrelated to mine?

I am using Windows XP and Cygwin 1.5.

- --
VH


-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkm85C8ACgkQhQBMvHf/WHlkHADfSV0QCgxinVSmTginE+46vowr
5bCiYTTGRYz0PQDfWstVyJhBL2Sqp1t4oY/7c3zBtABkU8WmZwaxvA==
=AtOO
-END PGP SIGNATURE-

--
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: problem under cygwin with sh, bash, ksh

[Václav Haisman]

Hubert Samm wrote, On 6.3.2009 14:26:
> Hi All...  I've searched and found nothing  this script runs just fine on 
> AIX, Solaris, and Linux, but under cygwin, the array VALUE prints only 
> blanks.. has anyone else run into this... I've tried a bunch of different 
> things around typecast, etc, but it looks like VALUE is local in the table_it 
> function...  any thoughts???
>[...]
Have you tried debugging it using the -x switch to see what is going on?
Simple test case of setting VALUE[0]=$1 and then echoing "${VALUE[0]}" does
print what I give it, using bash.

--
VH

--
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: [boost and xerces] ping maintainers

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

b...@nc.rr.com wrote:
> First, thank-you for supporting these packages in Cygwin.  It's
> appreciated very much, at least by me.
> 
> From the mailing list archives, it appears the last boost package
> (v1.33.1) was rolled in 01/08, and the last xerces package (v2.8.0)
> in 05/08.  Any possibility of updating them to the current releases
> (i.e., boost v1.38.0 and xerces v3.0.1)?
I have given up on Boost package on Cygwin. Boost build AFAIK does not
follow the naming conventions Cygwin has for DLLs (or did not the last
time I checked) and I do not have the willpower to hack it into submission.

If you feel like taking over the Cygwin Boost package, try Boost Cygport
as starting point for a new Cygwin package.

- --
wilx

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkmvjLEACgkQhQBMvHf/WHmuHwDgtuVC72i2G84dWi5IY1VNSm5Y
yU7WWlWsedJ84gDgiirGMko6ywsljH7JpkK3mgIRG0teBg7cVMeazw==
=WUAC
-END PGP SIGNATURE-

--
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: FW: GLUI and GLUIX

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Jamie Sandell wrote, On 9.2.2009 23:17:
> Hi Andre, I have a problem. I'm trying to use GLUI with GLUIX. I can use
> GLUI fine on it's own and have been doing for some time.
> 
> If I have this:
> 
> #include "glui.h" #include "gluix.h"
> 
> Then I get the errors: Error25error LNK2019: unresolved external
> symbol "public: int __thiscall GLUIX_FileSelectionDialog::set_text(enum
> GLUIX_FSD_Part,char *)"
> (?set_t...@gluix_fileselectiondialog@@QAEHW4GLUIX_FSD_Part@@p...@z)
> referenced in function "void __cdecl setupGLUI(void)" (?setupGLUI@@YAXXZ)
> GLUI_Window_Template.objPrototype_01 Error26error LNK2019:
> unresolved external symbol "public: __thiscall
> GLUIX_FileSelectionDialog::GLUIX_FileSelectionDialog(char *,void
> (__cdecl*)(char *,char *,char *),int,int,int,int,int,int,int)"
> (??0GLUIX_FileSelectionDialog@@q...@padp6ax000@z...@z) referenced in
> function "void __cdecl setupGLUI(void)" (?setupGLUI@@YAXXZ)
> GLUI_Window_Template.objPrototype_01 Error27fatal error
> LNK1120: 2 unresolved externals
> C:\work\3rd_year\08341\Prototype_12\Debug\Prototype_01.exePrototype_01
> 
> 
> But I have them in this order I get these errors: Error1error
> C2061: syntax error : identifier 'Byte'
> c:\work\3rd_year\08341\prototype_12\prototype_01\gluix.h89
> Prototype_01 Error2error C2061: syntax error : identifier 'GLUI'
> c:\work\3rd_year\08341\prototype_12\prototype_01\gluix.h123
> Prototype_01
> 
> I'm not sure how to fix it? Thanks for your time.
You are obviously using MSVC to compile your code. You cannot use MSVC with
Cygwin libraries. So, to fix it, first step would be to stop using MSVC and
start using Cygwin GCC.

- --
VH

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkmQrlwACgkQhQBMvHf/WHkhowDeKk8Wv8AFQtQ6Td1MW8MaYIwL
MGnBr13NDAkrMwDfctesa0NDDA7rlTAGSspxkNhHVhqg2s/iSNF9Gw==
=YulC
-END PGP SIGNATURE-

--
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: ZSH completion problem

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Peter A. Castro wrote, On 9.12.2008 20:39:
> On Tue, 9 Dec 2008, V�clav Haisman wrote:
> 
> Hi,
> 
>> Greetings, Výclav,
> 
> I have just updated ZSH and now when completing paths it prints the
> following:
> _alternative:69: command not found: _path_commands
> 
>> That's a different symptom than what other people has reported.
>> But, it could just be from a stale dump file.
> 
>> If you haven't already done so, please remove your .zcompdump (or
>> whatever custom dump file you might be using) and re-generate it.
> 
>> The best way to do this cleanly is to comment out running 'compinit' from
>> your .zsh* files, exit and start a fresh zsh, then run compinit (answer
>> yes if it complains about insecure dirs).  Check that .zcompdump is more
>> than 256 bytes (should be about 33k).  If it's too small, run
>>   compinit -d .zcompdump
>> Check .zcompdump again.  If it's still too small, try exiting and
>> re-starting the shell again and run compinit -d again.
> 
>> Then you can uncommment running compinit from your .zsh* files
>> (you might need to add the '-i' option) and things should be good.
> 
>> One caveat is that DOS style paths (eg: "C:/") do not seem to tab
>> complete right now.  It's a know problem that I'm trying to track down.
>> Let me know if there are other issues.
Hi,
thanks, it was the stale .zcompdump file.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkk+y6MACgkQhQBMvHf/WHliwgDeMB/7Yko4g4ClhFzO6zcHEsXe
5vx6udH8ED6EtwDdGkbBjb70i/wvJpX/gYyv1IcdWFdaEXlZEkJnbQ==
=aZXA
-END PGP SIGNATURE-

--
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/

ZSH completion problem

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hi,
I have just updated ZSH and now when completing paths it prints the following:

_alternative:69: command not found: _path_commands

Cygcheck thinks the package is complete:

amber2::wilx:~> zsh --version
zsh --version
zsh 4.3.9 (i686-pc-cygwin)

amber2::wilx:~> cygcheck -c zsh
cygcheck -c zsh
Cygwin Package Information
Package  VersionStatus
zsh  4.3.9-1OK

The cygcheck -s output is attached.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkk+trgACgkQhQBMvHf/WHm+EADeJFXQWUwK76gpoB+ypBhB/gqL
1sdnQyycH8yawADg2dKQBQt7+gbLWcQLiBJ2cSPrYtTUQ/+vnAernQ==
=mGvN
-END PGP SIGNATURE-

Cygwin Configuration Diagnostics
Current System Time: Tue Dec 09 19:15:26 2008

Windows XP Professional Ver 5.1 Build 2600 Service Pack 3

Path:   C:\cygwin\usr\local\bin
C:\cygwin\bin
C:\cygwin\bin
C:\cygwin\usr\X11R6\bin
c:\GNAT\2008\bin
c:\WINDOWS\system32
c:\WINDOWS
c:\WINDOWS\System32\Wbem
c:\Perl\site\bin
c:\Perl\bin
c:\Program Files\ATI Technologies\ATI.ACE\Core-Static
c:\Program Files\Intel\DMIX
c:\Program Files\Common Files\bin
c:\Program Files\Common Files\GTK\2.0\bin
c:\Program Files\QuickTime\QTSystem\
c:\Program Files\GNU\GnuPG
c:\Program Files\Common Files\bin

Output from C:\cygwin\bin\id.exe (nontsec)
UID: 1003(wilx)   GID: 513(None)
513(None) 547(Power Users)  555(Remote Desktop Users)
545(Users)

Output from C:\cygwin\bin\id.exe (ntsec)
UID: 1003(wilx)   GID: 513(None)
513(None) 547(Power Users)  555(Remote Desktop Users)
545(Users)

SysDir: C:\WINDOWS\system32
WinDir: C:\WINDOWS

CYGWIN = 'server'
HOME = '/home/wilx'
PWD = '/home/wilx'
USER = 'wilx'
MAKE_MODE = 'unix'

Use '-r' to scan registry

c:  hd  NTFS23Mb  96% CP CS UN PA FC Charlie
d:  hd  NTFS142616Mb  99% CP CS UN PA FC StareD_160
e:  hd  NTFS  9358Mb  42% CP CS UN PA FC Echo
i:  cd N/AN/A
j:  cd N/AN/A
k:  cd N/AN/A
l:  cd N/AN/A
m:  cd N/AN/A
q:  hd  NTFS 10001Mb  77% CP CS UN PA FC StareC_160

C:\cygwin  /   system  binmode
D:\wilx/home/wilx  system  binmode
C:\cygwin/bin  /usr/binsystem  binmode
C:\cygwin/lib  /usr/libsystem  binmode
.  /cygdrive   system  binmode,cygdrive

Found: C:\cygwin\bin\awk.exe
Found: C:\cygwin\bin\bash.exe
Found: C:\cygwin\bin\cat.exe
Found: C:\cygwin\bin\cp.exe
Found: C:\cygwin\bin\cpp.exe
Not Found: crontab
Found: C:\cygwin\bin\find.exe
Found: C:\cygwin\bin\gcc.exe
Found: C:\cygwin\bin\gdb.exe
Found: C:\cygwin\bin\grep.exe
Found: C:\cygwin\bin\kill.exe
Found: C:\cygwin\bin\ld.exe
Found: C:\cygwin\bin\ls.exe
Found: C:\cygwin\bin\make.exe
Found: C:\cygwin\bin\mv.exe
Found: C:\cygwin\bin\patch.exe
Found: C:\cygwin\bin\perl.exe
Found: c:\Perl\bin\perl.exe
Found: C:\cygwin\bin\rm.exe
Found: C:\cygwin\bin\sed.exe
Found: C:\cygwin\bin\ssh.exe
Found: C:\cygwin\bin\sh.exe
Found: C:\cygwin\bin\tar.exe
Found: C:\cygwin\bin\test.exe
Not Found: vi
Found: C:\cygwin\bin\vim.exe

   20k 2007/07/29 C:\cygwin\bin\cygao-2.dll
  107k 2008/09/01 C:\cygwin\bin\cygapr-1-0.dll
   89k 2008/09/01 C:\cygwin\bin\cygaprutil-1-0.dll
  704k 2007/12/18 C:\cygwin\bin\cygaspell-15.dll
  135k 2007/02/11 C:\cygwin\bin\cygaudiofile-0.dll
  180k 2008/03/31 C:\cygwin\bin\cygautotrace-3.dll
  351k 2008/01/14 C:\cygwin\bin\cygboost_date_time-gcc-mt-1_33_1.dll
  120k 2008/01/14 C:\cygwin\bin\cygboost_filesystem-gcc-mt-1_33_1.dll
   79k 2008/01/14 C:\cygwin\bin\cygboost_iostreams-gcc-mt-1_33_1.dll
  526k 2008/01/14 C:\cygwin\bin\cygboost_program_options-gcc-mt-1_33_1.dll
  564k 2008/01/14 C:\cygwin\bin\cygboost_python-gcc-mt-1_33_1.dll
  678k 2008/01/14 C:\cygwin\bin\cygboost_regex-gcc-mt-1_33_1.dll
  621k 2008/01/14 C:\cygwin\bin\cygboost_serialization-gcc-mt-1_33_1.dll
  118k 2008/01/14 C:\cygwin\bin\cygboost_signals-gcc-mt-1_33_1.dll
   91k 2008/01/14 C:\cygwin\bin\cygboost_thread-gcc-mt-1_33_1.dll
   61k 2008/04/01 C:\cygwin\bin\cygbz2-1.dll
  386k 2008/08/27 C:\cygwin\bin\cygcairo-2.dll
7k 2008/11/10 C:\cygwin\bin\cygcharset-1.dll
  560k 2008/07/07 C:\cygwin\bin\cygclamav-4.dll
  644k 2008/11/27 C:\cygwin\bin\cygclamav-5.dll
   42k 2008/07/07 C:\cygwin\bin\cygclamunrar-4.dll
   42k 2008/11/27 C:\cygwin\bin\cygclamunrar-5.dll
8k 2008/07/07 C:\cygwin\bin\cygclamunrar_iface-4.dll
8k 2008/11/27 C:\cygwin\bin\cygclamunrar_iface-5.dll
7k 2003/10/19 C:\cygwin\bin\cygcrypt-0.dll
 1064k 2008/09/30 C:\cygwin\bin\cygcrypto-0.9.8.dll
  194k 2007/06/30 C:\cygwin\bin\cygcurl-3.dll
  221k 2007/06/30 C:\cygwin\bin\cygcurl-4.dll
  703k 2007/12/17 C:\cygwin\bin\cygdb-4.2.dll
  943k 2007/1

Re: Solution or workaround for "file name too long" problem ?

[Václav Haisman]

Klaus Tiedemann wrote:
> Hello cygwin,
> 
> is there any progress on the "file name too long" problem ?
> I think a lot of people would like to use rsync under cygwin for backup
> or replication, but as long as cygwin can't handle long path names this
> is not a serious option ...
> 
> Is there at least a workaround you can recommend ?
Shorter paths.

> 
> Best regards
> Klaus
Try 1.7 snapshot if it fixes your problem.

--
VH


--
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: cygwin g++ strictness

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John Emmas wrote:
> - Original Message - From: "Václav Haisman"
> Sent: 31 October 2008 11:54
> Subject: Re: cygwin g++ strictness
>>
>> Try getting preprocessed source to see where int32_t get defined to
>> anything else than typedef of int.
>>
> I quite like this idea because I can see that this situation is going to
> cause me lots of problems - in fact, it's ALREADY causing me lots of
> problems... :-)
> 
> Can you expand on that suggestion please?  Where is the preprocessed
> source available?  If you mean searching through Cygwin's normal header
> files it would be very difficult to track this down (although I agree with
> you - int32_t must be getting defined differently, somewhere).
I mean the -save-temps switch of GCC.

> 
> John
>

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkLAIMACgkQhQBMvHf/WHl9nQDgrofeXENv0R1If6vi5Y2AxzPV
jklp779yZa34bQDfUOSynmoptQAotxHMm7AQxePJ8cZ+EbVwDgf0PQ==
=dkF6
-END PGP SIGNATURE-

--
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: cygwin g++ strictness

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John Emmas wrote:
> - Original Message - From: "Václav Haisman"
> Sent: 31 October 2008 11:14
> Subject: Re: cygwin g++ strictness
>>
>> Check what type is gint really is. I suspect the gint will be typedef
>> for long. Long and int are two different types even though they are both
>> 32bits wide on 32bit platforms.
> 
> Thanks Vaclav.  It must be something like that because I've noticed that if
> the function prototype is changed to look like this:-
> 
> int AddTwoInts (int& a, int& b);
> 
> this works.
> gint x = 4;
> gint y = 5;
> int z = AddTwoInts (x, y);
> 
> wheareas this doesn't.
> int32_t x = 4;
> int32_t y = 5;
> int z = AddTwoInts (x, y);
> 
> So, even though it looks like 'sys/types.h' is typedefing int32_t as an
> int,
> that section must either be getting conditionally (not) compiled or maybe
> int32_t is getting redefined somewhere else.
Try getting preprocessed source to see where int32_t get defined to
anything else than typedef of int.

> 
> Having said all that, most compilers provide implicit conversions between
> related types.  gcc4.4 seems to be doing that and I'm pretty sure that MSVC
> would allow it also (although I haven't tried it).
That has nothing to do with your problem. Reference to int and reference
to long are two totally unrelated types. The implicit conversions of
C/C++ only apply to values, not references.

> 
> Thanks also for the suggestion about changing to temporary variables but it
> won't help in this case because this isn't my own code and I'd probably
> need
> to change dozens of modules.  Explicit casting is probably the safest
> solution.
No, casting is not an option, really. You have references. What do you
intend to cast x and y to?

- --
VH

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkK8eIACgkQhQBMvHf/WHl+kgDfYntRu/+NS1A6Z5/2TYlV96K0
Tih8AggNNdhejADeMweLvprsehppWaNqAczAv/DJ5NWQwBYJicAUzA==
=MlgZ
-END PGP SIGNATURE-

--
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: cygwin g++ strictness

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John Emmas wrote:
> - Original Message - From: "John Emmas"
> Sent: 31 October 2008 08:21
> Subject: Re: cygwin g++ strictness
>>
>> adding the compiler flag -fpermissive seems to have solved the problem.
>>
> 
> 
> - Original Message - From: "Václav Haisman"
> Sent: 31 October 2008 10:07
> Subject: Re: cygwin g++ strictness
>>
>> It just works. You are doing something wrong. There is nothing wrong
>> with GCC 3.4 in this respect.
>>
> 
> It seems like I spoke to soon.  -fpermissive seems to have helped in
> some cases but not in every case.  I'll give an example. Please can someone
> tell me if I'm misunderstanding something here.  Consider the following
> function prototype (where 'gint' is typedef'd as an int in gtypes.h):-
> 
> #include 
> int AddTwoInts (gint& a, gint& b);
> 
> This code compiles under both Linux/gcc4.4 and also under Cygwin:-
> gint x = 4;
> gint y = 5;
> int z = AddTwoInts (x, y);
> 
> This code compiles under Linux/gcc4.4 but not under Cygwin:-
> #include// typedefs int32_t as int
> int32_t x = 4;
> int32_t y = 5;
> int z = AddTwoInts (x, y);
Check what type is gint really is. I suspect the gint will be typedef
for long. Long and int are two different types even though they are both
32bits wide on 32bit platforms. Either declare x, y as gint or use
temporaries for the AddTwoInts() call.

> 
> The last example produces this error on my system:-
> error: no matching function for call to `AddTwoInts(int32_t&, int32_t&)'
> note: candidates are: int AddTwoInts(gint&, gint&)
[...]

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkK6KAACgkQhQBMvHf/WHnLpwDeMNkb5Gf8KL5fkj1kGbYA94LM
cKMQbaW5jHxZXQDfRoB6wH03WYo8tliLcgpH2ceZ9gkGvy2YtbhbDg==
=KUkg
-END PGP SIGNATURE-

--
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: cygwin g++ strictness

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

John Emmas wrote:
> - Original Message - From: "Larry Hall (Cygwin)"
> Sent: 30 October 2008 22:23
> Subject: Re: cygwin g++ strictness
>>
>> This is gcc/g++ question, not a Cygwin one.  Please find an appropriate
>> forum to ask this question if you can't find it in the available
>> documentation.
>>
> 
> - Original Message - From: "Vaclav Haisman"
> Sent: 30 October 2008 22:10
> Subject: Re: cygwin g++ strictness
>>
>> I think the problem is between keyboard and chair. GCC, no matter how
>> ancient version, just does not do that.
>>
> Regardless of your ascerbic comments, adding the compiler flag -fpermissive
> seems to have solved the problem.   Cygwin's version of gcc seems to be 3.4
> on my system whereas my Linux box is running 4.4.  Maybe this is something
> that got relaxed between the two of them?  Whatever the explanation, the
> exact same code compiles fine under Linux/gcc4.4 without needing that flag.
> Maybe it wouldn't have done under Linux/gcc3.4?
> 
> John

Watch this:

([EMAIL PROTECTED])[1010] /cygdrive/c/wilx
$ cat pebkac.cxx
#include 

using namespace std;

typedef int gint;
typedef int int32;
void foo (gint x)
{
  cout << x;
}

int main ()
{
  int32 x = 2;
  foo (x);
}

([EMAIL PROTECTED])[1011] /cygdrive/c/wilx
$ g++ -Wall -Wextra -ansi -pedantic -o pebkac pebkac.cxx

([EMAIL PROTECTED])[1012] /cygdrive/c/wilx
$ g++ -v
Reading specs from /usr/lib/gcc/i686-pc-cygwin/3.4.4/specs
Configured with:
/usr/build/package/orig/test.respin/gcc-3.4.4-3/configure --verbose
- --prefix=/usr --exec-prefix=/usr --sysconfdir=/etc --libdir=/usr/lib
- --libexecdir=/usr/lib --mandir=/usr/share/man --infodir=/usr/share/info
- --enable-languages=c,ada,c++,d,f77,pascal,java,objc --enable-nls
- --without-included-gettext --enable-version-specific-runtime-libs
- --without-x --enable-libgcj --disable-java-awt --with-system-zlib
- --enable-interpreter --disable-libgcj-debug --enable-threads=posix
- --enable-java-gc=boehm --disable-win32-registry --enable-sjlj-exceptions
- --enable-hash-synchronization --enable-libstdcxx-debug
Thread model: posix
gcc version 3.4.4 (cygming special, gdc 0.12, using dmd 0.125)

It just works. You are doing something wrong. There is nothing wrong
with GCC 3.4 in this respect.


- --
wilx
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkkK2M8ACgkQhQBMvHf/WHktsQDfUCmfLwof8JgmiBUCjnAhxVlB
1UeClAO5B70OcADgx8k5fi00xozHySX/fSdcXwCwLmPRKNET3y7gDA==
=HrNG
-END PGP SIGNATURE-

--
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: crash if fork(2) from another thread

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Christopher Faylor wrote, On 28.9.2008 17:25:
> On Sun, Sep 28, 2008 at 09:32:39AM +0200, V??clav Haisman wrote:
>> -BEGIN PGP SIGNED MESSAGE-
>> Hash: SHA256
>>
>> Hirokazu Yamamoto wrote, On 28.9.2008 4:16:
>>> # I've post mail, but it didn't show up in
>>> http://www.nabble.com/Cygwin-f12165.html.
>>> # Maybe it was not good to attach a file. So try again...
>>>
>>> I'm not familiar with pthread & fork, but I think following code should not
>>> crash. Is this expected behavior?
>>>
>>> #include 
>>> #include 
>>> #include 
>>> #include 
>>>
>>> void *thread_func(void* args)
>>> {
>>> int ret;
>>> pid_t pid;
>>> pthread_t thread;
>>>
>>> puts("thread_func");
>>>
>>> pid = fork();
>>>
>>> assert(pid != (pid_t)-1);
>>>
>>> if (pid != 0) /* parent process */
>>> {
>>> int status;
>>>
>>> printf("parent process (child pid = %d)\n", pid);
>>>
>>> waitpid(pid, &status, 0);
>>>
>>> puts("parent process end");
>>> }
>>> else /* child process */
>>> {
>>> puts("child process"); /* crash here */
>> I think this is not allowed in here.  You can only do async-signal-safe
>> stuff in the child.  IO is AFAIK not in that category.  Basically, the
>> only thing you can safely do in the child process is to call exec().
> 
> I don't see any reason why this shouldn't be allowed.  You should
> be able to do anything you want in a child process.
I do not think that is true. As per
,
RATIONALE, the penultimate paragraph, it is basically undefined behaviour.


- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkjfp4oACgkQhQBMvHf/WHmFRwDgoqjd8DsvwSb8e+3BEbvYtVLK
mLXEYdMTkxauIADgsxmD6GxTDfHCyaTP41jpRkErFhTXsZ5bHcRjrg==
=hyOi
-END PGP SIGNATURE-

--
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: crash if fork(2) from another thread

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Hirokazu Yamamoto wrote, On 28.9.2008 4:16:
> # I've post mail, but it didn't show up in
> http://www.nabble.com/Cygwin-f12165.html.
> # Maybe it was not good to attach a file. So try again...
> 
> I'm not familiar with pthread & fork, but I think following code should not
> crash. Is this expected behavior?
> 
> #include 
> #include 
> #include 
> #include 
> 
> void *thread_func(void* args)
> {
> int ret;
> pid_t pid;
> pthread_t thread;
> 
> puts("thread_func");
> 
> pid = fork();
> 
> assert(pid != (pid_t)-1);
> 
> if (pid != 0) /* parent process */
> {
> int status;
> 
> printf("parent process (child pid = %d)\n", pid);
> 
> waitpid(pid, &status, 0);
> 
> puts("parent process end");
> }
> else /* child process */
> {
> puts("child process"); /* crash here */
I think this is not allowed in here. You can only do async-signal-safe stuff
in the child. IO is AFAIK not in that category. Basically, the only thing you
 can safely do in the child process is to call exec().

> }
> 
> return args;
> }
> 
> int main()
> {
> int ret;
> pthread_t thread;
> 
> ret = pthread_create(&thread, NULL, thread_func, NULL);
> assert(ret == 0);
> 
> ret = pthread_join(thread, NULL);
> assert(ret == 0);
> }
> 
> // built with "gcc main.c -o main.exe"
> 
> Thank you.

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)

iFYEAREIAAYFAkjfMxcACgkQhQBMvHf/WHkrOgDgjwH6nF9WnksWQtjZDKOutx2d
Sk/irkVq2NjjzADeJOjUN3LB+WkRPYGHGubEVHVT7H5DEh2NcZtPyg==
=/9e7
-END PGP SIGNATURE-

--
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 constantly accesses floppy drive

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Lee Maschmeyer wrote, On 11.7.2008 22:13:
|> So $PATH in bash references '/cygdrive/a'?
|
| No, $PATH references c:/windows:
|
| $ echo $PATH
|
~/bin:/usr/local/bin:/usr/bin:/bin:/usr/X11R6/bin:/c/WINDOWS/system32:/c/WINDOWS:/c/WINDOWS/System32/Wbem:/usr/bin:/usr/X11r6/bin:/e

|
| /Program Files/Executive Software/Diskeeper/:/usr/lib/lapack
|
| $ mount
| e:\cygwin\usr\X11R6\lib\X11\fonts on /usr/X11R6/lib/X11/fonts type ntfs
| (binmode,system)
| e:\classic literature on /data/Classic Literature type ntfs
| (binmode,cygexec,system)
| e:\New Literature on /data/New Literature type ntfs
| (binmode,cygexec,system)
| e:\Jiffy-Braille on /data/Jiffy-Braille type ntfs (binmode,cygexec,system)
| e:\braille books on /data/Braille Books type ntfs (binmode,cygexec,system)
| e:\cygwin\bin on /usr/bin type ntfs (binmode,system)
| e:\cygwin\lib on /usr/lib type ntfs (binmode,system)
| e:\cygwin on / type ntfs (binmode,system)
| a: on /a type unknown (binmode,cygexec,system)
I do not have such mounts. Try to unmount /a and see if it still happens.

| c: on /c type ntfs (binmode,cygexec,system)
| d: on /d type unknown (binmode,cygexec,system)
| e: on /e type ntfs (binmode,cygexec,system)
| h: on /h type unknown (binmode,cygexec,system)
| j: on /j type unknown (binmode,cygexec,system)
| y: on /y type ntfs (binmode,cygexec,system)
| z: on /cygdrive/z type ntfs (binmode,noumount,user)
|
|

- --
VH

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iFYEAREIAAYFAkh4SCYACgkQhQBMvHf/WHnvWgDdE4Hvy5BfP9f6+VUJJOuCniCu
hNTlTVSuiaFM4wDg2V8TEpmscCUnQAh8ZwPMrljq1cQT3AB5dSkjaQ==
=TQjU
-END PGP SIGNATURE-

--
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: cl.exe cannot understand gygwin path format

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

CN wrote:
| Hi,
|
| I am trying to compile a .c file using cl.exe in cygwin.
| I am getting following Error.
|
| $ cl -Fo/cygdrive/e/cnair/tmp/hai.o /cygdrive/e/cnair/tmp/hai.c
| Microsoft (R) 32-bit C/C++ Optimizing Compiler Version 13.00.9466 for
80x86
| Copyright (C) Microsoft Corporation 1984-2001. All rights reserved.
|
| cl : Command line warning D4002 : ignoring unknown option
| '/cygdrive/e/cnair/tmp
| /hai.c'
| cl : Command line error D2003 : missing source filename
|
|   If I  change the .c file path format to normal windows format then it is
| working fine.
|
| Is there any option/way to compile files using cl.exe with the same cygwin
| path format?
No, it is not. CL is native Windows executable and thus does not handle
Cygwin paths. At best you could use the cygpath utility to convert the
paths.

|
| Thanks and regarsd,
| CN
|
|

-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkhSU/0ACgkQjksRtmO2spdtZQCfdOSdQZjjbtPDX7A5YIyHD8mB
HtcAnR9DSOpWD9gE6N2YavLu0xktSCvL
=i++9
-END PGP SIGNATURE-

--
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: Why are cygwin files (exe. dlls etc. ) not version stamped on Windows?

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Václav Haisman wrote, On 17.5.2008 14:12:
| qa4ever  gmail  com wrote, On 14.5.2008 11:50:
^^
Sorry for that :(

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkguzFcACgkQoUFWwtEPkHJ/oACeObfpcLWjt4TYOqsKdTaw8VsN
RgAAoIFaKsKMkNGJropAtdMQoEV6j+0K
=PCO5
-END PGP SIGNATURE-

--
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: Why are cygwin files (exe. dlls etc. ) not version stamped on Windows?

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[EMAIL PROTECTED] wrote, On 14.5.2008 11:50:
| Why are cygwin files (exe. dlls etc. ) not version stamped on Windows?
Because that would involve adding Windows resources to the files which is not
something that source code targetted for *nix usually does. It would involve
patching the source which is what maintainers are usually trying to avoid if
possible.

There are also --{major,minor}-image-version flags for ld but I am not sure
these are the right thing for that (though I have used them to mark Boost
.dlls as 1.33).

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkguy8AACgkQoUFWwtEPkHJVnQCdHfBIFXaRKogtNF+DMB5NNAdF
42MAn3C3f+zDthDXJXKWHVIVvjb71RoH
=ohb3
-END PGP SIGNATURE-

--
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: SDL and OpenFST package

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

[EMAIL PROTECTED] wrote:
| Hi
|
| Just wondering if there is any available cygwin package for
|
| SDL, SDL_image, SDL_gfx and OpenFST.
|
| currently need them for my project, however can not find them in cygwin
| setup
|
| please let me know if anyone have such package that can be install in to
| cygwin
|
| Cheers,
| Leo
All Cygwin packages are listed on .

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgkLlgACgkQjksRtmO2spcVKwCgih97h/PlDaJsmsiwtqiTL/q+
iJwAn3zQLJxJn9fkyvBgGVVsB5y85OQR
=YH4r
-END PGP SIGNATURE-

--
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: cygtls::handle_exceptions: Error while dumping state

[Václav Haisman]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA256

Gloria Muñoz wrote:
| Hi all!
|
| First of all hello everybody! because I've just joined
| the list. I've had a lok into the Mailing list archive and I've seen
| that this error has happened before to other people but each time the
| solution was different and I haven't found the answer to my specific
| case so here we go!
|
|
| I'm just trying to read a .data file and create a .xls file to use
| with excel; for that I've created the next simple program:
|
| #include 
|
| main (int argc, char* argv[])
| {
| FILE *f1, *f2;
|
|
| char *file_name;
| int num_compressors = 0;
| int num_files = 0;
| int numC = 0;
| char *out_file;
| char *aux;
| char *ctime;
|
|  if(argc != 2)
| {
|   fprintf(stderr, "Use: %s nameOfFile\n", argv[0]);
|
|   exit(1);
| }
|
|  // Open source file
|  if ((f1 = fopen(argv[1],"r")) == NULL){
| fprintf(stderr, "Can't open %s\n", argv[1]);
| exit(1);
|   }
|
|   fprintf(stderr, "%s opened\n", argv[1]);
|
|
|   fscanf(f1,"%d",&num_compressors
| );
|   fprintf(stderr, "Number of compressors: %d\n", num_compressors);
|   fscanf(f1,"%d",&num_files);
|   fprintf(stderr, "Number of files: %d\n", num_files);
|
|
|   do{
|   // THE PROBLEM SEEMS TO BEGIN HERE
|fscanf(f1,"%s",out_file);
You have forgotten to allocate some memory for your out_file buffer.

|fprintf(stderr, "Name of compressor: %s\n", out_file);
|
|out_file = strcat(out_file, ".xls");
|fprintf(stderr, "Read name of the new file: %s\n", out_file);
|// Create new .xls file
|   f2 = fopen (out_file, "w");
|
|   if (f2==NULL){
|  fprintf(stderr, "Can't open %s\n", out_file);
|  exit(1);
|   }
|
| fscanf(f1,"%s",file_name);
| fprintf(f2, "%s\t", file_name);
|
| fscanf(f1,"%s %s", aux, ctime);
| fprintf(f2, "%s\t", ctime);
|numC++;
| }while (numC < num_compressors);
|
|   fclose(f1);
|   fclose(f2);
|
|
| }
|
|
| The test .data file is called pruExcel.data and consist of:
|
| 1
| 1
|
| gzip
|
| to_mm_24.bin
|
| real0m0.614s
| user0m0.499s
| sys0m0.015s
|
|
| And the output :
|
|
| $ ./oExcel pruExcel.data
| pruExcel.data opened
| Number of compressors: 1
| Number of files: 1
|   7 [main] oExcel 2988 _cygtls::handle_exceptions: Error while
dumping state
|  (probably corrupted stack)
| Segmentation fault (core dumped)
|
| I'm working with Windows XP and CYGWIN_NT-5.1,
|
| any idea would be appreciated!
| Thanks!
|

- --
VH
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.4.9 (MingW32)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iEYEAREIAAYFAkgkEggACgkQjksRtmO2spfl3QCfVOjGhbVuHPDpXJJd6FT2uWq7
aCQAn3CMeGWSoU+Pn56mx4qsAnZCx84z
=1ql3
-END PGP SIGNATURE-

--
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: Cygwin IRC channel?

[Václav Haisman]

Robert Eckhoff wrote, On 5.4.2008 8:38:

Hi,

   I was wondering, is there a cygwin IRC channel?  I've been looking
   around for one, and all I see is cygwin/X.  Just wondering.

   ~Robert

[EMAIL PROTECTED]

--
VH



signature.asc
Description: OpenPGP digital signature

CMake: CPack dumps core

[Václav Haisman]

Hi,
I am using CMake for one of my projects and I also want to use CPack but 
CPack dumps core for anything except cpack --help.


--
VH



signature.asc
Description: OpenPGP digital signature

Re: REPOST: TeXLive cygwin port?

[Václav Haisman]

Sivaram Neelakantan wrote, On 27.3.2008 6:25:

Hello,

Is there a chance of a LaTeX port to cygwin?  The current TeTeX port
is pretty old.

 sivaram
Grab the source of the package, update it to the latest and submit a 
new/updated package. It is your chance to become famous!


--
VH



signature.asc
Description: OpenPGP digital signature

Re: [ANNOUNCEMENT] New package: irssi-0.8.12-1

[Václav Haisman]

burning shadow wrote, On 16.2.2008 2:08:

I'm running it in PuTTY via SSH connection. TERM set to "cygwin". Yes,
If you are connected using Putty you should probably be using TERM=putty or 
TERM=xterm rather than TERM=cygwin.



first 2 or maybe 3 lines. All packages are up to date. And I have
never seen that with my own compiled irssi.

I have made screenshots of my own compiled irssi and irssi from
package windows right after startup:

http://home.shad.pp.ru/tmp/irssi-compiled-putty-window.png
http://home.shad.pp.ru/tmp/irssi-package-putty-window.png



--
wilx



signature.asc
Description: OpenPGP digital signature

Re: extern keyword and dlls

[Václav Haisman]

masta uy wrote, On 11.2.2008 0:40:

Hello,

I am in working on porting some code to cygwin but I am stuck. I need it to be 
compiled as a dll but gcc gives me a linking error.

This code triggers the error:

extern int num;

int foo() {
  extern int num;
  num = 5;
}

You are missing a definition of num. All you have now is just a declaration.




the error is:

hello.c:(.text+0x5): undefined reference to `_num'

And this is how I call gcc: "gcc -shared hello.c" 


Interestingly, the code above does work on my ubuntu installation (ubuntu 7.10 
gcc 4.1.3)

Any help is appreciated

Regards
Fernando


--
VH



signature.asc
Description: OpenPGP digital signature

Re: cygwin, g++ and boost? Do I need dll.a?

[Václav Haisman]

adam99 wrote:

I downloaded boost packages under cygwin (both boost and boost-devel). My
first problem is unit test framework was not installed through this
installation. I have tried to create it through bjam and created a library
file at 

[...]

If you have not noticed yet, I have updated the Boost package, now built 
with Boost.Test library enabled. Try that.


--
VH



signature.asc
Description: OpenPGP digital signature

Re: Wrongfully compiled code

[Václav Haisman]

ariga masahiro wrote:

Hello everyone,

VH wrote,

I think that this list is a wrong one for this kind of compiler problem.
Also, your compiler is rather old one. Have you tried looking for a newer
version of GCC for your target?


I am sorry but I do not know how to get new sh-elf-gcc compiler
and to re_install it on Cygwin.

Please help me.
If you know which site I should refer to,
please enligten me.

Thank you in advance.

Masahiro Ariga
The eCos site seems to suggest GCC 3.2.1. Maybe you could manage to 
build GCC 3.2.3, which is the last of the 3.2 series.


Maybe you should try some sort of eCos support mailing list or forum. 
Cygwin mailing list is really not the right place, I think.


--
VH



signature.asc
Description: OpenPGP digital signature

Re: Wrongfully compiled code

[Václav Haisman]

ariga masahiro wrote, On 15.1.2008 1:51:

Hello,

I am trying to port eCos into my target on Cygwin environment.

I am encountered next wrongfully compiled code and I am very in deep 
trouble.

It happens when sending back TCP SYN-ACK packet to peer,
and it happens in
packages\net\bsd_tcpip\current\src\sys\netinet\tcp_output.c
tcp_output()function.

I asked eCos mailing  list first,
but it says it's a problem of compiler per se,
I shoud ask tool chain mailing list.

My target CPU is SH7709S.

I installed toolchain by downloading ecos-install.tcl.
That I got using next command on Cygwin.
$ wget --passive-ftp ftp://ecos.sourceware.org/pub/ecos/ecos-install.tcl

I checked sh-elf-gcc version and it was version 3.2.1.
$ sh-elf-gcc -v
[...]
I think that this list is a wrong one for this kind of compiler problem. 
Also, your compiler is rather old one. Have you tried looking for a newer 
version of GCC for your target?


--
VH




signature.asc
Description: OpenPGP digital signature

[ANNOUNCEMENT] Updated: boost-1.33.1-4

[Václav Haisman]

The following packages have been updated:

boost-1.33.1-4
boost-devel-1.33.1-4
libboost-1.33.1-4

Changes since 1.33.1-3:

Rebuilt including previously disabled Boost.Test and against Python 2.5.

--
VH


*** 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:

[EMAIL PROTECTED]

If you need more information on unsubscribing, start reading here:

http://sources.redhat.com/lists.html#unsubscribe-simple

Please read *all* of the information on unsubscribing that is available
starting at this URL.



signature.asc
Description: OpenPGP digital signature

Re: cygwin, g++ and boost? Do I need dll.a?

[Václav Haisman]

adam99 wrote, On 9.1.2008 5:57:

I downloaded boost packages under cygwin (both boost and boost-devel). My
first problem is unit test framework was not installed through this
installation. I have tried to create it through bjam and created a library
file at 
I was about to reply that the Boost.Test library is there but then I noticed 
the version of the package on mirrors is only -3. I have built updated 
package with Boost.Test enabled some moths ago but I forgot to actually have 
it uploaded. I will release the -4 package ASAP.


[...]

--
VH




signature.asc
Description: OpenPGP digital signature

Re: cygwin and squid - RLIMIT_NOFILE

[Václav Haisman]

[EMAIL PROTECTED] wrote, On 4.12.2007 4:40:
> David Rothenberger wrote:
> 
>> On 12/3/2007 2:51 PM, [EMAIL PROTECTED] wrote:
>> [snip]
>>> $ squid -N
>>> FATAL: setrlimit: RLIMIT_NOFILE: (24) Too many open files
>>>
>>> This is a classic error described a few times on the mailing list.
>>>
>>> So..
>>> has anybody managed this?!!!
>>> and how?!
>> Is there any reason not to use the Windows-native squid binaries[1]?
>> I thought about trying to package squid-2.6 for Cygwin because of the
>> problems you mention, but when I noticed the Windows-native binaries
>> I decided it wasn't worth the effort.
>>
>> [1] http://www.acmeconsulting.it/SquidNT/
> 
> 
> I did try the windows port, it did not work either. 
> here is a direct link to the download page
> http://squid.acmeconsulting.it/download/dl-squid.html
> 
> I tried with 2.6 stable17, and 2.6 stable16.  Same result. 
> 
> first time I got an error
> C:\squid\sbin>squid
> FATAL: Unable to open configuration file: c:/squid/etc/squid.conf:
> 
> 
> (
> well,
> there is no such file. There was squid.conf.default, so I did
> copy squid.conf.default squid.conf
> )
> 
> 
> I ran it again and got a different error
> C:\squid\sbin>squid
> FATAL: cache_dir c:/squid/var/cache: (2) No such file or directory
> Squid Cache (Version 2.6.STABLE17): Terminated abnormally.
> CPU Usage: 0.030 seconds = 0.010 user + 0.020 sys
> Maximum Resident Size: 3944 KB
> Page faults with physical i/o: 996
> 
> 
> I tried it on another machine, since on this machine (maybe a bad win
> xp) I have been able to run servers, but have had problems when
> installing a server as a service, like openssh runs ./sshd but not net
> start sshd. Anyhow, it did not work on the computer with the fully
> working win xp either. same errors
> 
I think that you need to RTFM. IIRC you first have to create your swap
directories using the -z option.

--
wilx



signature.asc
Description: OpenPGP digital signature

Re: "diff" command missing in cygwin distribution ?

[Václav Haisman]

Finof wrote, On 21.11.2007 11:57:
> Hi,
> 
> I just installed cygwin 2.573.2.2 directly from internet. 
> Trying to get my linux-scripts working I repeated the installation a few
> times (only changing text-mode to binary-mode and back). Now I'm using
> test-mode.
> 
> Now my script fails on a diff command. And to my surprise I can't find
> "diff" in my cygwin-folder.
> Shouldn't it be there ??
Cygwin setup.exe installs only very few packages by default.

Please, use  to find the package that you seek.

--
wilx



signature.asc
Description: OpenPGP digital signature

Re: ZSH completion problem

[Václav Haisman]

Peter A. Castro wrote, On 15.10.2007 23:30:
> On Sun, 14 Oct 2007, Václav Haisman wrote:
> 
>> I have a problem with ZSH completion after updating from 4.3.2-1 to
>> 4.3.4-1.
>>
>> amber2::WilX:~> zsh --version
>> zsh 4.3.4 (i686-pc-cygwin)
>>
>> amber2::WilX:~> cd tmp_path_files:695: command not found: _list_files
>>
>> In this example I have hit TAB after writing "cd tmp". The rest of the
>> line
>> is error message I got.
> 
> Hmm... I'll see if I can reproduce this (I'm not at my machine right
> now).  If you had compinit set before the upgrade you may need to remove
> your .zcompcache and reinitialize it.  There have been a few bugs with
I removed ~/.zcompdump and ~/.zshrc.zwc and it fixed the problem, thanks for
the hint.

> some of the completion items, but that seems like something that would
> have been caught before the release.  I'll check it tonight.
> 
>> Also, Cygwin's ZSH package seems to have the
>> /usr/share/zsh/4.3.4/functions
>> directory flattened compared to what I can see
>> /usr/local/share/zsh/4.3.4/functions on FreeBSD. Is that ok?
> 
> Yes.  It's flat for Linux too (and for the previous releases as well, I
Ok.

> believe).  Or are you refering to the sample Doc instead (which is in
> /usr/share/doc/zsh-4.3.4/Functions/) ?
> 
>> -- 
>> VH
> 

--
VH



signature.asc
Description: OpenPGP digital signature

ZSH completion problem

[Václav Haisman]

I have a problem with ZSH completion after updating from 4.3.2-1 to 4.3.4-1.

amber2::WilX:~> zsh --version
zsh 4.3.4 (i686-pc-cygwin)

amber2::WilX:~> cd tmp_path_files:695: command not found: _list_files

In this example I have hit TAB after writing "cd tmp". The rest of the line
is error message I got.

Also, Cygwin's ZSH package seems to have the /usr/share/zsh/4.3.4/functions
directory flattened compared to what I can see
/usr/local/share/zsh/4.3.4/functions on FreeBSD. Is that ok?

--
VH



signature.asc
Description: OpenPGP digital signature

Re: -exec on find(1) broken

[Václav Haisman]

Paul McFerrin wrote, On 9.10.2007 8:09:
> I think I'm going nuts.  What am I doing wrong?  Can't seem to get -exec
> to work.
> 
>/i/mp3.$ find . -type f -mtime +18 -exec /bin/echo \{\;\} | more
>find: missing argument to `-exec'
>/i/mp3.$ find . -type f -mtime +18 -exec /bin/echo \{\} | more   
> find: missing argument to `-exec'
>/i/mp3.$ find . -type f -mtime +18 -exec /bin/echo '\;' | more
>find: missing argument to `-exec'
>/i/mp3.$ find . -type f -mtime +18 -exec /bin/echo \{;\} | more
>find: missing argument to `-exec'
>/i/mp3.$ find . -type f -mtime +18 -exec echo '\;' | more
>find: missing argument to `-exec'
Try and compare the output of command echo ';' and command echo '\;' and
compare the output. You want to use ';' to terminate the -exec argument list.

> 
> There is NO missing argument to -exec.  What gives?  Is it really broken
> or do I not understand the manual page correctly?
> 
> - paul mcferrin
> 

--
VH



signature.asc
Description: OpenPGP digital signature

Re: possible compiler optimization error

[Václav Haisman]

Frederich, Eric P21322 wrote, On 28.6.2007 19:18:
> On Windows I have found that a program I wrote fails when compiled with
> -O1 and -O2 but runs fine with -O0.
> The program behaves correctly on Linux and Solaris with or without
> optimizations.
> 
> The place it starts behaving differently on Windows is where two numbers
> (which should be equal) are failing a greater than or equal to (>=) if
> statement, but on Solaris and Linux it passes.
> 
> My first thought was that this had to do with floating point
> representation differences on the systems but it doesn't appear to be.
> It appears to be a compiler error.
> 
> The first thing I did was start to print out an equality matrix of the
> double array I was using.
> I was expecting to find a difference in the equality matrices between
> Linux/Solaris and Windows.
> There was none.
> This meant that two numbers which pass an equality (==) check (for the
> purposes of printing the matrix), later failed on a greater than or
> equal to (>=) check which actually affected program flow.
> I then created a corresponding else statement and did some more checking
> of the two numbers and they then pass a greater than or equal to (>=)
> check.
> 
> So, in summary two doubles pass on ==, then fail on >=, then pass ==,
>> =, <= while never being modified.  Does this imply compiler error?
> 
> I have attached two files example.c and example.out which are just
> excerpts from the code and output.
> In example.c I have two versions of the function where the problem is
> happening.  One is the original and one has all of the debugging fprintf
> statements that produced the example.out.  Both versions have the same
> bad behavior, I just wanted to include the clean one so you can see what
> it is doing.
> 
> The function in example.c that is failing is called combineOverlaps
> which just takes line sections (on a circle) and combines them if they
> overlap into a bigger section.
> A section is a simple structure with a double "from" and a double "to".
> The equality matrix for the failing iteration (Lines 214 to 223 from
> example.out) is...
>   0 1 2 3
>   ftftftft
> 0f=...
>  t.==.=...
> 1f.==.=...
>  t...=.==.
> 2f.==.=...
>  t...=.==.
> 3f...=.==.
>  t...=
> 
> This shows that section[0]'s "to" is equal to section[1]'s "from"
> It actually passed twice since I'm printing the full matrix.
> 
> Lines 228 to 230 of example.out are being printed from else clause
> (lines 129 to 136 in example.c) after it fails the >= check and shows
> that afterwards it passes all those other equality checks.
> 
> Here is a summary of where it works and where it doesn't.
> 
> OS  Env GCC Options Pass/Fail
> 
> Windows Msys/mingw  3.4.5   -O2 Fail
> 
> Windows Cygwin  3.4.4   -mno-cygwin -02 Fail
> Windows Cygwin  3.4.4   -02 Fail
> Windows Cygwin  4.1.1   -02 Fail
> 
> Windows Cygwin  3.4.4   -mno-cygwin -00 Pass
> Windows Cygwin  3.4.4   -00 Pass
> Windows Cygwin  4.1.1   -00 Pass
> 
> Linux   4.1.1   -02 Pass
> Linux   3.4.6   -O2 Pass
> 
> Solaris 4.1.1   -02 Pass
> 
> 
> It fails on Windows with any optimization in both 3.4.4 and 4.1.1, so it
> is not just happening on one particular version of the compiler.
> 
> If a program compiled with -O0 has different output than the same
> program compiled with -O1 or -O2, is that defiantly a compile error?
> I do realize that it could be a combination of compiler optimizations
> along with the platform's representation of floating point numbers, but
> isn't that something the compiler should be aware of be careful about?
> 
> Any insight is appreciated.
> 
> Thanks,
> ~Eric
> 
> 
It is either what Dave Korn says or it could be that you are suffering from
excessive precision of x87 and rounding errors. Try to make sure that x87
rounding modes are the same on both Linux and Windows. Also try to add
-ffloat-store flag to compilation command line.

--
wilx



signature.asc
Description: OpenPGP digital signature

Re: Problem with stat

[Václav Haisman]

Erich Dollansky wrote:
[...]
> 
> When I run this little C++ program:
> 
> PRIVATE VOID StatLessdox (VOID)
> BEGIN
>struct   stat Stat;
> 
>IF (stat ("/usr/X11R6/share/doc/lesstif-0.94.4/html/Lessdox", &Stat)
> == 0) THEN
>   printf ("Mode: %lX\n", (unsigned long) Stat.st_mode);
>   IF (S_ISDIR (Stat.st_mode)) THEN
>  printf ("Directory flag is set.\n");
>   END;
>   IF (S_ISREG (Stat.st_mode)) THEN
>  printf ("Is a regular file.\n");
>   END;
>   IF (S_ISLNK (Stat.st_mode)) THEN
>  printf ("Link flag is set.\n");
>   END;
>END;
> END;
[...]
This is NOT C++. Not without some obscure header included before the source.

--
VH




signature.asc
Description: OpenPGP digital signature

Re: _GLIBCXX_USE_C99 not working?

[Václav Haisman]

Christian Franke wrote:
> Defining _GLIBCXX_USE_C99 does not work with current Cygwin C++ includes.
> 
> Testcase:
> 
> #define _GLIBCXX_USE_C99 1 // need std::llabs()
> 
> #include 
> 
> long long f(long long x)
> {
>return std::llabs(x);
> }
> 
> 
> Compile fails with:
> 
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cstdlib:181:
>  error: `::strtold' has not been declared
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cstdlib:200:
>  error: `__gnu_cxx::strtold' has not been declared
> 
> 
> The function strtold() does actually not exist in stdlib.h
> and the corresponding _GLIBCXX_HAVE_STRTOLD in
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/i686-pc-cygwin/bits/c++config.h
> 
> is not set.
> 
> But "using ::strtold" exists in the "#if _GLIBCXX_USE_C99" part of
> /usr/lib/gcc/i686-pc-cygwin/3.4.4/include/c++/cstdlib
> 
> Workaround: delete the two "using ::strtold" lines from cstdlib.
> 
> Christian
Look into the cstdlib header. You will find that llabs(long long) and
abs(long long) are in the __gnu_cxx namespace there. It is because long
long is not C++ standard type.

--
Vaclav Haisman



signature.asc
Description: OpenPGP digital signature

Re: Login shell ZSH spins when executed from SSH session

[Václav Haisman]

Corinna Vinschen wrote, On 13.4.2007 15:37:
> On Apr  4 19:56, V?clav Haisman wrote:
>> Hi,
>> I have installed Cygwin snapshot of 1.7. Since then I cannot use SSH because
>> ZSH shell that I use spins with 100%. I straced the spinning shell and this
>> is what it shows:
>>
>> App version:  1005.18, api: 0.132
>> DLL version:  1007.0, api: 0.167
>> DLL build:20070330 09:36:55SNP
>> OS version:   Windows NT-5.1
>> Heap size:402653184
>> Date/Time:2007-04-04 19:44:09
>> **
>>   115 781 [main] -zsh 7380 fhandler_pipe::create_selectable: pipe access
>> denied, retrying
>>78 859 [main] -zsh 7380 fhandler_pipe::create_selectable:
>> CreateNamedPipe: name \\.\pipe\cygwin-0x1CD4-0xA333FA, size 65536
>>   111 970 [main] -zsh 7380 fhandler_pipe::create_selectable: pipe access
>> denied, retrying
>> 17284   18254 [main] -zsh 7380 fhandler_pipe::create_selectable:
>> CreateNamedPipe: name \\.\pipe\cygwin-0x1CD4-0xA333FB, size 65536
>>   152   18406 [main] -zsh 7380 fhandler_pipe::create_selectable: pipe access
>> denied, retrying
>>48   18454 [main] -zsh 7380 fhandler_pipe::create_selectable:
>> CreateNamedPipe: name \\.\pipe\cygwin-0x1CD4-0xA333FC, size 65536
>> [...]
> 
> Can you test with which patch in CVS this has been introduced?
> 
> 
> Corinna
> 
Sorry for this late reply, I have not noticed your post earlier.

I did binary search and the problem seems to be in changes between snapshots
2006-12-12 and 2006-12-15. I don't have Cygwin CVS build set up but I will
try to do so and narrow it to a single patch.

--
wilx



signature.asc
Description: OpenPGP digital signature

Re: C++ name with leading underscore character not Compiling

[Václav Haisman]

Dave Korn wrote:
> On 16 April 2007 10:34, Chelton Evans wrote:
> 
>> I believe it is legal to have a C++ variable name with a leading
>>  underscore.
> 
>   No.  All names beginning with an underscore are reserved for the
> implementation.
> 
Nit pick, IIRC only names that start with underscore and capital letter
or that start with double underscores are reserved. Single underscore
and small letter should be available to users.

>[...]

--
Vaclav Haisman



signature.asc
Description: OpenPGP digital signature