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
