Activity for Thomas Orgis
-
Thomas Orgis posted a comment on ticket #382
Isn't this a major bug in cmake and subprojects should just be avoided unless there is some isolation between them, or at least controlled sharing of variables? Anyhow, I imported the most recent patch. Is current revision 5532 fine for you?
-
Attempting to build results in syntax error
-
mpg123 build failed for the avx assembly files.
-
out123_open uses strtok_r, which is unavailable on MSVC
-
Using libmpg123 to get raw ID3 returns modified data.
-
Building mpg123 using non-legacy CMake toolchain fails
-
This is a weird one. When I download the URL via wget, I get an MPEG stream. When I access via mpg123's old internal http code, I get some HTML reply. If I look at what the redirections that wget gets do … $ wget http://nrj.de/pop --2025-09-18 23:25:28-- http://nrj.de/pop Resolviendo nrj.de (nrj.de)... 157.90.170.233 Conectando con nrj.de (nrj.de)[157.90.170.233]:80... conectado. Petición HTTP enviada, esperando respuesta... 301 Moved Permanently Ubicación: https://frontend.streamonkey.net/energy-pop/stream/mp3?aggregator=shorty...
-
How's the current trunk for both?
-
Am Wed, 10 Sep 2025 14:19:19 -0000 schrieb "Maarten" pacha2087@users.sourceforge.net: -.data +#ifndef APPLE + .section .rodata +#else + .data +#endif Yeah … I guess we probably should define a macro #ifndef __APPLE__ #define RODATA .section .rodata #else #define RODATA .data #endif and use that everywhere?
-
Am Wed, 10 Sep 2025 14:18:39 -0000 schrieb "Maarten" pacha2087@users.sourceforge.net: // Apple and Android NDK seem both not to like direct global access. -#if defined(PIC) && (defined(APPLE) || defined(ANDROID)) +#if defined(PIC) && (defined(APPLE) || defined(ANDROID)) #define PIC_GLOBAL_PTR #endif So our resolution of bug #345 was fauly in putting ANDROID in there? Or rather, this used to be defined and now only ANDROID is?
-
It was a bad idea to begin with, messing with the bytes like that. I now took the step to change the internal parser API to pass the encoding separately, removing the need for the byte abusal. Revision 5520 contains the fix. The snapshot being generated before 03:00 CEST tonight will contain this. Can you confirm the fix?
-
Oh, right, you beat me to it. I even wrote a very explicit comment about abusing a byte.
-
Indeed. I did not spot the line yet, but something in the parser does modify the buffer. If you also set mpg123_param(mh, MPG123_ADD_FLAGS, MPG123_SKIP_ID3V2, 0); to disable the parsing itself (which makes sense if you are interested in the raw frame data), the contents are unchanged. Likely the parser modifying the data only started being a bug once we added the feature of keeping the RAW data
-
Can you try the same with current svn trunk? I added code that should give you a clearer error message (the error being missing pkg-config at autoreconf).
-
This happens whem you don't have JACK development files installed. No issue with running configure, but when generating it. (Edit: This was not supposed to be in bold, stupid sf.net markup) It's an annoyance, yes. Maybe we can change JACK detection not to depend on that macro. But for now, just install libjack-dev, jack-devel or similar package from your distribution. (Edit: removed mail signature … mail responses are a nice feature, but too bad that it's broken here.)
-
Ah, yes. It is about not having pkg-config installed when running autoreconf. Then all invokations of PKG_CHECK_MODULES stay in the configure script and the first one encountered causes this error. Seems to be a well-known and lamented issue that for some reason is not handled better. I wonder if I can do something to cause an error at autoconf time instead. Someone must have figured this out already, digging around a bit
-
Actually … I can't reproduce this right now. I remember such an issue, though. What did you do, exactly? Which download or repo checkout, which exact autoreconf invocation?
-
This happens whem you don't have JACK development files installed. No issue with running configure, but when generating it. It's an annoyance, yes. Maybe we can change JACK detection not to depend on that macro. But for now, just install libjack-dev, jack-devel or similar package from your distribution. sent from mobile device, trustworthy or not
-
Yeah, except I don't find a declaration of putenv, let alone use of it in our sources. This is in files that start with /* src/.libs/lt-mpg123-strip.c - temporary wrapper executable for .libs/mpg123-strip.exe Generated by libtool (GNU libtool) 2.4.6 Debian-2.4.6-15build2 The src/mpg123-strip program cannot be directly executed until all the libtool libraries that it depends on are installed. This wrapper executable should never be moved out of the build directory. If it is, it will not operate correctly....
-
@Pali: During testing the changes, can you give some hint on that error cross-compiling with mingw-w64 on Linux? /bin/bash ./libtool --tag=CC --mode=link i686-w64-mingw32-gcc -O2 -fomit-frame-pointer -funroll-all-loops -finline-functions -ffast-math -Wall -Werror -std=c99 -pedantic -g -O2 -o src/mpg123.exe src/audio.o src/common.o src/sysutil.o src/control_generic.o src/equalizer.o src/getlopt.o src/httpget.o src/resolver.o src/genre.o src/mpg123.o src/metaprint.o src/local.o src/playlist.o src/streamdump.o...
-
Another update: I'm aiming at the small-scale return value handling now. The restructuring with wmain poses more questions and we lost our Windows maintainer over the somewhat heated discussions.
-
I committed the above now. Idea is to ship with 1.33.0. Edit: Using CCASFLAGS instead of CFLAGS
-
I committed the above now. Idea is to ship with 1.33.0.
-
Note: release 1.33.0 should ship with the fix.
-
So I guess something like Index: configure.ac =================================================================== --- configure.ac (revisión: 5475) +++ configure.ac (copia de trabajo) @@ -1209,7 +1209,7 @@ # extended to use balign if present AC_MSG_CHECKING([if .balign is present]) echo '.balign 4' > conftest.s -if $CCAS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then +if $CCAS $CFLAGS -c -o conftest.o conftest.s 1>/dev/null 2>&1; then AC_MSG_RESULT([yes]) AC_DEFINE(ASMALIGN_BALIGN, 1, [ Define...
-
Regarding the cross compiler setup with/without CFLAGS, I am used to cross build setups where the toolchain carries that in the name, like arm-linux-gnueabihf-gcc … that will be the CC being used and it does not need options to activate target instruction suppot Edit: Same for arm-linux-gnueabihf-as, of course.
-
Regarding the cross compiler setup with/without CFLAGS, I am used to cross build setups where the toolchain carries that in the name, like arm-linux-gnueabihf-gcc … that will be the CC being used and it does not need options to activate target instruction suppot
-
Clarification about intsym.h: This is gone with mpg123 1.32. It used tp be present in src/. gcc -E -I. -I/Users/jenkins/workspace/cci_prod_PR-26381/conan-home/p/b/mpg1248a9c0de2a75d/b/src -I./src -DASMALIGN_BALIGN /Users/jenkins/workspace/cci_prod_PR-26381/conan-home/p/b/mpg1248a9c0de2a75d/b/src/src/libmpg123/dct36_avx.S | yasm - -pgas -rgas -mamd64 -f macho -o src/libmpg123/dct36_avx.o So the -I options pointing to your in/out of tree src should do the trick to locate it. Why not? Can you test that...
-
OK, the other way round. My head is not in good shape right now. Would it workkwhen the check is saying 'yes' for CCAS AVX support? I am puzzled myself how the intsym.h location crops up. I don't know if I'll have time to look into this on the weekend
-
Are you trying to build AVX for armv8 arch? No wonder that the compiler does not support it. Or am I grossly misreading the github issue? sent from mobile device, trustworthy or not
-
I removed the redundant workflow now. Ozkan: is the combined workflow missing something?
-
OK, I should have fixed the strtok_r usage (now detecting and on MSVC hopefully using strtok_s) with revision 5474 and merged .github changes with 5475. Maybe you can confirm if things are right now
-
Just an update: We are intending to move away from wgetmainargs, and rather switch to setting UNICODE mode and using wmain for that case. It'll take some weeks because of holiday season.
-
weird warning when building against ARM64EC UCRT
-
"unresolved external symbol mpg123_open" when installing from vcpkg
-
Yeah, I decided on UTF-8 internal representation, also in the library APIs, as one universal choice. Of course this comes from POSIX environments, where the upgrade path from 8 bit encodings via UTF-8 is the great cheap trick. Though, jumping to 16 bit wchar_t might also be considered a cheap trick, but a trick that failed once we had to move beyond UCS-2 into UTF-16, where you still have to deal with all the complexity of codepoint-vs-encoding-units … I do have to wonder how much the mpg123 application...
-
World, are you kidding me? You cannot win. So we need to check for strtok_r() and fall back if not there? Or rather … strtok_s() for Windows, strtok_r() for others? Relying on thread-local storage is not quite enough, so it needs to be a safer variant.
-
Seems like a pretty mess. Maybe https://manx.datengang.de/temp/wmain-v5.patch is a better route. But in practice, we are talking of a very rare error case where we run out of memory processing command line arguments. How likely is it that the program will not crash shortly after that, anyway? But of course early crashing/error exit is preferrable. I look at the further UTF-8 conversion calls and think that we need to handle failure there better when worrying about wgetmainargs.
-
"unresolved external symbol mpg123_open" when installing from vcpkg
-
May you test if the snapshot https://mpg123.org/snapshot/mpg123-1.32.10-dev+20241210193333.tar.bz2 works for you? Without the patches vcpkg added now? I'd intend to release that as 1.32.10 soon.
-
Copying my reply to the vcpkg issue: Yes … the MPG123_EXPORT switchery. I need to recap that myself. Right from the top: How important is __declspec(dllimport) for a client build, anyway? The mpg123 headers define MPG123_BUILD_DLL and MPG123_LINK_DLL accordingly for library and client code (common/abi_align.h, src/mpg123app.h and individual sources). Does the client code that misses the symbols actually define MPG123_LINK_DLL to get the dllimport? I guess we should put a platform check into mpg123.h...
-
Copying my reply to the vcpkg issue: Yes … the MPG123_EXPORT switchery. I need to recap that myself. Right from the top: How important is __declspec(dllimport) for a client build, anyway? The mpg123 headers define MPG123_BUILD_DLL and MPG123_LINK_DLL accordingly for library and client code (common/abi_align.h, src/mpg123app.h and individual sources). Does the client code that misses the symbols actually define MPG123_LINK_DLL to get the dllimport? I guess we should put a platform check into mpg123.h...
-
You're not just running a PORTABLE_API build. Using that gives you 116 symbols lin libmpg123 (with autoconf and cmake on Linux, though the cmake build is buggy in that it also exports the INT123_ symbols). You got 130. This is something in between. Edit: Nope. Suffixes should not matter for MSVC! I wonder how the business with MPG123_EXPORT works out, which seems to conflict with the idea of providing functions with and without _64 suffix, or _32 suffix, for that matter. All in all, we recently added...
-
You're not just running a PORTABLE_API build. Using that gives you 116 symbols lin libmpg123 (with autoconf and cmake on Linux, though the cmake build is buggy in that it also exports the INT123_ symbols). You got 130. This is something in between. I wonder how the business with MPG123_EXPORT works out, which seems to conflict with the idea of providing functions with and without _64 suffix, or _32 suffix, for that matter. All in all, we recently added real 64 bit offset support to the MSVC builds...
-
And what about trying the current version? It has build changes vor msvc... Am 22. November 2024 12:30:09 MEZ schrieb Martin c0rn3j@users.sourceforge.net: And what about hat FPU patch? Always force FPU on when cross compiling? Doesn't sound right. It conflicts on the older version, so I just removed it. Where is MPG123_PORTABLE_API defined? I don't see it in No idea, couldn't find it either, might not even be the issue, but the older version works for some reason. [bugs:#374] "unresolved external...
-
Where is MPG123_PORTABLE_API defined? I don't see it in https://github.com/microsoft/vcpkg/blob/master/ports/mpg123/portfile.cmake Yes, with portable API, you don't have mpg123_open varants at all. No file I/O. If you want that, you should push for upgrading to 1.23.9 in vcpgk, anyway, as that enables 64 bit offsets with MSVC. And what about hat FPU patch? Always force FPU on when cross compiling? Doesn't sound right.
-
OK, applied. But we indeed should not spend too much work on platforms we don't really test.
-
OK, like that in trunk? We didn't discuss much the switch from WIN32 to the more specific compiler identities. You think that's safer and some other runtime that doesn't define UCRT will also not share its peculiarities?
-
OK. Committed … with a bit of tweaking on top (attached). Does this work fine for you?
-
Is there no extra flag needed to make _open() open the file in 64 bit mode?
-
Without yet having looked at the patch (just read your message in the train), I want to make more clear what I meant: I was talking about _lseeki64() and some kind of off64_t usage in lfs_wrap.c only. This is the one place that implements seeks for any public API. Looking again … indeed, there should be no need to define any off64_t on MSVC. There is public 32 bit ABI with off_t, mapping to the _32 functions in lfs_wrap.c. All further code paths use int64_t internally to pass things around. We just...
-
Without yet having looked at the patch (just read your message in the train), I want to make more clear what I meant: I was talking about _lseeki64() and some kind of off64_T usage in lfs_wrap.c only. This is the one place that implements seeks for any public API. Looking again … indeed, there should be no need to define any off64_t on MSVC. There is public 32 bit ABI with off_t, mapping to the _32 functions in lfs_wrap.c. All further code paths use int64_t internally to pass things around. We just...
-
Well, messing up use of plain lseek counts as part of the same game to me. But let's get down to the technical. We're only talking about this code, right? static int64_t internal_lseek64(void *handle, int64_t offset, int whence) { struct wrap_data* ioh = handle; #ifdef LFS_LARGEFILE_64 return lseek64(ioh->fd, offset, whence); #else if(offset < OFF_MIN || offset > OFF_MAX) { errno = EOVERFLOW; return -1; } return lseek(ioh->fd, (off_t)offset, whence); #endif } With the corollary of off64_t being a...
-
Well, messing up use of plain lseek counts as part of the same game to me. But let's get down to the technical. We're only talking about this code, right? static int64_t internal_lseek64(void *handle, int64_t offset, int whence) { struct wrap_data* ioh = handle; #ifdef LFS_LARGEFILE_64 return lseek64(ioh->fd, offset, whence); #else if(offset < OFF_MIN || offset > OFF_MAX) { errno = EOVERFLOW; return -1; } return lseek(ioh->fd, (off_t)offset, whence); #endif } With the corrolary of off64_t being a...
-
Well, messing up use of plain lseek counts as part of the same game to me. But let's get down to the technical. We're only talking about his code, right? static int64_t internal_lseek64(void *handle, int64_t offset, int whence) { struct wrap_data* ioh = handle; #ifdef LFS_LARGEFILE_64 return lseek64(ioh->fd, offset, whence); #else if(offset < OFF_MIN || offset > OFF_MAX) { errno = EOVERFLOW; return -1; } return lseek(ioh->fd, (off_t)offset, whence); #endif } With the corrolary of off64_t being a...
-
What about building with --enable-portable? You only need decoding, not file I/O? Im kinda sick of this political game of Microsoft, suggesting the POSIX names are in conflict with ISO C. -- sent from mobile device, trustworthy or not
-
Option Missing in the Help Document
-
It's even mentioned in the man page. Fixed this with 1.32.8. Thanks for the pointer.
-
aarch64 assembler files are missing PAC/BTI flags
-
heap-buffer-overflow in mpg123 at src/libmpg123/synth_mono.h:39
-
1.32.8 is out
-
We added minimal ARM PAC/BTI changes now, scheduled or 1.32.8.
-
Great, thanks. I'll release the fix after this round of testing.
-
I did a more thourough fix now for this and similar bugs. Main point: separate header parsing and decoder structure update. Sounds simple, but wasn't as relevant when the code initially was written, before mpg123 even supported decoding streams with varying properties (concatenated files in the best case, exploits in the worst). Can you check the current revision 5433 / https://mpg123.org/snapshot ? I'll plan to make this a release 1.32.8 soon.
-
heap-buffer-overflow in mpg123 at src/libmpg123/synth_mono.h:39
-
Please try revision 5432 / https://mpg123.org/snapshot just being generated. Maybe a better fix has to be devised, but this one seems to catch this particular confusion of parsed header state and actual frame to decode.
-
End of media output in remote mode
-
According to https://developer.arm.com/documentation/101754/0616/armclang-Reference/armclang-Command-line-Options/-mbranch-protection this build I did on my ARMv8.2 phone should enable BTI: CFLAGS='-Os -mbranch-protection=bti -march=armv8-a" ./configure --with-optimization=0 --enable-nagging make I don't see any issue being reported. It do see linker warnings at runtime regarding unused DT entry that may be related to the alluded no-ops on this older CPU ... those warnings are only in libout123 and...
-
(With instructiuons, I mean including tool calls to verify if a binary has branch protection enabled or not … my memory is rusty….)
-
aarch64 assembler files are missing PAC/BTI flags
-
I was busy with this BTI stuff before and figured that, at least for x86-64, all is well by just ensuring that the assembly is not called via indirect branching (aka function pointers). When resarching the issue back then, I came to the conclusion that wrapping all calls to the assembly into C functions that then get all compiler ornamentation for BTI and whatnot enables the compiler hardening without having to mess with the assembly files yet again (like with executable stack before). Can you give...
-
Erroneous `-D-I/usr/include` added via the CMake buildsystem port
-
was fixed in 1.32.5
-
aarch64 assembler files are missing PAC/BTI flags
-
Closing for now … I built using clang and branch protection in termux on an Android aarch64 device. It only complained about some prototype-less functions that I'll also fix, but nothing about it still wanting landing pads for the wrapped assembly.
-
Build fail with portable mode
-
[PATCH] [Cmake] link libsyn123 with -lm (for exp())
-
warning in readers.c with debugging enabled
-
Ok, been a long time. Stuff happened in real life. I finally integrated this. Thanks (though: gcc 11.4 saw no issue with this).
-
Documentation fix for mpg123_volume_change_db
-
The point is that there are no indirect branches into the asm code anymore and hence no landing pads needed. At least that seems to fix things on x86. Is that different on arm? Is there an actual issue left, or do you just want those instructions there for themselves? sent from mobile device, trustworthy or not
-
I settled the build issue (std=c99 surfaced missing defines in the getcpuflags code for siglongjmp stuff. I'll close this, assuming things are fine now after the correction to use the wrappers.
-
You're building --with-cpu=aarch64? Choosing plain neon64 would not use a wrapper, but … neon64) ADD_CPPFLAGS="$ADD_CPPFLAGS -DOPT_NEON64 -DREAL_IS_FLOAT" more_sources="$s_neon64" ;; aarch64) ADD_CPPFLAGS="$ADD_CPPFLAGS -DOPT_MULTI -DOPT_GENERIC -DOPT_GENERIC_DITHER -DOPT_NEON64 -DREAL_IS_FLOAT" more_sources="$s_neon64 $s_dither $s_arm_multi" ;; So this is a multi build that should use the wrapper. And … oh … dear … what stupid thing: I simply didn't complete the wrapper usage in INT123_dct36_choose()....
-
missing symbol INT123_dct36_sse_wrap when configured with --with-cpu=sse_alone
-
Yeah, confirmed. I included libm now in current svn trunk. Thanks.
-
(sorry)
-
Yes, I reverted that change. The indirect branch on aarch64 is the bogus thing here. No OPT_THE_DCT36 and thus no wrappers for single optimizations.
-
Wait, this is warped. We should not need the wrappers without OPT_MULTI. There should be no indirect banches. On other platforms, this issue does not arise as we do not call into asm via function pointers. Can you be more specific as to which assembly function is to blame? Where is the indirect branch? Or is the linker just doing this blindly?
-
Yeah, that was stupid of me. Please check current trunk or https://mpg123.org/snapshot . I should release 1.32.5 shortly.
-
So you have OPT_NEON64 defined so that the wrapper function is created, but it's not assigned to fr->cpu.opts.the_dct36 later on in layer3.c? Oh, of course. The case without OPT_MULTI didn't use the wrappers yet. Please check current https://mpg123.org/snapshot (or svn trunk).
-
Wich exact version are you referring to and which assembler function, specifically? I hoped to have that issue avoided via this change noted in NEWS for 1.32.4: 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.
-
Oh, darn. Did I miss that for the current release? I fixed in svn now, thanks.
-
command-line argument -b causes current track output to be invalid
-
cmake build fixes, mostly related to O_LARGEFILE redefinition
-
You're right. That's wrong for all modules covered there.
-
Oh, I just realized that I did 'fix' that behaviour in the meantime. With 1.29.3 (Ubuntu 22.04) you already have buffer draining after each song. This has the effect of the new track info only appearing once the new track starts. If you want absolutely no pause between tracks, you can give --smooth to avoid the draining. This has the downside of restoring the early printout of track info. But you can choose: Properly timed information or absolutely smooth playback. The use of --index is probably...
-
Pulseaudio? There's (or was) a bug in the ALSA wrapper that results in static noise at stream beginning (or interruption). Maybe -o pulse to use pulse directly fixes it in this case.
-
Regardless of fixing the display issue or not ... for your case --index might do the trick. It should fill the filesystem cache with the track, in exchange for a small pause beween tracks. But for typical file sizes, this should be really small.
-
True. The positiion info takes that somewhat into account, but mpg123 prints new track info as it appears from the decoder. It's not cached in the player. The decoder library moved on to the next track while the buffer still plays the old one. Considering that this has been that way for rather many years, since the buffer first entered, we might call it a feature request to do otherwise. It can be done, but people weren't bothered enough by the current state yet. What is your use case for the buffer,...
-
ABI break in 1.32.2 compared to 1.31.x
1 >
