Hi/2. Rocky Bernstein wrote: > Ok, then you can be responsible for OS/2 . That means that you will be > expected to test, in advance, releases. Note that this is a change from the > laxness we've had in the past with respect to releases. >
No problem. > If you disappear and there is no one else to take responsibility, the > ability to test OS/2 disappears, then OS/2 support in libcdio may disappear > as well. > Ooops... I feel the very much responsibility. ^^ >> What about testing an OS getopt first ? > > We have 7 or so drivers that work with the supplied getopt.c and one that > doesn't. And for that one driver we have maybe two people who use that. > Even here, their use is probably infrequently for say Mplayer while the > uses elsewhere span audio ripping, other media players, making boot CDs and > lots of other things I probably don't know about. So guess which way causes > the least disruption to the majority of users and developers? > Hmmm... I don't think this is a problem of quantity. But this is not a important part. > Couple that with the fact currently we don't have rigorous tests either > getopt routine to make sure that works. It's possible, though that in one > of the larger integration tests, we might catch a malfunctioning getopt, > but I wouldn't want to count on that. > > If you want to start writing a test suite for getopt whether it the > provided one or the OS-supplied one, we can reconsider. But given things > are currently the way they are, if the supplied getopt works, it's better > to to use that, because assuming the getopt.c compiles as it was intended, > we *know* what the intended behavior is. > Ok. I agree. So I approach in other way. Review, please... > > > On Mon, Jul 28, 2014 at 10:12 PM, KO Myung-Hun <[email protected]> wrote: > >> >> >> Rocky Bernstein wrote: >>> Sorry for the delay. Things have been busy for me. >>> >> >> No problem. ^^ >> >>> It is interesting to hear back after the 5 or so years. About a month >> and a >>> half ago we were discussing dropping libcdio's OS/2 driver altogether. >> See >>> http://lists.gnu.org/archive/html/libcdio-devel/2014-06/msg00004.html >>> >>> What motivated this was the desire to change the API to add >> get_track_isrc >>> and Robert Kausch mentioned he had no way to test OS/2. In that, we >>> realized that basically no one *is* actively testing OS/2. >>> >>> Aside from yourself and possibly Natalia, do you know anyone else that is >>> using this? >>> >> >> I don't know. But those who want to build MPlayer with audio cd >> supports, would be using libcdio. >> >>> Given the low activity and difficulty for finding developers and testers, >>> I'm inclined to have this maintained by you and Natalia in separately. >> She >>> already has a fork on github of libcdio-paranoia. >>> >>> If OS/2 is to survive in libcdio, someone needs to commit to handle >>> problems and API changes as such things arise. Are you willing to commit >> to >>> this? >>> >> >> Of course. Five years ago, it's me to submit OS/2 patches as you know. ^^ >> >>> Lastly, on the first patch. It has to do with deciding on whether the use >>> the libcdio-supplied getopt.c,and this is based purely on OS. OS/2 is the >>> only one to not used the supplied getopt.c >>> >>> Rather than have a test by OS, I'd prefer a test to compile the supplied >>> getopt; if that fails, then run a test to see if there is an OS getopt. >>> >> >> Ok. What about testing an OS getopt first ? I think, it's better to >> consider libcdio-getopt as a fallback. >> >>> >>> >>> On Sat, Jul 26, 2014 at 11:50 PM, KO Myung-Hun <[email protected]> wrote: >>> >>>> Ping ? >>>> >>>> KO Myung-Hun wrote: >>>>> Hi/2, long tiem no see. ^^ >>>>> >>>>> I attach the patches to build libcdio and to enhance memory usage on >>>> OS/2. >>>>> >>>>> Review, please... >>>>> >>>>> >>>>> >> >> -- >> KO Myung-Hun >> >> Using Mozilla SeaMonkey 2.7.2 >> Under OS/2 Warp 4 for Korean with FixPak #15 >> In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM >> >> Korean OS/2 User Community : http://www.ecomstation.co.kr >> >> >> > -- KO Myung-Hun Using Mozilla SeaMonkey 2.7.2 Under OS/2 Warp 4 for Korean with FixPak #15 In VirtualBox v4.1.32 on Intel Core i7-3615QM 2.30GHz with 8GB RAM Korean OS/2 User Community : http://www.ecomstation.co.kr
From 18bc417bbd8d512f7bd6d62a933d198fb46c5aa2 Mon Sep 17 00:00:00 2001 From: KO Myung-Hun <[email protected]> Date: Mon, 21 Jul 2014 00:28:39 +0900 Subject: [PATCH 1/2] Fix linkage on OS/2 OS/2 kLIBC has getopt() already. ----- CCLD cd-drive.exe ld.exe: symbol `_optarg' defined more than once in F:/lang/gcc/usr/lib/libc_dll.a(IMPORT#45#426bf) ----- --- src/getopt.h | 14 ++++++++++++++ 1 files changed, 14 insertions(+), 0 deletions(-) diff --git a/src/getopt.h b/src/getopt.h index da1a01f..b67fdd4 100644 --- a/src/getopt.h +++ b/src/getopt.h @@ -48,6 +48,20 @@ extern "C" { #endif +#ifdef __KLIBC__ +/* OS/2 kLIBC has already getopt(). So to avoid name clash, rename + them here. */ + +#define optarg libcdio_optarg +#define optind libcdio_optind +#define opterr libcdio_opterr +#define optopt libcdio_optopt + +#define getopt libcdio_getopt +#define getopt_long libcdio_getopt_long +#define getopt_long_only libcdio_getopt_long_only +#endif + /* For communication from `getopt' to the caller. When `getopt' finds an option that takes an argument, the argument value is returned here. -- 1.7.3.2
