mpg123-devel — Mailing list for mpg123 developers

[mpg123-devel] Opened GH-#15: aarch64: enable PAC/BTI [billatarm]

[<ano...@gm...>]

A pull request by billatarm  was opened at 2024-09-06 15:17:54+00:00.

Please visit https://github.com/madebr/mpg123/pull/15 to give feedback and review the code.

---

Enable Pointer Authentication Codes (PAC) and Branch Target Identification (BTI) support for ARM 64 targets.

PAC works by signing the LR with either an A key or B key and verifying the return address. Since the assembly code does not push and pop the link register to the stack, and it remains in the register file, their is no need to sign the LR, so PAC is essentially just adding it to the GNU notes section for auditing purposes.

BTI works by marking all call and jump positions with bti c and bti j instructions. If execution control transfers via an indirect branch or call to an instruction other than a BTI instruction, the execution is killed via SIGILL.

For BTI to work, all object files linked for a unit of execution, whether an executable or a library must have the GNU Notes section of the ELF file marked to indicate BTI support. This is so loader/linkers can apply the proper permission bits (PROT_BRI) on the memory region.

PAC can also be annotated in the GNU ELF notes section, but it's not required for enablement, as interleaved PAC and non-pac code works as expected since it's the callee that performs all the checking.

Becuase the aarch64 assembly code does not make use of pushing the LR to the stack, only BTI targets were needed to be instrumented and the GNU notes section indicating support for BTU. Thus for PAC the only requirement was to mark the GNU notes section as supporting PAC.

Testing was done under the following CFLAGS:
1. -mbranch-protection=none
2. -mbranch-protection=standard
3. -mbranch-protection=pac-ret
4. -mbranch-protection=pac-ret+b-key
5. -mbranch-protection=bti

<!--
Please write a little about the why and how of this pull request
A mail should automatically get sent to the mpg123-devel mailing list.

Before submitting, please check the following:
- [ ] Set target branch to `master`
- [ ] Write a little text above 
-->


---

patch details:
- url: https://github.com/madebr/mpg123/pull/15
- patch: https://github.com/madebr/mpg123/pull/15.patch

url details:
- user name: billatarm
- user url: https://github.com/billatarm

[mpg123-devel] releasing mpg123 1.32.7

[Thomas O. <tho...@or...>]

Hi there,

mpg123 1.32.7 is coming out, with only some minor hygiene:

1.32.7
------
- ports/cmake: Work around bug in CMake that does not detect FPU on
  Apple ARM CPUs (github PR 14).
- Fix some laziness (func() to func(void)) for standards conformance.

You can get it from https://mpg123.org/download.shtml as usual.


Alrighty then,

Thomas

[mpg123-devel] Opened GH-#14: Fix CMake build on Apple Silicon [madebr]

[<ano...@gm...>]

A pull request by madebr  was opened at 2024-05-01 23:15:10+00:00.

Please visit https://github.com/madebr/mpg123/pull/14 to give feedback and review the code.

---

On Apple silicon, `cmake_host_system_information(RESULT HAVE_FPU QUERY HAS_FPU)` returns `HAVE_FPU=0`.
I reported this [upstream](https://gitlab.kitware.com/cmake/cmake/-/issues/25950).

Without a detected fpu, the build fails when `REAL_IS_FIXED` is defined, and neon is detected.
https://github.com/madebr/mpg123/actions/runs/8916112597/job/24486953667#step:5:13

My fix moves the cpu arch detection earlier, and hard enables `HAVE_FPU` for apple arm64.

As an extra, I added a patch that adds macos CI.

---

patch details:
- url: https://github.com/madebr/mpg123/pull/14
- patch: https://github.com/madebr/mpg123/pull/14.patch

url details:
- user name: madebr
- user url: https://github.com/madebr

[mpg123-devel] Opened GH-#13: Fix typo [basicmaster]

[<ano...@gm...>]

A pull request by basicmaster  was opened at 2024-04-06 10:57:49+00:00.

Please visit https://github.com/madebr/mpg123/pull/13 to give feedback and review the code.

---

Fixes a tiny typo.

---

patch details:
- url: https://github.com/madebr/mpg123/pull/13
- patch: https://github.com/madebr/mpg123/pull/13.patch

url details:
- user name: basicmaster
- user url: https://github.com/basicmaster

[mpg123-devel] mpg123 1.32.6 released (just a build system tweak for better LFS migration on Debian)

[Thomas O. <tho...@or...>]

Dear mpg123 folks,

a little build system tweak arrives in the current mpg123 release.

1.32.6
------
- build: Detect forced 64 bit offsets on a dual-mode system that used
  to default to 32 bits and drop ambiguous suffix-less symbols in that
  case. This avoids subtle ABI breakage (causing memory corruption)
  with existing binaries and instead has them fail during runtime linking.
  You trigger that when having -D_FILE_OFFSET_BITS=64 in your compiler
  flags during mpg123 build.


If this does not mean anything to you … you might just ignore it. No
new features, just less symbols in a library built in an environment
with enforced large file support.



Alrighty then,

Thomas

[mpg123-devel] releasing mpg123 1.32.5

[Thomas O. <tho...@or...>]

Hi folks,

some cleanup comes to you with mpg123 version 1.32.5:

1.32.5
------

- build:
-- CMake port uses CFLAGS for pulse/jack/tinyalsa properly now (bug 366).
-- CMake port links libsyn123 with libm now (bug 370).
- libmpg123:
-- Fix --enable-portable (no usage of LFS_WRAP_NONE, bug 368).
-- Fix dct36 wrapper usage for x86-64 and NEON. Stupid (bug 367) and
   also avoid returning void.
-- Make ARM builds work with nagging (missing feature macros for std=c99).


Grab it if you so desire from

	https://sourceforge.net/projects/mpg123/files/
or
	https://mpg123.org/download.shtml

and have a good time.


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.32.4 released

[Thomas O. <tho...@or...>]

Hi all,

some internal rearrangements and build system enhancements come with
mpg123 1.32.4:

1.32.4
------
- build:
-- Reorganize shared headers, API headers into src/include.
-- Use relative include paths, avoiding internal directories in
   CPPFLAGS except for config.h.
-- Group C99 feature checks and make several standard headers
   mandatory.
-- Get rid of SIZE_P, OFF_P and friends.
-- Only enforce dummy module together with libout123, to be able
   to build individual modules using --disable-components logic.
- out123:
-- added --libversion
- libmpg123:
-- Avoid indirect branches into the assembly routines by using C wrappers
   also for dct36, relieving us of the need to care for bti / endbr
   instructions for control flow integrity.


Get it from the usual places …


Alrighty then,

Thomas

[mpg123-devel] Opened GH-#12: streamdump: use correct dump_close function [JohannesKauffmann]

[<ano...@gm...>]

A pull request by JohannesKauffmann  was opened at 2023-12-29 15:57:53+00:00.

Please visit https://github.com/madebr/mpg123/pull/12 to give feedback and review the code.

---

The function doesn't take a parameter, so don't pass it.

Caught by Clang's -Wdeprecated-non-prototype:
```
../src/streamdump.c:691:13: error: passing arguments to 'dump_close' without a prototype is deprecated in all versions of C and is not supported in C2x [-Werror,-Wdeprecated-non-prototype]
                dump_close(sd);
                          ^
```

---

patch details:
- url: https://github.com/madebr/mpg123/pull/12
- patch: https://github.com/madebr/mpg123/pull/12.patch

url details:
- user name: JohannesKauffmann
- user url: https://github.com/JohannesKauffmann

[mpg123-devel] Opened GH-#11: Allow building with installed mpg syn out libs [i-garrison]

[<ano...@gm...>]

A pull request by i-garrison  was opened at 2023-11-06 15:50:32+00:00.

Please visit https://github.com/madebr/mpg123/pull/11 to give feedback and review the code.

---

Allow building `mpg123` against installed `libmpg123`
- add `programs` component to `configure.ac`
- if building `libmpg123` is not enabled, find and use already installed `libmpg123` package; same for `libsyn123` and `libout123`
- move a few shared internal headers from `src/libmpg123` to `src/include` to fix build against installed `libmpg123` package


---

patch details:
- url: https://github.com/madebr/mpg123/pull/11
- patch: https://github.com/madebr/mpg123/pull/11.patch

url details:
- user name: i-garrison
- user url: https://github.com/i-garrison

[mpg123-devel] mpg123 1.32.3 released

[Thomas O. <tho...@or...>]

The (up to now) final release of the quick regression fix succession of
the 1.32.x series is out. It's a rough ride, but we're getting there.

Maybe we've even arrived.

1.32.3
------
- ports/cmake: Only enable modules with GetThreadErrorMode() on Windows.
- compat: Define EOVERFLOW for ancient Windows toolchains.
- libmpg123, libsyn123: always ifdef LFS_LARGEFILE_64 (not just if)
- libsyn123: re-introduce _32 wrappers in addition to suffix-less ones
  (regression from 1.31, bug 363)


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.32.2 released with build fixes for ABI regression from 1.31

[Thomas O. <tho...@or...>]

Hi all,

please upgrade to mpg123 1.32.2 which yet again fixes things that I
broke with 1.32.0. The CI and pre-release testing that we have is
covering only part of what we got out there. Now we missed the case of
-D_FILE_OFFSET_BITS=64 on 64 bit platforms, where the _64 symbols were
missing.

Also, the CMake build got some important fixes to complete what 1.32.0
should have had.

Pleae just upgrade, for these fixes:

1.32.2
------

- libmpg123: Re-introduce _64 symbols on native 64 bit offset platforms. This
  was a regression since 1.31 series. Sorry, too much cleanup, not enough
  testing.
- build:
-- Better O_LARGEFILE logic, avoiding redefintion.
- ports/cmake:
-- Require C99 (bug 360, among other points, thanks to Ozkan Sezer).
-- Fix broken O_LARGEFILE logic (bug 360).
-- Typo fix and cleanup, also manual SSE switch for Android on old x86 (bug 359).


Alrighty then,

Thomas

[mpg123-devel] mpg123 1.32.1 with build fixes

[Thomas O. <tho...@or...>]

There were some things amiss with the build system changes in the last
release, most notably the man pages went missing. Further fixes mainly
for the CMake build are also still in the works. Sorry for the fuss, but
only the announced release got the testing we'd like to have had beforehand.

1.32.1
------
- Include man pages again in tarball and install. We cannot avoid the empty
  man directory when disabling programs with autoconf.
- Fix signal handler prototype, avoiding some justified warnings.
- ports/cmake:
-- Include CheckTypeSize, which seems to be needed sometimes (bug 357).
-- Avoid O_LARGEFILE redefinition, logic closer to autoconf.


Alrighty then,

Thomas

[mpg123-devel] mpg123 .1.32.0 released

[Thomas O. <tho...@or...>]

Dear people who at least know what mpg123 is,

version 1.32.0 got just released. Major points are the introduction of
yet another API set to yet again fix the largefile support situation,
where you can rely on fixed 64 bit integers instead of touching off_t,
and fixing of the meaning of the offset for mpg123_seek() when working
from the end.

But there is more … please see the full list:

1.32.0
------
- build:
-- Move version handling out of configure.ac to ease other build systems.
-- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the
   correct one is included (at least gcc picks the one in the same directory as the
   including header first).
-- All headers are build-independent now.
-- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not
   used (spurious linker error to non-exitent getcpuflags(), bug 353).
-- Handle deprecation of C99 detection macro in autoconf 2.70.
-- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for
   the libraries and frontend programs.
-- Added --enable-portable and --disable-largefile to configure, removing the other
   largefile-related options.
-- Added --disable-components --enable-libmpg123 to only build libmpg123 (and likewise
   --enable-libout123, --enable-libout123-modules, --enable-libsyn123) to autoconf
   build. CMake build has something  similar with BUILD_PROGRAMS and BUILD_LIBOUT123,
   which leave only libmpg123 and libsyn123 if disabled). (bug 351)
-- Consistent formatting of ./configure --help with AS_HELP_STRING().
- ports/Sony_PSP: removed
- mpg123:
-- Added --libversion.
-- Added proper A-B looping with terminal control key 'o', renamed
   --pauseloop to --presetloop.
-- Really get rid of mpg123_position() usage. (It was all lies before!)
-- Fix terminal progress info when seeking in stopped mode (1.31 regression).
-- Patch up interaction of output buffer with generic remote control, adding
   non-interruptible drain after P 3, and dropping buffer on QUIT.
-- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS,
   MUTE, UNMUTE
- libmpg123, libout123, libsyn123:
-- Bumped API version for version query functions.
-- Replaced nearly all symbol renames with explicit INT123_ prefix declarations
   (intsym.h close to empty now).
- libout123:
-- Add sleep builtin output module (silent, but proper timing).
- libsyn123:
-- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t
   (see NEWS.libsyn123).
- libmpg123:
-- Internal I/O using explicit largefile support via off64_t, lseek64, fallback
   to plain 32 bit off_t.
-- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()).
   This allows full avoidance of ambiguus off_t. The API is always using 64 bit
   integers, regardless of internal implementation. (bug 344)
-- Introduced MPG123_PORTABLE_API for an API subset without off_t and
   ssize_t.
-- Made mpg123_seek() and friends ignore offset sign for SEEK_END (always seeking
   towards beginning, assuming negative offset) to make lseek()-conforming usage
   possible. Seeking beyond the end never made sense, so no loss of valid functionality.
- Overall use of INT123_strerror(), trying to use thread-safe strerror_l() if possible.


Please get it from

	https://sourceforge.net/projects/mpg123/files/mpg123/1.32.0
or
	http://mpg123.org/download.shtml
.


Alrighty then,

Thomas

Re: [mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

[Thomas O. <tho...@or...>]

Second round!

Am Tue, 22 Aug 2023 00:13:23 +0200
schrieb Thomas Orgis <tho...@or...>: 

> TL;DR: Test mpg123 snapshot on your platform and report breakage. Please.

This is now the NEWS scheduled ever closer to a release:

1.32.0
------
- build:
-- Move version handling out of configure.ac to ease other build systems.
-- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the
   correct one is included (at least gcc picks the one in the same directory as the
   including header first).
-- All headers are build-independent now.
-- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not
   used (spurious linker error to non-exitent getcpuflags(), bug 353).
-- Handle deprecation of C99 detection macro in autoconf 2.70.
-- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for
   the libraries and frontend programs.
-- Added --enable-portable and --disable-largefile to configure, removing the other
   largefile-related options.
-- Added --disable-components --enable-libmpg123 to only build libmpg123 (and likewise
   --enable-libout123, --enable-libsyn123) to autoconf build. CMake build has something
   similar with BUILD_PROGRAMS and BUILD_LIBOUT123, which leave only libmpg123 and libsyn123
   if disabled). (bug 351)
-- Consistent formatting of ./configure --help with AS_HELP_STRING().
- ports/Sony_PSP: removed
- mpg123:
-- Added --libversion.
-- Added proper A-B looping with terminal control key 'o', renamed
   --pauseloop to --presetloop.
-- Really get rid of mpg123_position() usage. (It was all lies before!)
-- Fix terminal progress info when seeking in stopped mode (1.31 regression).
-- Patch up interaction of output buffer with generic remote control, adding
   non-interruptible drain after P 3, and dropping buffer on QUIT.
-- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS,
   MUTE, UNMUTE
- libmpg123, libout123, libsyn123: bumped API version for version query
  functions
- libout123:
-- Add sleep builtin output module (silent, but proper timing).
- libsyn123:
-- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t
   (see NEWS.libsyn123).
- libmpg123:
-- Internal I/O using explicit largefile support via off64_t, lseek64, fallback
   to plain 32 bit off_t.
-- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()).
   This allows full avoidance of ambiguus off_t. The API is always using 64 bit
   integers, regardless of internal implementation. (bug 344)
-- Introduced MPG123_PORTABLE_API for an API subset without off_t and
   ssize_t.
-- Made mpg123_seek() and friends ignore offset sign for SEEK_END (always seeking
   towards beginning, assuming negative offset) to make lseek()-conforming usage
   possible. Seeking beyond the end never made sense, so no loss of valid functionality.


There will be bugs, inevitably. The main point is the API changes that
are supposed to stay for further releases: Anyone seeing an issue with those?

Also, if anyone can spinup a current Windows system and test CMake with
MSVC + yasm for assembly … we still got a mysterious build issue
indicated by the git mirror:

	https://github.com/madebr/mpg123/actions/runs/6068446593/job/16461412092

That won't hold off the release, but having those CI actions run
through would be nice.



Alrighty then,

Thomas

Re: [mpg123-devel] Notion of SEEK_END

[Thomas O. <tho...@or...>]

Am Sat, 2 Sep 2023 15:28:01 +0200
schrieb Thomas Orgis <tho...@or...>: 

>   mpg123_seek(mh, 128, SEEK_END)
>   mpg123_seek(mh, -128, SEEK_END)
> 
> could both do the same thing. The latter would've been a error
> with current libmpg123. Turning errors into valid behaviour has
> its risks, but in this case, I think it is sensible.  

May you verify if current trunk (or snapshot) apply this correctly?

See updated https://mpg123.org/api/group__mpg123__seek.shtml .


Alrighty then,

Thomas

Re: [mpg123-devel] Notion of SEEK_END

[Thomas O. <tho...@or...>]

[on-list again, again]

Am 30. August 2023 23:11:34 MESZ schrieb Thomas Brand <to...@tr...>:

>>> Eventually a "seek_compatibility" flag could be introduced.  
>> 
>> This would need to be opt-in, though. We could introduce a flag
>> to fix SEEK_END behaviour. Or we could just document the state as-is
>> and realize that it's a rare case with not much practical impact.
>>   
>it's a hard decision. i don't know what's the best future-proof approach here.
>opt-in sounds good, plus documentation ..  

>> Hm. Returning an error or silently (only by return value) limiting offset
>> to the end. Both may make sense.  

I think it's simple after all. In a read-write library, seeking beyond
the end makes sense. You can write there and enlarge the file.
In a read-only library, only positions within the file make sense.

Current mpg123 inverts the sign of an offset from SEEK_END,
as I thought back then that it would be obvious to mean positive
steps from the end back. Only one direction does make sense.

So, what's the problem if I'd just ignore the sign of the SEEK_END
argument?

  mpg123_seek(mh, 128, SEEK_END)
  mpg123_seek(mh, -128, SEEK_END)

could both do the same thing. The latter would've been a error
with current libmpg123. Turning errors into valid behaviour has
its risks, but in this case, I think it is sensible.  


Alrighty then,

Thomas

Re: [mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

[Thomas O. <tho...@or...>]

Am Tue, 29 Aug 2023 17:04:50 +0000
schrieb Thomas Brand <to...@tr...>: 

> I'm not sure how gapless is related to seek, I couldn't pin it down.

It is related to seek, as it is concerned with exact sample offsets.
Things like

#ifdef GAPLESS
			else if(mh->end_os > 0) pos = SAMPLE_ADJUST(mh,mh->end_os) - sampleoff;
#endif

As only with gapless mode, things like the accurate sample count
including padding from the encoder are considered.

> PS, here the quick & dirty testcode:

You had me wondering for a moment. Non-gapless mode is not tested …
having it as an option stems from the time at that I did this one thing
to mpg123, hack in gapless decoding. This was my addition and I of course
wasn't sure how well it would work out. It was an option. It probably
should not be an option anymore.

To your testcase: Yes, seeking to 10 yields position 0. This is expected
once you realize (or have better documentation indicating) that without
the gapless machinery, libmpg123 seeking simply has no resolution below
MPEG frames. With a normal MP3 file that has 1152 samples per frame, you
should observe this:

#seek_to   result_gapless result_non-gapless
       0                0                   0
      10               10                   0
    1151             1151                   0
    1152             1152                1152

The non-gapless mode can only advance in full MPEG frames. This is what
mpg123 would do before I hacked in the gapless mode.

Now we indeed could discuss if, after all the years, we should get rid
of --disable-gapless.


Alrighty then,

Thomas

Re: [mpg123-devel] Notion of SEEK_END

[Thomas O. <tho...@or...>]

Am Tue, 29 Aug 2023 17:21:23 +0000
schrieb Thomas Brand <to...@tr...>: 

> To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this 
> overshoots by 10 samples (length + 10). On the other hand, seek(10, 
> SEEK_END) will go to 10 samples before the end. I think this notion is 
> inverse to other uses of SEEK_END.

Oh, great. Looking at lseek(2) and at my own documentation in mpg123.h,
the behaviour indeed does not match the description. It's utterly
wrong and you are the first person to notice.

Damn. I have to think hard on how to best handle it. Just correcting
the behaviour would break anyone relying on the existing. At the same
time, precisely because you're the first one noticing, I _guess_ that
you might be the only one trying to seek from the end on MPEG files so
far.

Having the reverse meaning compared to lseek really sucks. I don't have
the solution right now for the next release, just a confirmation that
you're right.


Alrighty then,

Thomas

[mpg123-devel] Notion of SEEK_END

[Thomas B. <to...@tr...>]

Hi, I'm puzzled with mpg123_seek() when using SEEK_END.
To seek 10 samples before the end, I'd seek(-10, SEEK_END), but this 
overshoots by 10 samples (length + 10). On the other hand, seek(10, 
SEEK_END) will go to 10 samples before the end. I think this notion is 
inverse to other uses of SEEK_END. Is it the expected behaviour? Unless 
I haven't overlooked something fundamental and my test is wrong, it 
should eventually be mentioned in the docs.
Greetings
Thomas

Re: [mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

[Thomas B. <to...@tr...>]

On 2023-08-21 22:13, Thomas Orgis wrote:
> TL;DR: Test mpg123 snapshot on your platform and report breakage. 
> Please.
> 
> 
> So, give
> 
> 	https://mpg123.org/snapshot
> 
> a spin. The full list of NEWS scheduled for the upcoming release 
> contains
> some more points:
> 

Hello, I've gave it a spin (x86_64, Linux) and everything looks good so 
far. Only a small set of functions are involved so it might not be 
representative.

Something observed independently and most likely not related to the new 
snapshot is that when compile flag
--enable-gapless=no
is set, then mpg123_seek seems to not work. This also happens with for 
example 1.31.3. The effect is that a mpg123_seek(h, 10, SEEK_SET) will 
return 0.
When --enable-gapless=no is not set, it will return 10, nothing else 
changed.
I'm not sure how gapless is related to seek, I couldn't pin it down.

Greetings
Thomas


PS, here the quick & dirty testcode:
#include <stdio.h>
#include <mpg123.h>
#include <stdint.h>
#include <inttypes.h>

static mpg123_handle* mh;

//=====================================================
int main(int argc, char **argv)
{
	long rate;
	int channels, format, err;
	int64_t offset=10;
	int64_t pos=0;

	mpg123_init();
	mh = mpg123_new(NULL, NULL);
	mpg123_format_none (mh);
	format=mpg123_format(mh
		, 44100
		, MPG123_STEREO
		, MPG123_ENC_FLOAT_32
	);
	err = mpg123_open(mh, argv[1]);
	if(err == MPG123_OK)
	{
		mpg123_getformat(mh, &rate, &channels, &format);

		pos=mpg123_seek(mh,offset,SEEK_SET);
		fprintf(stderr, "seek end return %" PRId64 "\n", pos);

		mpg123_close(mh);
	}
	else{fprintf(stderr, "Failed to open file: %s\n", 
mpg123_strerror(mh));}

	mpg123_exit();
}

./configure
vs
./configure --enable-gapless=no

[mpg123-devel] Please test upcoming mpg123 1.32 (current snapshot or svn trunk)

[Thomas O. <tho...@or...>]

TL;DR: Test mpg123 snapshot on your platform and report breakage. Please.

Dear all,

the lengthy dicussion on bug 344 prompted some hefty rearrangements in the
libmpg123 code and significant changes in the build. We have yet another overhaul
of the largefile support. The primary code path is now formed by API that is
fixed to offsets using int64_t and functions working with off_t (be it 32 bit
or 64 bit) are bolted on top of that. This enables work with large files
regardless of LFS in the libmpg123 build, which may be lacking in case of MSVC
builds that simply don't do 64 bit off_t, by client code providing proper
callbacks to

	mpg123_reader64( mpg123_handle *mh
	,	int (*r_read) (void *, void *, size_t, size_t *)
	,	int64_t (*r_lseek)(void *, int64_t, int)
	,	void (*cleanup)(void*) );

Whatever tricks your platform needs to do proper I/O, you can implement them.
I don't have to care. You can also define the macro MPG123_PORTABLE_API (same
for libsyn123 and syn123.h with SYN123_PORTABLE_API) when including mpg123.h to
skip defining any API that touches off_t (or ssize_t, for that matter).

The library is now built using explicit _LARGEFILE64_SOURCE and lseek64(), if
available. The standard autoconf largefile detection macro is not used anymore.
So it could well be that something needs consideration on platform X. I might
have assumed something that I shouldn't have.

So, give

	https://mpg123.org/snapshot

a spin. The full list of NEWS scheduled for the upcoming release contains
some more points:

1.32.0
------
- build:
-- Move version handling out of configure.ac to ease other build systems.
-- Include "fmt123.h" instead of <fmt123.h> in main API headers to make it more likely the
   correct one is included (at least gcc picks the one in the same directory as the
   including header first).
-- All headers are build-independent now.
-- Fix build for picky linkers by avoiding definition of wrap_getcpuflags() where it is not
   used (spurious linker error to non-exitent getcpuflags(), bug 353).
-- Handle deprecation of C99 detection macro in autoconf 2.70.
-- No use of AC_SYS_LARGEFILE anymore for explicit handling and differing choice for
   the libraries and frontend programs.
-- Added --enable-portable and --disable-largefile to configure, removing the other
   largefile-related options.
- ports/Sony_PSP: removed
- mpg123:
-- Added --libversion.
-- Added proper A-B looping with terminal control key 'o', renamed
   --pauseloop to --presetloop.
-- Really get rid of mpg123_position() usage. (It was all lies before!)
-- Fix terminal progress info when seeking in stopped mode (1.31 regression).
-- Patch up interaction of output buffer with generic remote control, adding
   non-interruptible drain after P 3, and dropping buffer on QUIT.
-- Uppercase some generic control replies for consinstency: SILENCE, PROGRESS,
   MUTE, UNMUTE
- libmpg123, libout123, libsyn123: bumped API version for version query
  functions
- libout123:
-- Add sleep builtin output module (silent, but proper timing).
- libsyn123:
-- Introduced SYN123_PORTABLE_API for an API without off_t and ssize_t
   (see NEWS.libsyn123).
- libmpg123:
-- Internal I/O using explicit largefile support via off64_t, lseek64, fallback
   to plain 32 bit off_t.
-- Added explicit 64 bit API with 64 suffix (mpg123_tell64(), not mpg123_tell_64()).
   This allows full avoidance of ambiguus off_t. The API is always using 64 bit
   integers, regardless of internal implementation. (bug 344)
-- Introduced MPG123_PORTABLE_API for an API subset without off_t and
   ssize_t.


Alrighty then,

Thomas

Re: [mpg123-devel] Question about mpg123_distversion()

[Thomas B. <to...@tr...>]

On 2023-08-06 11:27, Thomas Orgis wrote:
> Am Sun, 06 Aug 2023 10:29:10 +0200
> schrieb Thomas Orgis <tho...@or...>:
> 
>> I'll switch it over to a release branch, or generally have some
>> version info in there. Sorry for the confusion.
> 
> Or … actually … I kindof tried to prevent that confusion by this 
> preface:
> 
> 	Note: This API doc is automatically generated from the current
> 	development version that you can get via Subversion or as a
> 	daily snapshot from http://mpg123.org/snapshot. There may be
> 	differences (additions) compared to the latest stable release.
> 	See NEWS.libmpg123, NEWS.libout123, NEWS.libsyn123, and the
> 	overall NEWS file on libmpg123 versions and important changes
> 	between them.
> 
> I repaired the links to the NEWS files and spend a few minutes on
> adding mpg123 release version info to make them more useful for library
> feature lookup. See
> 
> 	https://mpg123.org/trunk/NEWS.libmpg123
> 
> for an overview of what is available with which mpg123 release. The
> version calls are scheduled for the next release series, 1.32.
> 
> Really nice would be to have a tag on each symbol on which version it
> appeared in. Maybe I'll script that into the doxygen stuff. Somehow I
> like that better than N copies of the documentation.
> 

Thanks for clarifying, it all makes sense now.
Greetings
Thomas

Re: [mpg123-devel] Question about mpg123_distversion()

[Thomas O. <tho...@or...>]

Am Sun, 06 Aug 2023 10:29:10 +0200
schrieb Thomas Orgis <tho...@or...>: 

> I'll switch it over to a release branch, or generally have some
> version info in there. Sorry for the confusion.

Or … actually … I kindof tried to prevent that confusion by this preface:

	Note: This API doc is automatically generated from the current
	development version that you can get via Subversion or as a
	daily snapshot from http://mpg123.org/snapshot. There may be
	differences (additions) compared to the latest stable release.
	See NEWS.libmpg123, NEWS.libout123, NEWS.libsyn123, and the
	overall NEWS file on libmpg123 versions and important changes
	between them.

I repaired the links to the NEWS files and spend a few minutes on
adding mpg123 release version info to make them more useful for library
feature lookup. See

	https://mpg123.org/trunk/NEWS.libmpg123

for an overview of what is available with which mpg123 release. The
version calls are scheduled for the next release series, 1.32.

Really nice would be to have a tag on each symbol on which version it
appeared in. Maybe I'll script that into the doxygen stuff. Somehow I
like that better than N copies of the documentation.


Alrighty then,

Thomas

Re: [mpg123-devel] Question about mpg123_distversion()

[Thomas O. <tho...@or...>]

I see ... the documentation is generated from the svn trunk, not the released version. The current development cycle with lots of API additions (and only intermittend developer time) coming up is dragging along and makes documentation go out of sync for too long.

I'll switch it over to a release branch, or generally have some version info in there. Sorry for the confusion.


Alrighty then,

Thomas

[mpg123-devel] Question about mpg123_distversion()

[Thomas B. <to...@tr...>]

Hello

I'm trying to call mpg123_distversion() and mpg123_libversion() like 
described here:

https://www.mpg123.de/api/group__mpg123__init.shtml#ga24c777432f0d27c07fd265a78647b3f2

fprintf(stderr, "mpg123 distversion: %s\n", mpg123_distversion(NULL, 
NULL, NULL));

But there's an undefined reference error. Grepping on the source tree 
(mpg123-1.31.3) doesn't reveal any matches for either distversion or 
libversion.

I'm missing something, what could be the issue? Thanks for any hints.

Greetings
Thomas