Re: QuickTime Streaming Server for Linux.. on x86

Re: QuickTime Streaming Server for Linux.. on x86

[Hollis R Blanchard]

On Thu, 8 Jul 1999, Jason Haas wrote:
> 
> Apparently Apple's releasing part of the QT Streaming Server as "open
> source". It'll run on Mac OS X Server and Linux/x86.
> 
> Hmm.
> 
> http://theregister.co.uk/990708-000012.html
> 
> What's slightly wrong with this picture?

Nope, doesn't compile. Lots of warnings (mostly implicit function
declarations) for the library, and then the server compile dies with

main.cpp: In function `int main(int, char **)':
main.cpp:101: no match for `__sigset_t & = int'
/usr/include/bits/sigset.h:31: candidates are: __sigset_t::operator =(const
{anonymous struct} &)

Also, lots and lots of "warning: multi-character character constant" coming
from lines like

static const FourCharCode kFractionLostPacketsSig = 'frac';

Should those single ticks be quotes?

-Hollis


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: QuickTime Streaming Server for Linux.. on x86

[Charles A. Jolley]

> 
> Also, lots and lots of "warning: multi-character character constant" coming
> from lines like
>
> static const FourCharCode kFractionLostPacketsSig = 'frac';
>
> Should those single ticks be quotes?
>
> -Hollis

The MacOS makes extensive use of 4-character constants (32-bit values) to
identify file and creator types, and also the types of resources in the
resource fork of a file.  The single quote method is a standard way of
indicating these constants and all MacOS compilers will take it without
complaint.  I encountered this same problem when porting some Mac stuff to
Linux some time ago.  I seem to recall that the compiler complained but
produced the right results anyway.  My Linux systems are down right now so I
can't check to make sure and I've since updated all my old code to work
around it.

Changing the single ticks to quotes will most definitely introduce errors,
though, because that will cause the compiler to produce a 32-bit pointer to
a NULL terminated string "frac", rather than a 32-bit value equal to the
four characters 'frac'.  This can be particularly deadly in code where types
are explicitly cast because it is still a 32-bit value either way.

Cheers,
-Charles


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: QuickTime Streaming Server for Linux.. on x86

[Hollis R Blanchard]

On Thu, 8 Jul 1999, Charles A. Jolley wrote:
> > 
> > Also, lots and lots of "warning: multi-character character constant" coming
> > from lines like
> >
> > static const FourCharCode kFractionLostPacketsSig = 'frac';
> >
> > Should those single ticks be quotes?
> >
> > -Hollis
> 
> The MacOS makes extensive use of 4-character constants (32-bit values) to
> identify file and creator types, and also the types of resources in the
> resource fork of a file.  The single quote method is a standard way of
> indicating these constants and all MacOS compilers will take it without
> complaint.  I encountered this same problem when porting some Mac stuff to
> Linux some time ago.  I seem to recall that the compiler complained but
> produced the right results anyway.  My Linux systems are down right now so I
> can't check to make sure and I've since updated all my old code to work
> around it.

I remember that much from the very little Mac OS programming I've done... but
I was just wondering how the compiler was handling it. I mean, if I were a
compiler and I was just translating chars in 's to ascii values, I'd probably
get confused. If it's no problem, then why is it a warning?

> Changing the single ticks to quotes will most definitely introduce errors,
> though, because that will cause the compiler to produce a 32-bit pointer to
> a NULL terminated string "frac", rather than a 32-bit value equal to the
> four characters 'frac'.  This can be particularly deadly in code where types
> are explicitly cast because it is still a 32-bit value either way.

Just hoping for a quick fix... =)

Also, was the two-line patch mentioned before for LinuxPPC? Whose is it and
where is it? The darwin-streaming Apple mailing list is exceptionally dead,
and I haven't seen any mention of LinuxPPC anything on there.

-Hollis


[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: QuickTime Streaming Server for Linux.. on x86

[Dan Burcaw]

On Thu, 8 Jul 1999, Hollis R Blanchard wrote:

> 
> On Thu, 8 Jul 1999, Charles A. Jolley wrote:
> > > 
> > > Also, lots and lots of "warning: multi-character character constant" coming
> > > from lines like
> > >
> > > static const FourCharCode kFractionLostPacketsSig = 'frac';
> > >
> > > Should those single ticks be quotes?
> > >
> > > -Hollis
> > 
> > The MacOS makes extensive use of 4-character constants (32-bit values) to
> > identify file and creator types, and also the types of resources in the
> > resource fork of a file.  The single quote method is a standard way of
> > indicating these constants and all MacOS compilers will take it without
> > complaint.  I encountered this same problem when porting some Mac stuff to
> > Linux some time ago.  I seem to recall that the compiler complained but
> > produced the right results anyway.  My Linux systems are down right now so I
> > can't check to make sure and I've since updated all my old code to work
> > around it.
> 
> I remember that much from the very little Mac OS programming I've done... but
> I was just wondering how the compiler was handling it. I mean, if I were a
> compiler and I was just translating chars in 's to ascii values, I'd probably
> get confused. If it's no problem, then why is it a warning?
> 
> > Changing the single ticks to quotes will most definitely introduce errors,
> > though, because that will cause the compiler to produce a 32-bit pointer to
> > a NULL terminated string "frac", rather than a 32-bit value equal to the
> > four characters 'frac'.  This can be particularly deadly in code where types
> > are explicitly cast because it is still a 32-bit value either way.
> 
> Just hoping for a quick fix... =)
> 
> Also, was the two-line patch mentioned before for LinuxPPC? Whose is it and
> where is it? The darwin-streaming Apple mailing list is exceptionally dead,
> and I haven't seen any mention of LinuxPPC anything on there.

Yes it was. Was just worked on yesterday.. 


> 
> -Hollis
> 

> 


Dan

Terra Soft Solutions, Inc.
 email: dburcaw@yellowdoglinux.com
 website: http://www.yellowdoglinux.com/



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: QuickTime Streaming Server for Linux.. on x86

[Deirdre Saoirse]

At 4:09 PM -0400 7/8/99, Hollis R Blanchard wrote:
>On Thu, 8 Jul 1999, Charles A. Jolley wrote:
>> Changing the single ticks to quotes will most definitely introduce errors,
>> though, because that will cause the compiler to produce a 32-bit pointer to
>> a NULL terminated string "frac", rather than a 32-bit value equal to the
>> four characters 'frac'.  This can be particularly deadly in code where types
>> are explicitly cast because it is still a 32-bit value either way.
>
>Just hoping for a quick fix... =)

Try treating the four-char constant as a four-byte integer instead. That's
really how it's represented in the MacOS. :)

Think of it as an undotted quad. :)


Deirdre Saoirse, Systems Analyst, Linuxcare, Inc.
415.354.4878 x252 tel, 415.701.7457 fax
dsaoirse@linuxcare.com, http://www.linuxcare.com/
Linuxcare. At the center of Linux.



[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]

Re: QuickTime Streaming Server for Linux.. on x86

[Dan Burcaw]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 557 bytes --]

Hey all,

I just tweaked the Streaming Server to work on PPC Linux and I have a
patch available. I haven't tested an actual streaming of audio or video to
see how well it works but at least this will let you build the server
which is a good first step. 

The good news is that all it took was very little modification of the
source to make it work.

The patch is attached to this email and is called
"StreamingServer-2-ppclinux.patch". 


Regards,
Dan

Terra Soft Solutions, Inc.
 email: dburcaw@yellowdoglinux.com
 website: http://www.yellowdoglinux.com/


[-- Attachment #2: Type: TEXT/PLAIN, Size: 755 bytes --]

--- StreamingServer-2/RhapServer/main.cpp.o	Fri Jul  9 01:15:18 1999
+++ StreamingServer-2/RhapServer/main.cpp	Fri Jul  9 01:36:07 1999
@@ -93,7 +93,7 @@
 	//(void) ::signal(SIGPIPE, SIG_IGN);
 	struct sigaction act;
 	
-#if defined(sun) || defined(i386)
+#if defined(sun) || defined(i386) || defined(powerpc)
 	sigemptyset(&act.sa_mask);
 	act.sa_flags = 0;
 	act.sa_handler = (void(*)(int))&sigcatcher;
--- StreamingServer-2/RhapServer/UDPSocket.cpp.o	Fri Jul  9 02:05:48 1999
+++ StreamingServer-2/RhapServer/UDPSocket.cpp	Fri Jul  9 02:07:41 1999
@@ -40,7 +40,11 @@
 #endif
 
 #if __linux__
+#if __GLIBC__ >= 2
+#include <bits/socket.h>
+#else
 #include <socketbits.h>
+#endif
 #endif
 #include "UDPSocket.h"
 #include "OS.h"

Re: QuickTime Streaming Server for Linux.. on x86

[Joel Klecker]

At 02:34 -0600 1999-07-09, Dan Burcaw wrote:
>--- StreamingServer-2/RhapServer/UDPSocket.cpp.o	Fri Jul  9 
>02:05:48 1999
>+++ StreamingServer-2/RhapServer/UDPSocket.cpp	Fri Jul  9 02:07:41 1999
>@@ -40,7 +40,11 @@
> #endif
>
> #if __linux__
>+#if __GLIBC__ >= 2
>+#include <bits/socket.h>
>+#else
> #include <socketbits.h>
>+#endif

Ugh, that is so wrong it's not even funny, both of those are internal 
headers to glibc, and should not be included directly. The portable 
way is <sys/socket.h> (which in the glibc implementation includes the 
appropriate internal header). Whoever's responsible for the linux 
patches ought to be shot.
-- 
Joel Klecker (aka Espy)                    Debian GNU/Linux Developer
<URL:mailto:jk@espy.org>                 <URL:mailto:espy@debian.org>
<URL:http://web.espy.org/>               <URL:http://www.debian.org/>

[[ This message was sent via the linuxppc-dev mailing list.  Replies are ]]
[[ not  forced  back  to the list, so be sure to Cc linuxppc-dev if your ]]
[[ reply is of general interest. Please check http://lists.linuxppc.org/ ]]
[[ and http://www.linuxppc.org/ for useful information before posting.   ]]