icecast-1.3.11 port to cygwin

icecast-1.3.11 port to cygwin

[Li-Kai Liu]

i've been dealing with icecast on cygwin platform for a few months here, 
and some time ago i've had a private branch of icecast-1.3.10 that can 
compile under cygwin. however, cygwin prior to 1.3.3 has crippled 
pthread support so icecast couldn't run as a native cygwin program. 
luckily icecast can be configured to use win32 threads, so I modified 
the build system to use mingw (and disable cygwin) when building 
icecast. I was able to get a gcc compiled binary that functions the same 
as win32 icecast.

after cygwin 1.3.3 has been released, i've also compiled the 
icecast-1.3.11 source code as native cygwin proram. it now runs with 
minor problems. most noticible is its inability to catch SIGINT from the 
tty -- perhaps this does have something to do with pthreads -- and when 
shutting down (from remote operator), it stackdumps when waiting for 
other threads to finish up. if interested, I'd be glad to assist 
debugging icecast on cygwin pthreads.

as for now, mingw icecast works great with no noticible defects. once 
all cygwin-related problems are fixed (and if anyone is interested in my 
business) I will put together what I have here and contrib.

liulk

ps. my branch of icecast-1.3.11 source code didn't receive many patches 
... mostly bug fixes or corrections that are not cygwin-specific.


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

Re: icecast-1.3.11 port to cygwin

[Robert Collins]

----- Original Message -----
From: "Li-Kai Liu" <news@likai.net>
To: "cygwin" <cygwin@cygwin.com>
Sent: Monday, September 17, 2001 8:02 AM
Subject: icecast-1.3.11 port to cygwin


> i've been dealing with icecast on cygwin platform for a few months
here,
> and some time ago i've had a private branch of icecast-1.3.10 that can
> compile under cygwin. however, cygwin prior to 1.3.3 has crippled
> pthread support so icecast couldn't run as a native cygwin program.

In what way? 1.3.2 had a bug in it, but no significant functionality
that was not present in 1.1.8.

> after cygwin 1.3.3 has been released, i've also compiled the
> icecast-1.3.11 source code as native cygwin proram. it now runs with
> minor problems. most noticible is its inability to catch SIGINT from
the
> tty -- perhaps this does have something to do with pthreads -- and
when
> shutting down (from remote operator), it stackdumps when waiting for
> other threads to finish up. if interested, I'd be glad to assist
> debugging icecast on cygwin pthreads.

Please do. I'm always interested in clear fault reports, or test cases.
If you can generate a trivial testcase, or sometimes even just a good
description of what is occuring in your program, I will endeavour to fix
the bug.

Rob


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

Re: icecast-1.3.11 port to cygwin

[Li-Kai Liu]

i'm just a poor fellow trying to port icecast to cygwin, and i'm not 
associated with icecast development team. :(

as i'm still studying the case myself, i just felt that I could make 
announcement based on what I already know. apparantly icecast uses their 
own thread management functions that traces active threads within the 
process. in cygwin prior to 1.3.3, icecast would complain during 
thread_init that "mt: thread never made to life ... weird" while the 
same time it says something like "unknown thread is running." I've 
reported to the icecast team and all they told me was not to use cygwin 
because pthread is broken. all I know is icecast tries to check the 
thread pointer using pthread_self() function and for some reason it 
doesn't return a reliable value.

i have a question though: does pthread_detach() in cygwin (before 1.3.3) 
change anything that is returned from pthread_self()? because i noticed 
how, after creating the thread, icecast calls this function. i strongly 
feel this has something to do with the phenomenon. anyhow, this problem 
is not present in cygwin 1.3.3 anymore, so i'd like to focus on other 
two problems.

- inability to catch signal ... i have no idea where to start finding 
the source of problem for this. can you give me a hint?
- coredump when waiting for threads to exit ... i will study this some more.

and as i said at the beginning, i'm not an active developer for icecast, 
so i'm just trying to bring icecast over to cygwin. the icecast 
developers don't seem to be keen about this port. (also, this is *not* 
my program).

liulk

Robert Collins wrote:

>Please do. I'm always interested in clear fault reports, or test cases.
>If you can generate a trivial testcase, or sometimes even just a good
>description of what is occuring in your program, I will endeavour to fix
>the bug.
>
>Rob
>



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

Re: icecast-1.3.11 port to cygwin

[Robert Collins]

----- Original Message -----
From: "Li-Kai Liu" <news@likai.net>
To: "cygwin" <cygwin@cygwin.com>; <robert.collins@itdomain.com.au>
Sent: Monday, September 17, 2001 9:18 AM
Subject: Re: icecast-1.3.11 port to cygwin


> i'm just a poor fellow trying to port icecast to cygwin, and i'm not
> associated with icecast development team. :(
>
> as i'm still studying the case myself, i just felt that I could make
> announcement based on what I already know. apparantly icecast uses
their
> own thread management functions that traces active threads within the
> process. in cygwin prior to 1.3.3, icecast would complain during
> thread_init that "mt: thread never made to life ... weird" while the
> same time it says something like "unknown thread is running." I've
> reported to the icecast team and all they told me was not to use
cygwin
> because pthread is broken. all I know is icecast tries to check the
> thread pointer using pthread_self() function and for some reason it
> doesn't return a reliable value.

I don't believe this has changed from pre 1.1.8. (in other words, in a
long time :}). pthread_equal was broken at one point though (between
1.1.8 and 1.3.2, and then fixed again for 1.3.3).

If the icecast team consider cygwin pthreads broken, they might consider
submitting bug reports. I'm quite active in tracking down the problem
once I've got a good pointer. (This is a general issue, from time to
time I hear things like "xyz is broken" and when I enquire, the "xyz"
developers _have not been told_!.

> i have a question though: does pthread_detach() in cygwin (before
1.3.3)
> change anything that is returned from pthread_self()? because i
noticed

No. pthread_detach changes the behaviour of exiting threads, not their
identifiers.

> how, after creating the thread, icecast calls this function. i
strongly
> feel this has something to do with the phenomenon. anyhow, this
problem
> is not present in cygwin 1.3.3 anymore, so i'd like to focus on other
> two problems.
>
> - inability to catch signal ... i have no idea where to start finding
> the source of problem for this. can you give me a hint?

Well to start with grab the Cygwin source
( http://www.cygwin.com/contrib.html ) and build yourself a debug .dll.
(You'll need that :} ).

Chris Faylor just wrote a "how-signals-works.txt" file, which you will
find in the source tarballs. Read that. Then start test cases I guess.
I.e. can you catch the signal during sleep()? Is it only catching the
signal on I/O that matters? and so forth. Once you've got a reproducible
minimal test case, then start thinking about how to correct it. I
suggest that at that point it's appropriate to bring the issue up here,
so we can all discuss it. It may be one of the "we really don't know how
to do x" issues, or perhaps we will have some pointers for things for
you to try.

> - coredump when waiting for threads to exit ... i will study this some
more.

This shouldn't happen. Attach to the program with gdb, and your debug
.dll, and see where they are crashing.

> and as i said at the beginning, i'm not an active developer for
icecast,

However, from my point of view, you
a) understand icecast more than I do
b) want it to work on cygwin
c) are willing to put time and effort into doing so.

So I'd call you the icecast cygwin developer team ;}.

> so i'm just trying to bring icecast over to cygwin. the icecast
> developers don't seem to be keen about this port. (also, this is *not*
> my program).

It is for the purposes of this exercise.

Rob


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

Re: icecast-1.3.11 port to cygwin

[Christopher Faylor]

On Mon, Sep 17, 2001 at 09:43:45AM +1000, Robert Collins wrote:
>> - inability to catch signal ... i have no idea where to start finding
>> the source of problem for this. can you give me a hint?
>
>Well to start with grab the Cygwin source
>( http://www.cygwin.com/contrib.html ) and build yourself a debug .dll.
>(You'll need that :} ).
>
>Chris Faylor just wrote a "how-signals-works.txt" file, which you will
>find in the source tarballs. Read that. Then start test cases I guess.

One thing that I should mention is that signals only work with cygwin
functions.  You can't do a "ReadFile" or a "Sleep" and expect the call
to be interrupted by a signal.

So, if icecast is mixing Windows functions and UNIX signals this will
be a problem.

cgf

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

Re: icecast-1.3.11 port to cygwin

[Li-Kai Liu]

Christopher Faylor wrote:

>One thing that I should mention is that signals only work with cygwin
>functions.  You can't do a "ReadFile" or a "Sleep" and expect the call
>to be interrupted by a signal.
>
>So, if icecast is mixing Windows functions and UNIX signals this will
>be a problem.
>
>cgf
>
i believe icecast does not do so. i explicitly compiled the cygwin 
icecast with -mno-win32 flag because otherwise it would try to use win32 
threads and include the wrong config.h file (in their build system, 
they've put up a win32config.h that gets included when _WIN32 is defined).

i'd like to say greetings to christopher! i've read many documents in 
cygwin that is signed by your name! i just want to let your know that I 
use cygwin regularly as if it has become part of my life (it is really 
part of my life).

i guess this will mark a temporary dormancy of this discussion when I 
try to find out what is wrong with icecast/cygwin.

liulk



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