[MacPorts] #49821: libsndfile - update to 1.0.26

[Ryan Schmidt]

> On Dec 6, 2015, at 11:45 AM, Jan Stary wrote:
> 
>> On Nov 26 20:20:28, noreply at macports.org wrote:
>>> #49821: libsndfile - update to 1.0.26
>>> -------------------------+--------------------------------
>>>  Reporter:  hans@???      |      Owner:  macports-tickets@???
>>>      Type:  update      |     Status:  new
>>>  Priority:  Normal      |  Milestone:
>>> Component:  ports       |    Version:  2.3.4
>>> Resolution:              |   Keywords:  haspatch
>>>      Port:  libsndfile  |
>>> -------------------------+--------------------------------
>>> 
>>> Old description:
>>> 
>>>> Here is a patch to the Portfile of audio/libsndfile
>>>> which brings it to the latest 1.0.26 release,
>>>> and the upgraded version of files/
>>>> 
>>>> The speex.patch removes SPEEX_* from EXTERNAL_* in configure;
>>>> I believe speex.patch is a better name, and configure.patch
>>>> should be replaced with this.
>>>> 
>>>> The carbon.patch is a better version of fix-include.patch
>>>> which it should replace. Not only does it remove the Carbon.h include
>>>> from sndfile-play.c, but it removes Carbon altogether.
>>>> 
>>>> I am leaving src__config.h.ed as is, but I am not completely sure
>>>> about its purpose; if __BIG_ENDIAN__, __LP64__, etc, is defined,
>>>> then ./configure (which creates config.h) is supposed to figure out
>>>> the SIZEOF_LONG etc, right? If not, it's a bug in configure,
>>>> not something we should patch in the resulting config.h, right?
>>>> 
>>>> I also removed the sqlite variant from the Portfile.
>>>> Only sndfile-regtest uses sqlite; does anybody use sndfile-regtest?
>>>> 
>>>> Jan
>>> 
>>> You can easily discover using "svn log" and "svn blame" that this file was
>>> added in r42762 to resolve #17088, when libsndfile was at version 1.0.17.
>> 
> Thanks for the pointer, I have my svn tree now.
> 
> The root cause seems to be
> http://www.mega-nerd.com/libsndfile/FAQ.html#Q018
> Please help me understand it clearly (author cc'd).
> The chunks of the diff between the original config.h
> and the patched one look like this:
> 
> 	+#ifdef __LP64__
> 	+#define CPU_CLIPS_NEGATIVE 0
> 	+#else
>  	#define CPU_CLIPS_NEGATIVE 1
> 	+#endif
>  	
> 	+#ifdef __BIG_ENDIAN__
> 	+#define CPU_IS_BIG_ENDIAN 1
> 	+#else
>  	#define CPU_IS_BIG_ENDIAN 0
> 	+#endif
> 
> Why do we need this?
> The defines are used in code like this:
> 
>   if (CPU_CLIPS_POSITIVE == 0 && scaled_value >= (1.0 * 0x7FFFFFFF)) {
> 	  dest [count] = 127 ;
> 	  continue ;
>   } ;
> 
> 
> The condition (CPU_CLIPS_POSITIVE == 0) is decided at compile time,
> whether it is defined to be 0 or 1. So even with the patch,
> libsndfile is compiled to behave this way, or it is compiled
> to behave the other way.
> 
> I don't have a BIGENDIAN mac or a LP64 mac to test on,
> but doesn't ./configure just define the constants
> to be the appropriate value, on a LP64 machine?
> Can people with BIGENDIAN or LP64 machine please test?
> 
> Maybe I am missing something obvious, but how exactly does this
> patch result in a universal binary, as opposed to without it?
> 
> 	Jan

Please enter your reply on the ticket web page, not by email:

https://trac.macports.org/ticket/49821

Then I'll reply there.