On Dec 06 18:45:11, h...@stare.cz 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?
Ah, it gets configured once but compiled *twice*, inside Xcode, right?
So my "compile time" argument above misses the point, right?
(Please excuse my UB ignorance, never used it.)
Jan
_______________________________________________
macports-users mailing list
macports-users@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-users
