mpg123-devel Mailing List for mpg123 (Page 5)
Brought to you by:
sobukus
Menu
▾
▴
mpg123-devel — Mailing list for mpg123 developers
You can subscribe to this list here.
| 2006 |
Jan
(2) |
Feb
(2) |
Mar
(3) |
Apr
|
May
|
Jun
(6) |
Jul
(4) |
Aug
(17) |
Sep
(2) |
Oct
(13) |
Nov
|
Dec
(6) |
|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 2007 |
Jan
(2) |
Feb
(1) |
Mar
(2) |
Apr
(1) |
May
(2) |
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(6) |
Oct
|
Nov
(7) |
Dec
(6) |
| 2008 |
Jan
(1) |
Feb
(2) |
Mar
(3) |
Apr
(18) |
May
(16) |
Jun
(10) |
Jul
(13) |
Aug
(14) |
Sep
(12) |
Oct
(32) |
Nov
(12) |
Dec
(33) |
| 2009 |
Jan
(2) |
Feb
(10) |
Mar
(16) |
Apr
(48) |
May
(92) |
Jun
(68) |
Jul
(37) |
Aug
(28) |
Sep
(61) |
Oct
(43) |
Nov
(33) |
Dec
(48) |
| 2010 |
Jan
(8) |
Feb
(27) |
Mar
(16) |
Apr
(11) |
May
(34) |
Jun
(27) |
Jul
(15) |
Aug
(16) |
Sep
(24) |
Oct
(14) |
Nov
(17) |
Dec
(9) |
| 2011 |
Jan
(21) |
Feb
(12) |
Mar
(8) |
Apr
(33) |
May
(2) |
Jun
(29) |
Jul
(16) |
Aug
(27) |
Sep
(27) |
Oct
(11) |
Nov
(16) |
Dec
(4) |
| 2012 |
Jan
(40) |
Feb
(12) |
Mar
(40) |
Apr
(34) |
May
(32) |
Jun
(6) |
Jul
(7) |
Aug
(13) |
Sep
(8) |
Oct
(12) |
Nov
(14) |
Dec
(5) |
| 2013 |
Jan
(3) |
Feb
(19) |
Mar
(2) |
Apr
(7) |
May
(30) |
Jun
(1) |
Jul
(1) |
Aug
|
Sep
(23) |
Oct
(8) |
Nov
(3) |
Dec
(1) |
| 2014 |
Jan
(2) |
Feb
(2) |
Mar
(1) |
Apr
(9) |
May
(8) |
Jun
(2) |
Jul
|
Aug
(15) |
Sep
(7) |
Oct
(1) |
Nov
(5) |
Dec
|
| 2015 |
Jan
|
Feb
(1) |
Mar
|
Apr
(1) |
May
(1) |
Jun
|
Jul
(13) |
Aug
(16) |
Sep
(26) |
Oct
(2) |
Nov
(5) |
Dec
|
| 2016 |
Jan
(13) |
Feb
(2) |
Mar
(1) |
Apr
(2) |
May
(16) |
Jun
(2) |
Jul
|
Aug
|
Sep
(2) |
Oct
|
Nov
(2) |
Dec
|
| 2017 |
Jan
(11) |
Feb
(10) |
Mar
(6) |
Apr
(4) |
May
(3) |
Jun
|
Jul
(8) |
Aug
(4) |
Sep
(2) |
Oct
|
Nov
|
Dec
(11) |
| 2018 |
Jan
(8) |
Feb
(16) |
Mar
(6) |
Apr
|
May
(3) |
Jun
|
Jul
|
Aug
|
Sep
(8) |
Oct
(5) |
Nov
|
Dec
|
| 2019 |
Jan
|
Feb
|
Mar
|
Apr
(4) |
May
|
Jun
|
Jul
(3) |
Aug
(1) |
Sep
(3) |
Oct
(2) |
Nov
(10) |
Dec
(1) |
| 2020 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
(13) |
Jun
(9) |
Jul
(2) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
(1) |
| 2021 |
Jan
|
Feb
|
Mar
(3) |
Apr
(12) |
May
(4) |
Jun
(12) |
Jul
(2) |
Aug
|
Sep
(1) |
Oct
(4) |
Nov
(2) |
Dec
(1) |
| 2022 |
Jan
|
Feb
|
Mar
|
Apr
(3) |
May
(68) |
Jun
(1) |
Jul
(1) |
Aug
(1) |
Sep
(9) |
Oct
(7) |
Nov
|
Dec
|
| 2023 |
Jan
(7) |
Feb
|
Mar
(1) |
Apr
|
May
|
Jun
|
Jul
(7) |
Aug
(11) |
Sep
(6) |
Oct
(1) |
Nov
(1) |
Dec
(1) |
| 2024 |
Jan
(1) |
Feb
(1) |
Mar
|
Apr
(2) |
May
(1) |
Jun
|
Jul
|
Aug
(1) |
Sep
(2) |
Oct
(2) |
Nov
(1) |
Dec
(2) |
| 2025 |
Jan
(2) |
Feb
|
Mar
|
Apr
|
May
|
Jun
(1) |
Jul
(1) |
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
|
From: Thomas O. <tho...@or...> - 2022-05-15 16:59:25
|
So should we go for klibc so that we know what we're dealing with? Should we care about OS/2 without klibc? I'm torn between enforcing klibc and keeping mpg123 code rather ignorant about this and mostly relying on detected API. We can test for the screen size function, for example. But let's first settle how reading keys is supposed to work (again). Right now, we switched to ctermid() with fallback to /dev/tty ... is that a thing on OS/2? Does only reading from stdin work? Alrighty then, Thomas |
|
From: Dave Y. <dav...@gm...> - 2022-05-15 15:51:40
|
On 05/14/22 10:39 PM, Thomas Orgis wrote: > … but under __EMX__ ifdef. So is EMX still present or not? I guess we > need a writeup of the discussion so far … You can think of current libc as an update to EMX with most of the EMX functions still there along with the EMX GCC options and the EMX toolchain. Basically IBM needed an up to date compiler to build Mozilla and didn't like the EMX GPL libc so paid for the libc to be rewritten along with GCC updated. The rewrite did remove some functionality like DOS support So EMX functions like _scrsize and _wildcard are still in libc and usually an old EMX program will recompile with no changes or minimal changes like the old mpg123 I recompiled. As for guards, code under __OS2__ should compile with any OS/2 compiler, code under __EMX__ needs GCC + EMX or kLIBC and if using newer functions in current libc, there is __KLIBC__. Dave |
|
From: Thomas O. <tho...@or...> - 2022-05-15 05:40:16
|
Am Sun, 15 May 2022 07:28:48 +0200
schrieb Thomas Orgis <tho...@or...>:
> So, the question now is if we can extend that to reading a single key from the terminal.
>
> Does your code work? It should be apparent in the compact tag info printout with fields sharing a line. Or you just add a printf in term_width().
>
> What is nagging me: It did work with the previous posix code. You did get the error about terminal attributes before (e.g. with 1.29.3), right? That means the width detection did work, just not the proper setup.
In fact, we did exactly what you propose now …
int term_width(int fd)
{
#ifdef __EMX__
/* OS/2 */
int s[2];
_scrsize (s);
if (s[0] >= 0)
return s[0];
#else
… but under __EMX__ ifdef. So is EMX still present or not? I guess we
need a writeup of the discussion so far …
Alrighty then,
Thomas
|
|
From: Thomas O. <tho...@or...> - 2022-05-15 05:30:01
|
So, the question now is if we can extend that to reading a single key from the terminal. Does your code work? It should be apparent in the compact tag info printout with fields sharing a line. Or you just add a printf in term_width(). What is nagging me: It did work with the previous posix code. You did get the error about terminal attributes before (e.g. with 1.29.3), right? That means the width detection did work, just not the proper setup. Alrighty then, Thomas |
|
From: Dave Y. <dav...@gm...> - 2022-05-15 04:23:36
|
On 05/14/22 09:57 AM, Thomas Orgis wrote:
> PS: A bit of cleanup happened … mainly to make TERM_NONE work.
> PPS: And no … src/term_win32 will look quite different from OS/2, I
> presume. But what do I know? You can have a look at how it's developing
> and tell if you see resemblance to known API.
OK, the OS/2 API is VioGetMode() which is actually still 16 bit.
Googling for examples gave Windows examples, IIRC GetMode(). Windows
often uses the same API with the prefix dropped.
Hunting through my various sources I found an example in libc, where the
16 bit limitations were taken care of and we get, from the EMX
documentation,
Headers:
#include <stdlib.h>
Prototype:
void _scrsize (int *dst);
Compatibility:
emx
Description:
Retrieve the screen (window) size. The number of text columns (width) is
stored to dst[0], the number of text rows (height) is stored to dst[1].
See also: v_dimen()
This seems to work, probably needs work as I'm not a programmer,
#ifndef __OS2__
int term_width(int fd)
{
struct winsize geometry;
geometry.ws_col = 0;
if(ioctl(fd, TIOCGWINSZ, &geometry) >= 0)
return (int)geometry.ws_col;
return -1;
}
#else
int term_width(int fd)
{
int dst[1];
void _scrsize (int *dst);
return dst[0];
}
#endif
Thanks,
Dave
|
|
From: Dave Y. <dav...@gm...> - 2022-05-14 17:27:19
|
On 05/14/22 09:57 AM, Thomas Orgis wrote: > Am Sat, 14 May 2022 08:28:20 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> On 05/14/22 07:59 AM, Thomas Orgis wrote: >>> Ah, that's the ultra-recent changes prompted by our discussion. We >>> need to re-insert some header into term_posix.c. > > Eh … we had it before? sys/ioctl.h is included. Hm. It used to work, > no? Where did TIOCGWINSZ go? It should be contained in > > #include <termios.h> > #include <sys/ioctl.h> > > or not? Can you grep around in your system where it is hidden? Doesn't seem to exist, I could have sworn it was in EMX but I don't see it there either. OK, the only place is in the old XFree86 source code and that's for ptty's rather then tty's. >> >> Looking at historical versions of mpg123, I had to go back to mpg123 >> 0.20 to find one with working terminal control and source. > > Wait, what? You got version 0.20 of mpg123? Or is that a typo? My > history starts later. Care to share? Seems bad versioning and actually version 0.59m+, H:\tmp\mpg123_020>mpg123.exe High Performance MPEG 1.0/2.0 Audio Player for Layer 1, 2 and 3. Version 0.59m+ (1997/10/07). Written and copyrights by Michael Hipp. Uses code from various people. See 'README' for more! THIS SOFTWARE COMES WITH ABSOLUTELY NO WARRANTY! USE AT YOUR OWN RISK! Modified and ported to OS/2 by Samuel Audet <gu...@ca...> (C) 1998 v0.20 https://www.os2site.com/sw/mmedia/mp3/player/mpg123_020.zip > > > Alrighty then, > > Thomas > > PS: A bit of cleanup happened … mainly to make TERM_NONE work. > PPS: And no … src/term_win32 will look quite different from OS/2, I > presume. But what do I know? You can have a look at how it's developing > and tell if you see resemblance to known API. > OK, I'll look more this evening and also ask around for how to get the terminal width. Wife is tapping her feet waiting to go out :) Dave |
|
From: Thomas O. <tho...@or...> - 2022-05-14 16:58:10
|
Am Sat, 14 May 2022 08:28:20 -0700 schrieb Dave Yeo <dav...@gm...>: > On 05/14/22 07:59 AM, Thomas Orgis wrote: > > Ah, that's the ultra-recent changes prompted by our discussion. We > > need to re-insert some header into term_posix.c. Eh … we had it before? sys/ioctl.h is included. Hm. It used to work, no? Where did TIOCGWINSZ go? It should be contained in #include <termios.h> #include <sys/ioctl.h> or not? Can you grep around in your system where it is hidden? > > Looking at historical versions of mpg123, I had to go back to mpg123 > 0.20 to find one with working terminal control and source. Wait, what? You got version 0.20 of mpg123? Or is that a typo? My history starts later. Care to share? Alrighty then, Thomas PS: A bit of cleanup happened … mainly to make TERM_NONE work. PPS: And no … src/term_win32 will look quite different from OS/2, I presume. But what do I know? You can have a look at how it's developing and tell if you see resemblance to known API. |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 15:28:31
|
On 05/14/22 07:59 AM, Thomas Orgis wrote: > Ah, that's the ultra-recent changes prompted by our discussion. We need to re-insert some header into term_posix.c. > > Will take some time until I can have a go again. Do you manage? I think we had it in this very discussion thread, perhaps. > Looking at historical versions of mpg123, I had to go back to mpg123 0.20 to find one with working terminal control and source. Rebuilt it with current libc and GCC, needing to remove internal strndup and adjust the makefile to use the toolkit version of os2me.h and mmpm.lib and terminal control still works. I'll stare at it more and try to figure out how it works there. Dave |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 15:23:31
|
On 05/13/22 11:59 PM, Thomas Orgis wrote: > Am Fri, 13 May 2022 23:35:23 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> As far as I know, all OS/2 compilers define __OS2__, so would be fine. > >> No, EMX is likely to outdated to compile MPG123 without a lot of work, > > So I'll switch all ifdefs to __OS2__ and will drop the EMX bits. Less > cruft. OK > >> Actually I hadn't used terminal control previously. Now adding -v to the >> command line, I get this message, >> Terminal control enabled, press 'h' for listing of keys and functions. > > OK … so getting the window size works. > >> but 'h' nor any other key besides CTRL-C does anything and displays on >> the command line after mpg123 exits. Never noticed before. > > Better try without -v (less obscuring). So you press a key and it > appears after mpg123 ends? No reaction … hm. Ah, of course. Would > things suddenly happen if you didn't press 'h', but 'h' + 'return'? The return gets buffered as well. > > We switch the terminal into non-canonical mode, which also turns off > line buffering, using tcsetattr. I wonder: Does OS/2 implement > cfmakeraw(), perhaps? That one could be used instead. You could > experiment in src/term.c, in No sign of it in the headers, I'd never heard of cfmakeraw() before. > > void term_init(void) > > Instead of calling tcgetattr() and term_setup(), OS/2 could just do > cfmakeraw(), if that one is implemented instead. Or is there anything > else that enables unbuffered terminal input? I imagine that OS/2 must > have applications that react to keypresses in the terminal! > > Maybe finding a solution here would also fix terminal control on > Mingw/Windows … Good chance as they're similar enough. Dave |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 15:20:57
|
On 05/14/22 12:22 AM, Thomas Orgis wrote: > Am Sat, 14 May 2022 08:59:30 +0200 > schrieb Thomas Orgis <tho...@or...>: > >> Instead of calling tcgetattr() and term_setup(), OS/2 could just do >> cfmakeraw(), if that one is implemented instead. Or is there anything >> else that enables unbuffered terminal input? I imagine that OS/2 must >> have applications that react to keypresses in the terminal! > This is outdated cruft now? > > # On OS/2, we need to link to os2term to make terminal control actually work. > AC_CHECK_LIB([os2term], [tcsetattr], [ADD_LDFLAGS="$ADD_LDFLAGS -los2term"]) > > We had it working at some point … Yes, it is now cruft as there is no os2term lib accessible here Dave |
|
From: Thomas O. <tho...@or...> - 2022-05-14 15:00:09
|
Ah, that's the ultra-recent changes prompted by our discussion. We need to re-insert some header into term_posix.c. Will take some time until I can have a go again. Do you manage? I think we had it in this very discussion thread, perhaps. Alrighty then, Thomas |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 14:43:47
|
On 05/14/22 12:17 AM, Thomas Orgis wrote:
> Am Sat, 14 May 2022 00:00:37 -0700
> schrieb Dave Yeo <dav...@gm...>:
>
>>>> The above works for configure but the -idirafter doesn't end up in the
>>>> makefiles.
>>>
>>> Is it present in the final configure printouts about the configuration?
>>
>> No
>
> Does the build work now? I committed a change that sets OS2_CFLAGS and
> only temporarily adds them to CFLAGS for the test. I am not sure at
> what point the value got purged before, but it's cleaner that way.
>
> I removed the EMX ifdefs in local.c now. Now let's settle terminal
> control. It shouldn't be so hard to get single keypresses.
>
Hmm, now we're missing TIOCGWINSZ, wonder if I forgot to do make clean
last night? I was tired.
../mpg123.svn/src/term_posix.c: In function 'term_width':
../mpg123.svn/src/term_posix.c:62:17: error: storage size of 'geometry'
isn't known
62 | struct winsize geometry;
| ^~~~~~~~
../mpg123.svn/src/term_posix.c:64:15: error: 'TIOCGWINSZ' undeclared
(first use
in this function)
64 | if(ioctl(fd, TIOCGWINSZ, &geometry) >= 0)
| ^~~~~~~~~~
../mpg123.svn/src/term_posix.c:64:15: note: each undeclared identifier
is report
ed only once for each function it appears in
make: *** [src/term_posix.o] Error 1
Dave
|
|
From: Thomas O. <tho...@or...> - 2022-05-14 07:22:26
|
Am Sat, 14 May 2022 08:59:30 +0200 schrieb Thomas Orgis <tho...@or...>: > Instead of calling tcgetattr() and term_setup(), OS/2 could just do > cfmakeraw(), if that one is implemented instead. Or is there anything > else that enables unbuffered terminal input? I imagine that OS/2 must > have applications that react to keypresses in the terminal! This is outdated cruft now? # On OS/2, we need to link to os2term to make terminal control actually work. AC_CHECK_LIB([os2term], [tcsetattr], [ADD_LDFLAGS="$ADD_LDFLAGS -los2term"]) We had it working at some point … Alrighty then, Thomas |
|
From: Thomas O. <tho...@or...> - 2022-05-14 07:17:30
|
Am Sat, 14 May 2022 00:00:37 -0700 schrieb Dave Yeo <dav...@gm...>: > >> The above works for configure but the -idirafter doesn't end up in the > >> makefiles. > > > > Is it present in the final configure printouts about the configuration? > > No Does the build work now? I committed a change that sets OS2_CFLAGS and only temporarily adds them to CFLAGS for the test. I am not sure at what point the value got purged before, but it's cleaner that way. I removed the EMX ifdefs in local.c now. Now let's settle terminal control. It shouldn't be so hard to get single keypresses. Alrighty then, Thomas |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 07:00:48
|
On 05/13/22 09:51 PM, Thomas Orgis wrote: > Am Fri, 13 May 2022 19:13:02 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> Yes the build works fine now. Still need to workaround for os2me.h, need >> something like, > >> --- configure.ac (revision 5065) >> +++ configure.ac (working copy) >> @@ -1945,6 +1945,7 @@ >> ;; >> os2) >> OS2_LIBS="-lcx -lmmpm2" >> + CFLAGS+="-idirafter /@unixroot/usr/include/os2tk45" >> AC_CHECK_HEADERS([os2.h]) >> # os2me.h depends on os2.h >> # Yes, that way of coding it is ugly. >> @@ -1953,6 +1954,7 @@ >> # We mimick exactly the way how the >> header will >> be used. >> # It seems to be picky... >> AC_CHECK_HEADERS([os2me.h], [], [], >> [#define INC >> L_OS2MM >> +#undef VERSION > > OK, the undef VERSION is easy, I guess. But that business about the > different headers … > > 1. This is just for the OS/2 audio output, os2me, right? Yes, os2me.h > > 2. You need the -idirafter in CFLAGs for the output module build only, > yes? Yes, and the configure check. > >> The above works for configure but the -idirafter doesn't end up in the >> makefiles. > > Is it present in the final configure printouts about the configuration? No > > But anyway, it should be put into OS2_CFLAGS, anyway. That is applied in > > src_libout123_modules_output_os2_la_CFLAGS = $(MODULE_CFLAGS) @OS2_CFLAGS@ > > Or does the overall build also need this? Then we need to add those > flags elsewhere. But I also wonder how generic this setting is. For how > many users besides yourself are we doing this? ;-) It's fairly generic, the @unixroot thing expands to a drive letter, where ever the *nix environment is installed and "yum install os2tk45" will install it in /@unixroot/usr/include/os2tk45. See https://www.arcanoae.com/wiki/arcaos/compatibility-subsystems/getting-to-know-the-unix-compatibility-subsystem-klibc/ and our frontend to YUM/RPM, https://www.arcanoae.com/wiki/anpm/ And yes, it is only needed for the OS/2 sound module to find os2me.h. Thanks, Dave |
|
From: Thomas O. <tho...@or...> - 2022-05-14 06:59:42
|
Am Fri, 13 May 2022 23:35:23 -0700 schrieb Dave Yeo <dav...@gm...>: > As far as I know, all OS/2 compilers define __OS2__, so would be fine. > No, EMX is likely to outdated to compile MPG123 without a lot of work, So I'll switch all ifdefs to __OS2__ and will drop the EMX bits. Less cruft. > Actually I hadn't used terminal control previously. Now adding -v to the > command line, I get this message, > Terminal control enabled, press 'h' for listing of keys and functions. OK … so getting the window size works. > but 'h' nor any other key besides CTRL-C does anything and displays on > the command line after mpg123 exits. Never noticed before. Better try without -v (less obscuring). So you press a key and it appears after mpg123 ends? No reaction … hm. Ah, of course. Would things suddenly happen if you didn't press 'h', but 'h' + 'return'? We switch the terminal into non-canonical mode, which also turns off line buffering, using tcsetattr. I wonder: Does OS/2 implement cfmakeraw(), perhaps? That one could be used instead. You could experiment in src/term.c, in void term_init(void) Instead of calling tcgetattr() and term_setup(), OS/2 could just do cfmakeraw(), if that one is implemented instead. Or is there anything else that enables unbuffered terminal input? I imagine that OS/2 must have applications that react to keypresses in the terminal! Maybe finding a solution here would also fix terminal control on Mingw/Windows … Alrighty then, Thomas |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 06:35:32
|
On 05/13/22 09:29 PM, Thomas Orgis wrote:
> Am Fri, 13 May 2022 19:28:07 -0700
> schrieb Dave Yeo <dav...@gm...>:
>
>> The CFLAGS has -DOS2 in it, probably put there by configure, so it is fine
>
> Heh, yes. Silly me.
>
> AC_CHECK_HEADER([os2.h], [ADD_CPPFLAGS="$ADD_CPPFLAGS -DOS2"])
>
> But we could skip that definition and instead use __OS2__? Would that
> exclude anyone?
As far as I know, all OS/2 compilers define __OS2__, so would be fine.
...
>
> So I'll just drop that part. We're not testing with EMX anymore?
No, EMX is likely to outdated to compile MPG123 without a lot of work,
it's lacking a lot of modern types and libtool is geared to the current
state of things.
>
>> I think using isatty() would be fine, or using HAVE_TERMIOS as is which
>> seems fine as well.
>
> Well, it's about the runtime check. Let's look at that snippet:
>
>
> int term_width(int fd)
> {
> #ifdef __EMX__
> /* OS/2 */
> int s[2];
> _scrsize (s);
> if (s[0] >= 0)
> return s[0];
> #else
> #ifdef HAVE_TERMIOS
> /* POSIX */
> struct winsize geometry;
> geometry.ws_col = 0;
> if(ioctl(fd, TIOCGWINSZ, &geometry) >= 0)
> return (int)geometry.ws_col;
> #else
>
>
> So you're currently running the ioctl()? Is mpg123 able to get the
> terminal width that way? Does it always attempt terminal control by
> default, giving you that error message about tcsetattr?
Yes, it always gave that message when playing a mp3. Gone now.
>
> I committed a change that omits the tcsetattr() on __OS2__. Does that
> make terminal control work for you (with some uglyness because input is
> echoed)? Maybe I'll also just omit the error check for tcsetattr and
> treat this as a fallback mode. We wouldn't have special code for OS/2
> then, as things build and might get fixed properly for runtime.
Actually I hadn't used terminal control previously. Now adding -v to the
command line, I get this message,
Terminal control enabled, press 'h' for listing of keys and functions.
but 'h' nor any other key besides CTRL-C does anything and displays on
the command line after mpg123 exits. Never noticed before.
Dave
|
|
From: Thomas O. <tho...@or...> - 2022-05-14 04:51:45
|
Am Fri, 13 May 2022 19:13:02 -0700 schrieb Dave Yeo <dav...@gm...>: > Yes the build works fine now. Still need to workaround for os2me.h, need > something like, > --- configure.ac (revision 5065) > +++ configure.ac (working copy) > @@ -1945,6 +1945,7 @@ > ;; > os2) > OS2_LIBS="-lcx -lmmpm2" > + CFLAGS+="-idirafter /@unixroot/usr/include/os2tk45" > AC_CHECK_HEADERS([os2.h]) > # os2me.h depends on os2.h > # Yes, that way of coding it is ugly. > @@ -1953,6 +1954,7 @@ > # We mimick exactly the way how the > header will > be used. > # It seems to be picky... > AC_CHECK_HEADERS([os2me.h], [], [], > [#define INC > L_OS2MM > +#undef VERSION OK, the undef VERSION is easy, I guess. But that business about the different headers … 1. This is just for the OS/2 audio output, os2me, right? 2. You need the -idirafter in CFLAGs for the output module build only, yes? > The above works for configure but the -idirafter doesn't end up in the > makefiles. Is it present in the final configure printouts about the configuration? But anyway, it should be put into OS2_CFLAGS, anyway. That is applied in src_libout123_modules_output_os2_la_CFLAGS = $(MODULE_CFLAGS) @OS2_CFLAGS@ Or does the overall build also need this? Then we need to add those flags elsewhere. But I also wonder how generic this setting is. For how many users besides yourself are we doing this? ;-) Alrighty then, Thomas |
|
From: Thomas O. <tho...@or...> - 2022-05-14 04:30:13
|
Am Fri, 13 May 2022 19:28:07 -0700
schrieb Dave Yeo <dav...@gm...>:
> The CFLAGS has -DOS2 in it, probably put there by configure, so it is fine
Heh, yes. Silly me.
AC_CHECK_HEADER([os2.h], [ADD_CPPFLAGS="$ADD_CPPFLAGS -DOS2"])
But we could skip that definition and instead use __OS2__? Would that
exclude anyone?
> >>> Also, this snippet in local.c:
> >>>
> >>> #ifdef __EMX__
> >>> /* Special ways for OS/2 EMX */
> >>> #include <stdlib.h>
> >>> #else
> >>> /* POSIX stuff */
> >>> #ifdef HAVE_TERMIOS
> >>> #include <termios.h>
> >>> #include <sys/ioctl.h>
> >>> #endif
> >>> #endif
> OK, it _should_ have worked with EMX as it had better term support. Not
> sure why it was disabled, happened before my time.
So I'll just drop that part. We're not testing with EMX anymore?
> I think using isatty() would be fine, or using HAVE_TERMIOS as is which
> seems fine as well.
Well, it's about the runtime check. Let's look at that snippet:
int term_width(int fd)
{
#ifdef __EMX__
/* OS/2 */
int s[2];
_scrsize (s);
if (s[0] >= 0)
return s[0];
#else
#ifdef HAVE_TERMIOS
/* POSIX */
struct winsize geometry;
geometry.ws_col = 0;
if(ioctl(fd, TIOCGWINSZ, &geometry) >= 0)
return (int)geometry.ws_col;
#else
So you're currently running the ioctl()? Is mpg123 able to get the
terminal width that way? Does it always attempt terminal control by
default, giving you that error message about tcsetattr?
I committed a change that omits the tcsetattr() on __OS2__. Does that
make terminal control work for you (with some uglyness because input is
echoed)? Maybe I'll also just omit the error check for tcsetattr and
treat this as a fallback mode. We wouldn't have special code for OS/2
then, as things build and might get fixed properly for runtime.
Alrighty then,
Thomas
|
|
From: Dave Y. <dav...@gm...> - 2022-05-14 02:28:15
|
On 05/13/22 08:44 AM, Thomas Orgis wrote: > Am Fri, 13 May 2022 07:46:11 -0700 > schrieb Dave Yeo <dav...@gm...>: > >> Strictly speaking, __OS2__ covers all compilers, __EMX__ covers all >> versions of GCC, and __KLIBC__ covers the current GCC/libc (a mostly >> compatible rewrite of EMX's libc using BSD licensing rather then GPL) >> and GCC. > > So this looks like we should use __OS2__. Is it identical with the > plain OS2 (no underscores) that we have littered on the source right > now? The CFLAGS has -DOS2 in it, probably put there by configure, so it is fine > >>> Also, this snippet in local.c: >>> >>> #ifdef __EMX__ >>> /* Special ways for OS/2 EMX */ >>> #include <stdlib.h> >>> #else >>> /* POSIX stuff */ >>> #ifdef HAVE_TERMIOS >>> #include <termios.h> >>> #include <sys/ioctl.h> >>> #endif >>> #endif >>> >>> Does that make sense, still (if anytime)? Do you have termios and >>> terminal control in mpg123? >> >> It worked fine with EMX, now tcsetattr() is missing so we get, >> [../mpg123.svn/src/term.c:term_init():154] error: failed to get terminal >> attributes: Invalid argument > > It worked with EMX? But we explicitly disabled termios there? OK, it _should_ have worked with EMX as it had better term support. Not sure why it was disabled, happened before my time. > > So, should I just drop this ifdef and use HAVE_TERMIOS as-is, and you > eventually sort out the runtime problem with tcsetattr(). Or even more: > Could terminal control work for you (in the end, it's just > select(STDIN_FILENO)), just not with meddling with the attributes? > Works isatty() on OS/2? We could use that for more proper terminal > detection than messing with attributes. I think using isatty() would be fine, or using HAVE_TERMIOS as is which seems fine as well. Thanks, Dave |
|
From: Dave Y. <dav...@gm...> - 2022-05-14 02:13:15
|
On 05/13/22 08:41 AM, Thomas Orgis wrote:
> Am Fri, 13 May 2022 07:57:08 -0700
> schrieb Dave Yeo <dav...@gm...>:
>
>> Unluckily it seems that io.h also declares _setmode() but not _O_BINARY
>> or _O_TEXT.
> OK, please try the current trunk. I made a more elaborate compile check
> now that tests the function as well the symbol. Does
>
> 1. the check work?
>
> $ grep -i setmode src/config.h
> /* for Win/DOS system with setmode() */
> /* #undef HAVE_SETMODE */
> /* for Win/DOS system with _setmode() */
> /* #undef HAVE__SETMODE */
>
> You should have one of those defined.
>
> 2. the build work?
Yes the build works fine now. Still need to workaround for os2me.h, need
something like,
--- configure.ac (revision 5065)
+++ configure.ac (working copy)
@@ -1945,6 +1945,7 @@
;;
os2)
OS2_LIBS="-lcx -lmmpm2"
+ CFLAGS+="-idirafter /@unixroot/usr/include/os2tk45"
AC_CHECK_HEADERS([os2.h])
# os2me.h depends on os2.h
# Yes, that way of coding it is ugly.
@@ -1953,6 +1954,7 @@
# We mimick exactly the way how the
header will
be used.
# It seems to be picky...
AC_CHECK_HEADERS([os2me.h], [], [],
[#define INC
L_OS2MM
+#undef VERSION
#define INCL_DOS
#define INCL_VIO
#define INCL_KBD
as klibc has no multimedia support so need to fall back on the official
OS/2 toolkit headers and we don't want those libc headers.
The above works for configure but the -idirafter doesn't end up in the
makefiles.
Currently using C_INCLUDE_PATH, make 'CFLAGS -idirafter
/@unixroot/usr/include/os2tk45' also works.
Thanks
Dave
|
|
From: Thomas O. <tho...@or...> - 2022-05-13 15:45:11
|
Am Fri, 13 May 2022 07:46:11 -0700 schrieb Dave Yeo <dav...@gm...>: > Strictly speaking, __OS2__ covers all compilers, __EMX__ covers all > versions of GCC, and __KLIBC__ covers the current GCC/libc (a mostly > compatible rewrite of EMX's libc using BSD licensing rather then GPL) > and GCC. So this looks like we should use __OS2__. Is it identical with the plain OS2 (no underscores) that we have littered on the source right now? > > Also, this snippet in local.c: > > > > #ifdef __EMX__ > > /* Special ways for OS/2 EMX */ > > #include <stdlib.h> > > #else > > /* POSIX stuff */ > > #ifdef HAVE_TERMIOS > > #include <termios.h> > > #include <sys/ioctl.h> > > #endif > > #endif > > > > Does that make sense, still (if anytime)? Do you have termios and > > terminal control in mpg123? > > It worked fine with EMX, now tcsetattr() is missing so we get, > [../mpg123.svn/src/term.c:term_init():154] error: failed to get terminal > attributes: Invalid argument It worked with EMX? But we explicitly disabled termios there? So, should I just drop this ifdef and use HAVE_TERMIOS as-is, and you eventually sort out the runtime problem with tcsetattr(). Or even more: Could terminal control work for you (in the end, it's just select(STDIN_FILENO)), just not with meddling with the attributes? Works isatty() on OS/2? We could use that for more proper terminal detection than messing with attributes. Alrighty then, Thomas |
|
From: Thomas O. <tho...@or...> - 2022-05-13 15:41:51
|
Am Fri, 13 May 2022 07:57:08 -0700 schrieb Dave Yeo <dav...@gm...>: > Unluckily it seems that io.h also declares _setmode() but not _O_BINARY > or _O_TEXT. OK, please try the current trunk. I made a more elaborate compile check now that tests the function as well the symbol. Does 1. the check work? $ grep -i setmode src/config.h /* for Win/DOS system with setmode() */ /* #undef HAVE_SETMODE */ /* for Win/DOS system with _setmode() */ /* #undef HAVE__SETMODE */ You should have one of those defined. 2. the build work? Alrighty then, Thomas |
|
From: Dave Y. <dav...@gm...> - 2022-05-13 14:57:19
|
On 05/13/22 12:18 AM, Thomas Orgis wrote:
> … please test the updated state in svn trunk (with autoreconf). I added
> detection of _setmode() (Windows) and setmode() nd introduced a common
> place for calling those.
>
> Index: src/compat/compat.c
> ===================================================================
> --- src/compat/compat.c (revisión: 5064)
> +++ src/compat/compat.c (copia de trabajo)
> @@ -155,6 +155,15 @@
> return fclose(stream);
> }
>
> +void compat_binmode(int fd, int enable)
> +{
> +#if defined(HAVE__SETMODE)
> + _setmode(fd, enable ? _O_BINARY : _O_TEXT)
> +#elif defined(HAVE_SETMODE)
> + setmode(fd, enable ? O_BINARY : O_TEXT)
> +#endif
> +}
> +
>
> Index: src/net123_exec.c
> ===================================================================
> --- src/net123_exec.c (revisión: 5064)
> +++ src/net123_exec.c (copia de trabajo)
> @@ -227,6 +227,9 @@
> return NULL;
> }
>
> + compat_binmode(fd[0], TRUE);
> + compat_binmode(fd[1], TRUE);
> +
> nh->worker = fork();
> if(nh->worker == -1)
> {
>
>
> Does that do the trick?
>
Unluckily it seems that io.h also declares _setmode() but not _O_BINARY
or _O_TEXT.
...
libtool: compile: gcc -DHAVE_CONFIG_H -I. -I../mpg123.svn -I./src
-DPKGLIBDIR=\"h:/tmp/mpg123/lib/mpg123\" -I../mpg123.svn/src
-I../mpg123.svn/src/compat -I../mpg123.svn/src/libmpg123
-I../mpg123.svn/src/libout123 -I./src/libmpg123 -I./src/libsyn123
-I./src/libout123 -DOS2 -DOPT_GENERIC -DREAL_IS_FLOAT
-DNEWOLD_WRITE_SAMPLE -O2 -fomit-frame-pointer -funroll-all-loops
-finline-functions -ffast-math -g -O2 -MT src/compat/compat.lo -MD -MP
-MF src/compat/.deps/compat.Tpo -c ../mpg123.svn/src/compat/compat.c
-DDLL_EXPORT -DPIC -o src/compat/.libs/compat.o
../mpg123.svn/src/compat/compat.c: In function 'compat_binmode':
../mpg123.svn/src/compat/compat.c:161:2: warning: implicit declaration
of function '_setmode' [-Wimplicit-function-declaration]
161 | _setmode(fd, enable ? _O_BINARY : _O_TEXT);
| ^~~~~~~~
../mpg123.svn/src/compat/compat.c:161:24: error: '_O_BINARY' undeclared
(first use in this function); did you mean 'O_BINARY'?
161 | _setmode(fd, enable ? _O_BINARY : _O_TEXT);
| ^~~~~~~~~
| O_BINARY
../mpg123.svn/src/compat/compat.c:161:24: note: each undeclared
identifier is reported only once for each function it appears in
../mpg123.svn/src/compat/compat.c:161:36: error: '_O_TEXT' undeclared
(first use in this function); did you mean 'O_TEXT'?
161 | _setmode(fd, enable ? _O_BINARY : _O_TEXT);
| ^~~~~~~
| O_TEXT
make: *** [src/compat/compat.lo] Error 1
Dave
|
|
From: Dave Y. <dav...@gm...> - 2022-05-13 14:46:20
|
On 05/12/22 11:46 PM, Thomas Orgis wrote: > Am Thu, 12 May 2022 20:11:50 +0200 > schrieb Thomas Orgis <tho...@or...>: > >> Now for a correct preprocessor guard... either platform check or >> simply if setmode is available. > > Can we clarify that? > > We have > > #ifdef OS2 > > and > > #ifdef __EMX__ > > Which one is better? Strictly speaking, __OS2__ covers all compilers, __EMX__ covers all versions of GCC, and __KLIBC__ covers the current GCC/libc (a mostly compatible rewrite of EMX's libc using BSD licensing rather then GPL) and GCC. I usually use __OS2__ mostly as it more clear then __EMX__ but if someone was to compile mpg123 with OpenWatcom etc, which should work given a makefile, those differences become important. > Also, this snippet in local.c: > > #ifdef __EMX__ > /* Special ways for OS/2 EMX */ > #include <stdlib.h> > #else > /* POSIX stuff */ > #ifdef HAVE_TERMIOS > #include <termios.h> > #include <sys/ioctl.h> > #endif > #endif > > Does that make sense, still (if anytime)? Do you have termios and > terminal control in mpg123? It worked fine with EMX, now tcsetattr() is missing so we get, [../mpg123.svn/src/term.c:term_init():154] error: failed to get terminal attributes: Invalid argument Eventually I expect tcsetattr() to be redone, but who knows if it will happen. Thanks, Dave |
54 messages has been excluded from this view by a project administrator.
