Margot Miller wrote:
Let's just go with the simple one that doesn't
have the #elifs. ( The #elifs were suggested so
it would fall through to "You need to define 64
bit operations for your platform" if you were
porting this to another platform).
I am rebuilding now with the attached below and
will put back only to hxclient_1_3_0_neptunex.
What ever patch you use, you need to commit it to 150Cay.
If you don't, any build you do in the future that comes
off of 150Cay, or any branch made from it, will not have
your fix. Same goes with HEAD. So, make sure all three
branches have some form of your math64.h fix.
--greg.
Thanks
Margot
Date: Fri, 09 Dec 2005 09:40:35 -0800
From: Greg Wright <[EMAIL PROTECTED]>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: Margot Miller <[EMAIL PROTECTED]>
CC: [email protected], [EMAIL PROTECTED]
Subject: Re: [Audio-dev] CR: Sporadic Relocation error on Solaris
Content-Transfer-Encoding: 7bit
Margot Miller wrote:
I changed all the #if's to #elifs because that
is what Ryan had asked me to do before and it
would match better what is in HEAD.
Oh, if HEAD is like that then it is OK. Just show me the
diff to HEAD then. If you already made the change, that is
OK too. Either way is fine with me since it looks like it
has been used on HEAD for a while I guess.
--greg.
No problem I will do it without the #elifs.
MARgot
Date: Thu, 08 Dec 2005 16:01:18 -0800
From: Greg Wright <[EMAIL PROTECTED]>
User-Agent: Thunderbird 1.4 (Windows/20050908)
MIME-Version: 1.0
To: Margot Miller <[EMAIL PROTECTED]>
CC: [email protected], [EMAIL PROTECTED]
Subject: Re: [Audio-dev] CR: Sporadic Relocation error on Solaris
Content-Transfer-Encoding: 7bit
Why was it necessary to change all the #if to #elifs? It is just a little
scary because there is a *lot* of platforms that could be affected. Can you
just make the change without all those? I really don't see anything wrong
with it but I also can't guarantee that nothing will break with some random
compiler/platform. I just can't tell from the diff how nested things might
be.
If you could try that the CR would be a lot faster.
--greg.
Margot Miller wrote:
Modified by: [EMAIL PROTECTED],[EMAIL PROTECTED]
Reviewed by: NEEDED
Date: 10:06:05
Project: Support for Solaris X86
Synopsis:
Adding full Solaris Sparc and X86 support in math64.h to fix
sporadic MulShift30 unreference symbol error.
Overview:
This was reported in Bug 3533:
Running Solaris 10 (beta 72) on a Sun Blade 1500,
RealPlayer 10.0.2.619 dies while streaming audio from
<rtsp://real.advance.net:7071/encoder/frodo/frodo.rm>
after a few minutes with the message:
ld.so.1: /path/RealPlayer10/realplay.bin: fatal: relocation error: file
/path/RealPlayer10/common/clntcore.so: symbol MulShift30: referenced
symbol
not
found
Also reported in Bug 4687:
ld.so.1: realplay.bin: fatal: relocation error: file
/usr/local/RealPlayer/common/clntcore.so: symbol MulShift30:
referenced symbol not found
at various times in the middle of a stream. It's not deterministic,
I can play the same stream again and not get it. This has occurred
from time to time with any of the realplay sparc downloads, most
recently I'm running 10.0.6.1219 RXEN10.
Built using:
[0] Set BIF branch (realplayer_gtk_stable)
[1] Set Target(s) (player_all)
[2] Set Profile
(/build1/buildingNOV/build/umakepf/helix-client-all-defines)
math64.h was modified before in cayenne branch and Head for Solaris
X86. This fix for Neptune branch is similar. Now, Sparc and X86
Solaris will share the same block of code.
As a result, the fix for this problem is to:
- Use the HPUX block of code for Solaris X86 and Solaris
SPARC by adding the correct defines for Solaris:
#elif defined(_HPUX) || (defined (_SOLARIS) && !defined (__GNUC__))
- Delete the block of code that has similar functions
that the HPUX block of code already has.
The block of code being deleted was:
#if (defined(__SVR4) && defined(__i386) && (defined(_NO_GNU_AS) ||
!defined(__GNUC__)) )
/* No 64bit, no asm provided in some other file..
* need normal funcs for sun forte CC + 386
* However... forte's inline assembly for MulShift32 is just as good
* as the "hand tuned" gcc version, if you use
* cc -fast
*/
....
- Delete the sparc block of code; it was missing MulShift30.
- Use #if/#elif constructs
This should be very similar to what is in the HEAD and cayenne
now. Only difference should be that SPARC and X86 SOLARIS using same
block of code.
Files Added:
[File 1] - NONE
Files Modified:
[File 3] - audio/fixptutil/pub/math64.h
Image Size and Heap Use impact (Client -Only):
<Description of image size and heaps size impact. >
Platforms and Profiles Affected:
Tested on X86 with helix-client-all-defines profile
Distribution Libraries Affected:
<List of distribution libraries affected>
Distribution library impact and planned action:
<Is an update required and if so when will it occur>
Platforms and Profiles Build Verified:
Platform - x86.
brion% uname -a
SunOS brion 5.10 Generic i86pc i386 i86pc
brion%
Profile:helix-client-all-defines
Platforms and Profiles Functionality verified:
Same as above
Branch: <code branch(es) change is for>
Head, Neptune, Cayenne.
Copyright assignment: <MUST be one of the following statements >
3. My company SUN is bound by the terms
of a commercial contribution agreement with RealNetworks,
and I am authorized to contribute this code under said
agreement.
QA Instructions:
Full test suites run on an X86 and Sparc machines running Solaris 10.
------------- End Forwarded Message -------------
------------------------------------------------------------------------
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
_______________________________________________
Audio-dev mailing list
[email protected]
http://lists.helixcommunity.org/mailman/listinfo/audio-dev
