> On Dec 6, 2015, at 11:45 AM, Jan Stary wrote: > >> On Nov 26 20:20:28, nore...@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. _______________________________________________ macports-users mailing list macports-users@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-users