On 2021/10/28 22:36, Nam Nguyen wrote:
> I prepared a release tarball from a checkout:
> install groff for tbl and nroff
> install autoconf-archive, autoconf and automake
> edit src/Makefile.am append "libsox.sym" to EXTRA_DIST (needed to avoid
> compilation error)
> edit configure.ac: 14.4.3git --> 14.4.2pl20210509
> $ AUTOCONF_VERSION=2.69 AUTOMAKE_VERSION=1.16 autoreconf-2.69 -i
> $ ./configure
> $ gmake dist
I would prefer it if those extra steps were done in the port, either as
a "dist" target to generate the tar, or as steps in the normal build
so that it can use an unmodified archive from git. Alternatively (less
preferred but I would still be ok with it) with comments showing how
to do it. Bsaically so that somebody else wanting to update it doesn't
need to figure it out for themselves.
> Minor bump
> ----------
> Minor increased because check_sym reports new lsx_* symbols. According
> to the top of ${WRKSRC}/src/sox.h, "lsx_" or "LSX_" are internal use,
> but bump it anyways due their visibility. (sox_* are part of the public
> interface.)
ack.
> check_sym: https://namtsui.com/public/sox_sym.txt
>
> Also, datatypes changed in ${WRKSRC}/src/sox.h.
> See:
> https://sourceforge.net/p/sox/code/ci/3518bcd92416e7cf71ee9a863695a518f3de4e52/
> /usr/src/sys/sys/types.h
> /usr/src/sys/sys/stdint.h
> /usr/src/sys/arch/i386/include/_types.h
> /usr/src/sys/sys/limits.h
>
> Based on this, the only difficult one was long --> long long.
>
> -#if LONG_MAX==9223372036854775807 && LONG_MIN==(-9223372036854775807-1)
> -typedef long sox_int64_t;
> -#elif defined(_MSC_VER)
> -typedef __int64 sox_int64_t;
> -#else
> -typedef long long sox_int64_t;
> -#endif
> +typedef int64_t sox_int64_t;
>
> From this I read sox_int64_t's type definition before --> after:
> amd64: long --> long long
> i386: long long --> long long
>
> Conclusion: Types changed in a compatible way because it goes from a
> smaller to bigger datatype, so no need to major bump. sox_uint64_t also
> falls under this.
Had the types changed to a different size, even from a smaller to a
bigger datatype e.g. 32-bit to 64-bit, that wouldn't be a compatible
change - structs using them would change layout (maybe not on all archs
depending on how the variables are layed out, but there's also little-
vs big-endian to take into account), same for variables passed to
functions.
However these only changed to different types represented by the same
byte format, i.e. on 64-bit arches both long and long long are 64-bit
so there's no actual change to layout, so that doesn't break ABI.
Newer compilers warn about the difference in type rather than the
difference in representation because it can be a problem if you test
something on one arch and don't see a mismatch, but then somebody
goes to build on another and runs into the problem.
> make port-lib-depends still wants to remove opus from WANTLIB, which is
> new behavior. I do not know why. However, it is probably just fine to
> leave it in for clarity. sox uses opusfile, which depends on opus
> anyways.
Could you remove that please - sox doesn't use libopus functions directly,
only uses other libraries which call those functions. This changed because
sox now uses -Wl,--as-needed.
> - --without-amrwb \
> - --without-amrnb \
> + --enable-formats=no \
Though --enable-formats=no stops it from building the amr format
support, I think it would be better to disable it detecting it at all,
i.e.
--without-opencore-amrnb \
--without-opencore-amrwb \
> do-test:
> + @cd ${WRKSRC}/src && env -i ${MAKE_ENV} ${MAKE_PROGRAM} ${MAKE_FLAGS} \
"env -i ${MAKE_ENV}" isn't needed, the environment is already setup
enough for this
> # Attempt to avoid SIGILL in gcc.
- which sets an hppa-only thing, and there's also BROKEN-hppa.
The code changed, so I would just remove both of these. If someone
actually does a ports build on hppa we can see how it goes.
